You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -223,6 +229,15 @@ Programmatically assemble prompts for LLMs using [GenAIScript](https://microsoft
223
229
- Goose allows you to extend its functionality by [building your own MCP servers](https://block.github.io/goose/docs/tutorials/custom-extensions).
224
230
- Includes built-in tools for development, web scraping, automation, memory, and integrations with JetBrains and Google Drive.
225
231
232
+
### gptme
233
+
[gptme](https://github.com/gptme/gptme) is a open-source terminal-based personal AI assistant/agent, designed to assist with programming tasks and general knowledge work.
234
+
235
+
**Key features:**
236
+
- CLI-first design with a focus on simplicity and ease of use
237
+
- Rich set of built-in tools for shell commands, Python execution, file operations, and web browsing
238
+
- Local-first approach with support for multiple LLM providers
239
+
- Open-source, built to be extensible and easy to modify
240
+
226
241
### Klavis AI Slack/Discord/Web
227
242
[Klavis AI](https://www.klavis.ai/) is an Open-Source Infra to Use, Build & Scale MCPs with ease.
228
243
@@ -245,6 +260,18 @@ Programmatically assemble prompts for LLMs using [GenAIScript](https://microsoft
245
260
- Open-source and self-hostable, with secure multi-user support
246
261
- Future roadmap includes expanded MCP feature support
247
262
263
+
### Lutra
264
+
[Lutra](https://lutra.ai) is an AI agent that transforms conversations into actionable, automated workflows.
265
+
266
+
**Key features:**
267
+
- Easy MCP Integration: Connecting Lutra to MCP servers is as simple as providing the server URL; Lutra handles the rest behind the scenes.
268
+
- Chat to Take Action: Lutra understands your conversational context and goals, automatically integrating with your existing apps to perform tasks.
269
+
- Reusable Playbooks: After completing a task, save the steps as reusable, automated workflows—simplifying repeatable processes and reducing manual effort.
270
+
- Shareable Automations: Easily share your saved playbooks with teammates to standardize best practices and accelerate collaborative workflows.
271
+
272
+
**Learn more:**
273
+
-[Lutra AI agent explained](https://www.youtube.com/watch?v=W5ZpN0cMY70)
274
+
248
275
### mcp-agent
249
276
[mcp-agent] is a simple, composable framework to build agents using Model Context Protocol.
250
277
@@ -282,6 +309,19 @@ Programmatically assemble prompts for LLMs using [GenAIScript](https://microsoft
282
309
- Extend Copilot Studio agents with MCP servers
283
310
- Leveraging Microsoft unified, governed, and secure API management solutions
284
311
312
+
### MindPal
313
+
[MindPal](https://mindpal.io) is a no-code platform for building and running AI agents and multi-agent workflows for business processes.
314
+
315
+
**Key features:**
316
+
- Build custom AI agents with no-code
317
+
- Connect any SSE MCP server to extend agent tools
318
+
- Create multi-agent workflows for complex business processes
319
+
- User-friendly for both technical and non-technical professionals
320
+
- Ongoing development with continuous improvement of MCP support
specification to indicate the locations of authorization servers. The Protected Resource Metadata document returned by the MCP server **MUST** include
87
88
the `authorization_servers` field containing at least one authorization server.
88
89
89
90
The specific use of `authorization_servers` is beyond the scope of this specification; implementers should consult
90
-
the [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13) documentation for
91
+
OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)) for
91
92
guidance on implementation details.
92
93
94
+
Implementors should note that Protected Resource Metadata documents can define multiple authorization servers. The responsibility for selecting which authorization server to use lies with the MCP client, following the guidelines specified in
MCP servers **MUST** use the HTTP header `WWW-Authenticate` when returning a _401 Unauthorized_ to indicate the location of the resource server metadata URL
94
-
as described in [OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-13).
98
+
as described in OAuth 2.0 Protected Resource Metadata ([RFC9728](https://datatracker.ietf.org/doc/html/rfc9728)).
95
99
96
100
MCP clients **MUST** be able to parse `WWW-Authenticate` headers and respond appropriately to `HTTP 401 Unauthorized` responses from the MCP server.
97
101
@@ -255,32 +259,31 @@ Servers **MUST** return appropriate HTTP status codes for authorization errors:
255
259
256
260
## 3. Security Considerations
257
261
258
-
Implementations **MUST** follow OAuth 2.1 security best practices. Refer to
259
-
[RFC9700](https://datatracker.ietf.org/doc/html/rfc9700) for details.
262
+
Implementations **MUST** follow OAuth 2.1 security best practices as laid out in [Section 7. Security Considerations](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#name-security-considerations).
260
263
261
264
### 3.1 Token Theft
262
265
Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with
263
266
requests that appear legitimate to resource servers.
264
267
265
-
Clients **MUST** implement secure token storage and follow OAuth 2.0 best practices,
266
-
as outlined in [RFC 9700](https://datatracker.ietf.org/doc/html/rfc9700).
268
+
Clients **MUST** implement secure token storage and follow OAuth best practices,
269
+
as outlined in [OAuth 2.1, section 7.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.1).
267
270
268
-
MCP authorization servers SHOULD enforce token expiration and rotation to limit the window of exploitation.
271
+
MCP authorization servers SHOULD issue short-lived access tokens token to reduce the impact of leaked tokens. For public clients, MCP authorization servers MUST rotate refresh tokens as described in [Section 4.3.1 of OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-4.3.1).
269
272
270
273
### 3.2 Communication Security
271
274
An attacker positioned between MCP clients and MCP servers can intercept tokens via [Man-in-the-Middle (MITM)](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) attacks.
272
275
273
276
Implementations MUST follow [OAuth 2.1 section 1.5](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-1.5).
274
277
275
278
Specifically:
276
-
1. All authorization endpoints **MUST** be served over HTTPS.
279
+
1. All authorization server endpoints **MUST** be served over HTTPS.
277
280
1. All redirect URIs **MUST** be either `localhost` or use HTTPS.
278
281
279
282
### 3.3 Authorization Code Protection
280
283
281
-
An attacker who has gained access to an authorization code contained in an authorization response can try to redeem the authorization code for an access token or otherwise make use of the authorization code. (Further described in [RFC 9700 Section 4.5](https://www.rfc-editor.org/rfc/rfc9700.html#name-authorization-code-injectio))
284
+
An attacker who has gained access to an authorization code contained in an authorization response can try to redeem the authorization code for an access token or otherwise make use of the authorization code. (Further described in [OAuth 2.1, section 7.5](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.5))
282
285
283
-
MCP clients **MUST** implement PKCE according to [OAuth 2.1 section 7.5.2](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#name-countermeasures). PKCE helps prevent authorization code interception attacks by requiring clients to create a secret verifier-challenge pair, ensuring that only the original requestor can exchange an authorization code for tokens.
286
+
MCP clients **MUST** implement PKCE according to [OAuth 2.1 section 7.5.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.5.2). PKCE helps prevent authorization code interception and injection attacks by requiring clients to create a secret verifier-challenge pair, ensuring that only the original requestor can exchange an authorization code for tokens.
MCP clients **SHOULD** use and verify state parameters in the authorization code flow
294
297
and discard any results that do not include or have a mis-match with the original state.
295
298
296
-
Authorization servers **MUST** take precautions to prevent redirecting user agents to untrusted URI's, following suggestions laid out in [RFC 9700 Section 4.11.2](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.11.2)
299
+
Authorization servers **MUST** take precautions to prevent redirecting user agents to untrusted URI's, following suggestions laid out in [OAuth 2.1, Section 7.12.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#section-7.12.2)
297
300
298
301
Authorization servers **SHOULD** only automatically redirect the user agent if it trusts the redirection URI. If the URI is not trusted, the authorization server MAY inform the user and rely on the user to make the correct decision.
299
302
303
+
### 3.4 Confused Deputy Problem
304
+
305
+
Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to confused deputy vulnerabilities. By using stolen authorization codes, they can obtain access tokens without user consent. See [Security Best Practices 2.1](/specification/draft/basic/security_best_practices) for details.
300
306
301
-
### 3.4 Access Token Privilege Restriction
307
+
MCP proxy servers using static client IDs **MUST** obtain user consent for each dynamically
308
+
registered client before forwarding to third-party authorization servers (which may require additional consent).
309
+
310
+
### 3.5 Access Token Privilege Restriction
302
311
303
312
An attacker can gain unauthorized access or otherwise compromise a MCP server if the server accepts tokens issued for other resources.
304
313
@@ -322,4 +331,6 @@ For example, a MCP server could validate inbound tokens through one of the follo
322
331
MCP servers **MUST** strictly validate token audiences and only accept tokens specifically intended for themselves. Implementers **MUST NOT** design architectures where clients send
323
332
tokens through the MCP server intended for other resources.
324
333
325
-
If the MCP server makes requests to upstream APIs, it acts as an OAuth client to the upstream API. The access token it uses at the upstream API may be an opaque token, so the MCP server has no way to introspect the token to validate the audience or know what user it is associated with. Even if the token were a JWT [RFC 9068](https://www.rfc-editor.org/rfc/rfc9068.html) token, the audience of that token would not be the MCP server, so the MCP server is not intended to parse the token anyway. The MCP server **MUST NOT** accept such tokens to grant access to its resources.
334
+
If the MCP server makes requests to upstream APIs, it acts as an OAuth client to the upstream API. The access token it uses at the upstream API may be an opaque token, so the MCP server has no way to introspect the token to validate the audience or know what user it is associated with. Even if the token were a JWT [RFC 9068](https://www.rfc-editor.org/rfc/rfc9068.html) token, the audience of that token would not be the MCP server, so the MCP server is not intended to parse the token anyway. The MCP server **MUST NOT** accept such tokens to grant access to its resources.
0 commit comments