Merge remote-tracking branch 'origin/main' into structured-output-typing-dict

Author: Kludex

.github/workflows/main.yml

@@ -11,7 +11,7 @@ permissions:
 
 jobs:
   checks:
-    uses: ./.github/workflows/shared.yml
+    uses: $/.github/workflows/shared.yml
 
   all-green:
     if: always()

.github/workflows/publish-pypi.yml

@@ -38,7 +38,7 @@ jobs:
           path: dist/
 
   checks:
-    uses: ./.github/workflows/shared.yml
+    uses: $/.github/workflows/shared.yml
 
   pypi-publish:
     name: Upload release to PyPI

.pre-commit-config.yaml

@@ -6,8 +6,8 @@ repos:
     hooks:
       - id: end-of-file-fixer
 
-  - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: v3.1.0
+  - repo: https://github.com/rbubley/mirrors-prettier
+    rev: v3.9.10
     hooks:
       - id: prettier
         types_or: [yaml, json5]

docs/advanced/low-level-server.md

@@ -61,7 +61,7 @@ asyncio.run(main())
 The same text the `@mcp.tool()` version produced. Two honest differences:
 
 * `result.structured_content` is `None`. The high-level server wraps a `-> str` into `{"result": ...}` for you; here nobody builds what you didn't build.
-* `list_tools` returns the schema **you** typed, character for character. The high-level version had `"title": "Query"` on every property and a `"title": "search_booksArguments"` at the root: Pydantic artifacts. Down here, if it's on the wire, you put it there.
+* `list_tools` returns the schema **you** typed, character for character. Down here, if it's on the wire, you put it there.
 
 In a test you skip uvicorn and the port: `Client(server)` takes a low-level `Server` in-process exactly like it takes an `MCPServer`, and **[Testing](../get-started/testing.md)** is that pattern.
 

docs/client/index.md

@@ -72,11 +72,10 @@ and `tool.input_schema` is the JSON Schema the server derived from the function'
 {
   "type": "object",
   "properties": {
-    "query": {"title": "Query", "type": "string"},
-    "limit": {"default": 10, "title": "Limit", "type": "integer"}
+    "query": {"type": "string"},
+    "limit": {"default": 10, "type": "integer"}
   },
-  "required": ["query"],
-  "title": "search_booksArguments"
+  "required": ["query"]
 }
 ```
 

docs/handlers/context.md

@@ -30,10 +30,9 @@ This is the part to internalise. Here is the input schema `tools/list` reports f
 {
   "type": "object",
   "properties": {
-    "query": {"title": "Query", "type": "string"}
+    "query": {"type": "string"}
   },
-  "required": ["query"],
-  "title": "search_booksArguments"
+  "required": ["query"]
 }
 ```
 

docs/handlers/dependencies.md

@@ -28,10 +28,9 @@ Here is the input schema `tools/list` reports for `reserve_book`:
 {
   "type": "object",
   "properties": {
-    "title": {"title": "Title", "type": "string"}
+    "title": {"type": "string"}
   },
-  "required": ["title"],
-  "title": "reserve_bookArguments"
+  "required": ["title"]
 }
 ```
 

docs/handlers/lifespan.md

@@ -32,10 +32,9 @@ Nothing new. `ctx` is a **Context** parameter, so the SDK injects it and it neve
 {
   "type": "object",
   "properties": {
-    "genre": {"title": "Genre", "type": "string"}
+    "genre": {"type": "string"}
   },
-  "required": ["genre"],
-  "title": "count_booksArguments"
+  "required": ["genre"]
 }
 ```
 

docs/servers/structured-output.md

@@ -19,10 +19,9 @@ Because of it, the tool the SDK sends during `tools/list` carries an `output_sch
 ```json
 {
   "properties": {
-    "result": {"title": "Result", "type": "integer"}
+    "result": {"type": "integer"}
   },
   "required": ["result"],
-  "title": "get_temperatureOutput",
   "type": "object"
 }
 ```
@@ -59,9 +58,9 @@ Declare the shape as a Pydantic `BaseModel` and return an instance:
 ```json
 {
   "properties": {
-    "temperature": {"description": "Degrees Celsius.", "title": "Temperature", "type": "number"},
-    "humidity": {"description": "Relative humidity, 0 to 1.", "title": "Humidity", "type": "number"},
-    "conditions": {"title": "Conditions", "type": "string"}
+    "temperature": {"description": "Degrees Celsius.", "type": "number"},
+    "humidity": {"description": "Relative humidity, 0 to 1.", "type": "number"},
+    "conditions": {"type": "string"}
   },
   "required": ["temperature", "humidity", "conditions"],
   "title": "WeatherData",
@@ -125,20 +124,19 @@ A `list[...]` isn't a JSON object either, so it gets the `{"result": ...}` wrapp
   "$defs": {
     "WeatherData": {
       "properties": {
-        "temperature": {"title": "Temperature", "type": "number"},
-        "humidity": {"title": "Humidity", "type": "number"},
-        "conditions": {"title": "Conditions", "type": "string"}
+        "temperature": {"type": "number"},
+        "humidity": {"type": "number"},
+        "conditions": {"type": "string"}
       },
       "required": ["temperature", "humidity", "conditions"],
       "title": "WeatherData",
       "type": "object"
     }
   },
   "properties": {
-    "result": {"items": {"$ref": "#/$defs/WeatherData"}, "title": "Result", "type": "array"}
+    "result": {"items": {"$ref": "#/$defs/WeatherData"}, "type": "array"}
   },
   "required": ["result"],
-  "title": "get_forecastOutput",
   "type": "object"
 }
 ```
@@ -158,7 +156,6 @@ Ask for a two-day forecast and `structured_content` is `{"result": [{...}, {...}
 ```json
 {
   "additionalProperties": {"type": "number"},
-  "title": "get_temperaturesDictOutput",
   "type": "object"
 }
 ```
@@ -169,7 +166,7 @@ result.structured_content  # {"London": 16.2, "Reykjavik": 4.4}
 
 The keys must be `str`. A `dict[int, float]` can't be a JSON object, so it falls back to the `{"result": ...}` wrapper.
 
-Dictionary results use Pydantic's `TypeAdapter` for validation and serialization. If you inspect a tool's `FuncMetadata.output_model`, it holds the dictionary type annotation with its schema title.
+Dictionary results use Pydantic's `TypeAdapter` for validation and serialization. If you inspect a tool's `FuncMetadata.output_model`, it holds the dictionary type annotation itself.
 
 ## Validation
 

docs/servers/tools.md

@@ -24,15 +24,14 @@ From those type hints the SDK generates a JSON Schema and sends it to the client
 {
   "type": "object",
   "properties": {
-    "query": {"title": "Query", "type": "string"},
-    "limit": {"title": "Limit", "type": "integer"}
+    "query": {"type": "string"},
+    "limit": {"type": "integer"}
   },
-  "required": ["query", "limit"],
-  "title": "search_booksArguments"
+  "required": ["query", "limit"]
 }
 ```
 
-Both arguments are in `required` because neither has a default. You'll fix that in a moment. (The `title` keys are Pydantic artifacts; the properties, their types, and `required` are the contract.)
+Both arguments are in `required` because neither has a default. You'll fix that in a moment. There are no `title` keys: the ones Pydantic would derive from the class and field names only repeat them. A title you set yourself with `Field(title=...)` is kept.
 
 There is no `$schema` key either: MCP treats a schema without one as **JSON Schema 2020-12**, which is what Pydantic generates, so there is nothing to choose until you write schemas by hand on the **[low-level Server](../advanced/low-level-server.md#the-dialect-is-json-schema-2020-12)**.
 
@@ -79,11 +78,10 @@ The schema follows:
 {
   "type": "object",
   "properties": {
-    "query": {"title": "Query", "type": "string"},
-    "limit": {"default": 10, "title": "Limit", "type": "integer"}
+    "query": {"type": "string"},
+    "limit": {"default": 10, "type": "integer"}
   },
-  "required": ["query"],
-  "title": "search_booksArguments"
+  "required": ["query"]
 }
 ```