MCPB tools should include input/output schema

[asklar]

It would be beneficial to models to know not just the description of tools but their input/output schemas.

Proposal

Add optional inputSchema and outputSchema members to the tools object, matching the output from the tools/list message.
title is also potentially valuable, and keeps in line with tools/list.

Example

{
// ...
  "tools": [
    {
      "name": "get_weather_data",
      "title": "Weather Data Retriever",
      "description": "Get current weather data for a location",
      "inputSchema": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "City name or zip code"
          }
        },
        "required": ["location"]
      },
      "outputSchema": {
        "type": "object",
        "properties": {
          "temperature": {
            "type": "number",
            "description": "Temperature in celsius"
          },
          "conditions": {
            "type": "string",
            "description": "Weather conditions description"
          },
          "humidity": {
            "type": "number",
            "description": "Humidity percentage"
          }
        },
        "required": ["temperature", "conditions", "humidity"]
      }
    }
  ]
  // ...
}

[MarshallOfSound]

@asklar we find quite a few servers have semi-dynamic tools and schemas depending on user, connectivity, in these cases we see more and more servers using tools_generated: true. I think adding even more information that could drift / differ will result in even more folks just using that generated flag.

Is there a usecase for this information that isn't solved by just connecting to the MCPB and calling list_tools. i.e. what scenario do you need this data for but aren't connecting to the MCP?

[asklar]

@MarshallOfSound We want to ensure code isn't run locally unless absolutely needed, so any kind of dynamic discovery runs afoul of that. On Windows, we'll enforce static tool lists (see Securing the Model Context Protocol: Building a safer agentic future on Windows)

Servers’ definition of tools cannot be changed at runtime

Because the OS will manage consent (so additional consent prompts may show up before 3rd party code runs), we need to be sure we don't show those consent dialogs until the model decides to call a tool, at which point the server should be launched (i.e. not before).

[asklar]

We discussed this offline - this will for now be part of the new _meta property and specifically be scoped to Windows's implementation. Windows docs will follow on final guidance.
Keeping this open for when we want to promote this to a standard property instead of _meta.