Are ChatGPT docs lying about this MCP tool field existing?

camel · October 16, 2025, 6:18am

I’ve been able to create a read-only app with the Apps SDK. Pretty cool seeing it in the chat! I’m really excited about the idea of this becoming a platform. But for anything actually useful I can think of, persistent storage between chats is needed. My understanding is this requires storing data on my servers, and therefor authenticating chatters with OAuth.

That I’m struggling with. One issue I recently came across, the docs[0] say to “declare auth requirements in the first-class securitySchemes field on each tool”, and give this example:

server.registerTool(
  "search",
  {
    title: "Public Search",
    description: "Search public documents.",
    inputSchema: {
      type: "object",
      properties: { q: { type: "string" } },
      required: ["q"],
    },
    securitySchemes: [
      { type: "noauth" },
      { type: "oauth2", scopes: ["search.read"] },
    ],
  },
  async ({ input }) => {
    return {
      content: [{ type: "text", text: `Results for ${input.q}` }],
      structuredContent: {},
    };
  }
);

However, the securitySchemes field doesn’t exist in the example’s library[1]. Likewise it doesn’t exist in the FastMCP Python library. Am I crazy? Someone please explain what I’m missing.

PS I haven’t even been able to get my Apps SDK app to connect without a vague error. Looking forward to someone putting out a real tutorial for us MCP & OAuth first timers.

PSS I think it would be amazing if ChatGPT exposed a persistent storage method through the Apps SDK. When someone downloads an iPhone app it can store data for future uses, without requiring the user to connect to a remote server and painstakingly create an account.

[0] developers.openai [DOT] com/apps-sdk/build/auth
[1] github [DOT] com/modelcontextprotocol/typescript-sdk/blob/0e482dbd293b4dd260379ef97b8f74e07474fd8b/src/server/mcp.ts#L789

Also it’s nuts that links aren’t allowed on this forum for discussing an API lol

gusdeoliveira · October 25, 2025, 9:02pm

We are not crazy, I also noticed this while building my apps, I thought it was related to the MCP sdk for Node, but it seems is the same for FastMCP. Interesting that I couldn`t find complaints about this issue anywhere else.

chulkilee · October 30, 2025, 5:19pm

You’re not alone - the latest spec doesn’t specify securitySchemes

OpenAI proposed it to MCP - but it’s not the part of the spec yet.

github.com/modelcontextprotocol/modelcontextprotocol

SEP-1488: securitySchemes in Tool Metadata for Mixed-Auth Servers

opened 12:38AM - 18 Sep 25 UTC

thiago-openai

auth security SEP draft

# SEP: securitySchemes in Tool Metadata for Mixed-Auth Servers Authors: Duke Ki…m (duke@openai.com), Thiago Hirai (thiago@openai.com) Status: Draft Sponsor: Nick Cooper (nickc@openai.com) Type: Standards Track Created: 2025-09-17 ## Summary We propose adding an optional securitySchemes field to MCP tool descriptors. This makes it possible for a server to mark which tools are open to everyone and which need auth. Clients can then: - Show clear UI labels (e.g. “Public” vs. “Requires sign-in”). - Ask users to sign in before calling protected tools. - Pick between public and authenticated versions of the same tool. This is a small, backward-compatible change. For now, we support just two scheme types: - "noauth" → tool can be called without credentials - "oauth2" → tool needs OAuth 2.0 (with optional scopes list) More scheme types can be added later without changing the shape of the field. ## Motivation Right now, clients only discover auth needs by trying and failing, or by reading docs. This isn’t great. By declaring securitySchemes per tool, servers can: - Improve UX: Clients know upfront if a tool is public or needs auth. - Guide flows: Clients can prompt users for login before invoking a protected tool. - Reduce mistakes: Servers can mark tools as public vs. protected. - Stay flexible: Easy to add new auth schemes (API keys, mTLS, etc.) later. ## Design ### Tool Descriptor Change Each tool can include a new optional securitySchemes field in its tools/list response: ``` { "name": "get_weather", "title": "Weather Info", "description": "Get current weather for a location", "inputSchema": { "type": "object", "properties": { "location": { "type": "string" } }, "required": ["location"] }, "securitySchemes": [ { "type": "noauth" }, { "type": "oauth2", "scopes": ["weather.read"] } ] } ``` ### Field Definition `securitySchemes` (array, optional) - If missing → tool follows the server’s default policy. - If empty array → discouraged, same as missing. - If present with entries → lists supported auth schemes. #### Scheme types (so far): - noauth: no credentials required. - oauth2: needs OAuth2; can list scopes if relevant. ### Multiple Schemes - Tools can list both noauth and oauth2 to mean “works anonymously, but auth gives more features.” - Clients can pick any scheme they can satisfy, usually preferring authenticated. - Servers must enforce auth rules regardless of client metadata. ## Examples **Public with optional auth**: ``` { "name": "search", "title": "Public Search", "description": "Search public documents.", "inputSchema": { "type": "object", "properties": { "q": { "type": "string" } }, "required": ["q"] }, "securitySchemes": [ { "type": "noauth" }, { "type": "oauth2", "scopes": ["search.read"] } ] } ``` **Auth required**: ``` { "name": "create_doc", "title": "Create Document", "description": "Make a new doc in your account.", "inputSchema": { "type": "object", "properties": { "title": { "type": "string" } }, "required": ["title"] }, "securitySchemes": [ { "type": "oauth2", "scopes": ["docs.write"] } ] } ``` **No field (inherits server policy)**: ``` { "name": "status", "title": "Server Status", "description": "Basic health info.", "inputSchema": { "type": "object", "properties": {} } } ``` ## JSON Schema (informative) ``` { "$id": "https://modelcontextprotocol.io/schemas/tool.securitySchemes.v1", "type": "object", "properties": { "securitySchemes": { "type": "array", "items": { "oneOf": [ { "type": "object", "required": ["type"], "properties": { "type": { "const": "noauth" } } }, { "type": "object", "required": ["type"], "properties": { "type": { "const": "oauth2" }, "scopes": { "type": "array", "items": { "type": "string", "minLength": 1 }, "uniqueItems": true } } } ] } } }, "additionalProperties": true } ``` ## Compatibility - **Optional field** → no breaking changes. - Old clients ignore it and keep using runtime errors/docs to figure out auth. - Old servers just don’t send it. ## Security Notes - Declaring `noauth` makes public tools explicit and auditable. - Declaring `oauth2` with scopes helps clients request the right tokens. - This field is just metadata; servers still must enforce auth. - Misconfigurations (e.g. forgetting to require auth) are the main risk.

Edit: also Reference mentions _meta["securitySchemes"]

gusdeoliveira · October 31, 2025, 1:54am

Wouldn’t it be better to change the documentation to only include securitySchemes in _meta instead of proposing the change to MCP? That “legacy” implementation seems to work well with the Node SDK.

Topic		Replies	Views
🍄 Safeguarding Your ChatGPT Plugins: Best Practices for Security Plugins / Actions builders	4	5136	July 24, 2023
Help Needed with Correct Scope Configuration for OAuth with OpenAI Plugins / Actions builders plugin-development , api , oauth	6	1969	December 5, 2023
chatGPT missing name field in Documentation API	2	2258	March 15, 2023
Allowing users to add their own OpenAI API Keys - guidelines/policy? API	6	6774	December 20, 2023
We no longer require you to register your applications with OpenAI API	9	3002	May 4, 2023

Are ChatGPT docs lying about this MCP tool field existing?

Related topics