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
***Parameters:** The function parameters define the inputs needed to generate the prompt.
55
55
***Inferred Metadata:** By default:
56
56
* Prompt Name: Taken from the function name (`ask_about_topic`).
57
-
* Prompt Description: Taken from the function's docstring.
57
+
* Prompt Description: Taken from the summary of the function's docstring. If the docstring includes parameter descriptions (Google, NumPy, or Sphinx style), they populate each prompt argument's description in the MCP protocol (see [Argument Descriptions](#argument-descriptions)).
58
58
<Tip>
59
59
Functions with `*args` or `**kwargs` are not supported as prompts. This restriction exists because FastMCP needs to generate a complete parameter schema for the MCP protocol, which isn't possible with variable argument lists.
60
60
</Tip>
@@ -88,7 +88,7 @@ def data_analysis_prompt(
88
88
</ParamField>
89
89
90
90
<ParamFieldbody="description"type="str | None">
91
-
Provides the description exposed via MCP. If set, the function's docstring is ignored for this purpose
91
+
Provides the description exposed via MCP. If set, the function's docstring is ignored for the prompt description, though docstring-derived argument descriptions still apply (see [Argument Descriptions](#argument-descriptions)).
FastMCP parses your function's docstring to extract the prompt description and per-argument descriptions. Google, NumPy, and Sphinx styles are all supported:
dataset: URI or identifier of the dataset to analyze.
217
+
method: Type of analysis to perform (summary, detailed, etc).
218
+
"""
219
+
returnf"Please perform a '{method}' analysis on {dataset}."
220
+
```
221
+
222
+
The free-form text above the `Args` section — whether a single line or multiple paragraphs — becomes the prompt description, and each argument's docstring entry becomes the description on the corresponding `PromptArgument` in the MCP protocol. Sections like `Returns`, `Raises`, and `Example` are excluded from the description but otherwise ignored.
223
+
224
+
If an argument already has an explicit description — via `Annotated[x, "..."]` or `Field(description=...)` — that description takes precedence over the docstring. This makes it safe to adopt docstring-based descriptions incrementally: existing annotations keep working, and docstrings fill in the gaps.
Copy file name to clipboardExpand all lines: docs/servers/tools.mdx
+29-2Lines changed: 29 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,7 @@ def add(a: int, b: int) -> int:
36
36
37
37
When this tool is registered, FastMCP automatically:
38
38
- Uses the function name (`add`) as the tool name.
39
-
-Uses the function's docstring (`Adds two integer numbers...`) as the tool description.
39
+
-Parses the function's docstring for the tool description and, if present, per-parameter descriptions (see [Docstring Descriptions](#docstring-descriptions)).
40
40
- Generates an input schema based on the function's parameters and type annotations.
41
41
- Handles parameter validation and error reporting.
Provides the description exposed via MCP. If set, the function's docstring is ignored for this purpose
73
+
Provides the description exposed via MCP. If set, the function's docstring is ignored for the tool description, though docstring-derived parameter descriptions still apply (see [Docstring Descriptions](#docstring-descriptions)).
74
74
</ParamField>
75
75
76
76
<ParamFieldbody="tags"type="set[str] | None">
@@ -289,6 +289,33 @@ The default flexible validation mode is recommended for most use cases as it han
289
289
290
290
You can provide additional metadata about parameters in several ways:
291
291
292
+
#### Docstring Descriptions
293
+
294
+
<VersionBadgeversion="3.2.4" />
295
+
296
+
FastMCP parses your function's docstring to extract both the tool description and per-parameter descriptions. Google, NumPy, and Sphinx docstring styles are all supported — the parser tries each and uses whichever finds parameter descriptions:
297
+
298
+
```python
299
+
@mcp.tool
300
+
defprocess_image(
301
+
image_url: str,
302
+
resize: bool=False,
303
+
width: int=800,
304
+
) -> dict:
305
+
"""Process an image with optional resizing.
306
+
307
+
Args:
308
+
image_url: URL of the image to process.
309
+
resize: Whether to resize the image.
310
+
width: Target width in pixels.
311
+
"""
312
+
# Implementation...
313
+
```
314
+
315
+
The free-form text above the `Args` section — whether a single line or multiple paragraphs — becomes the tool description, and each parameter's docstring entry becomes the description for that parameter in the generated schema. Sections like `Returns`, `Raises`, and `Example` are excluded from the description but otherwise ignored.
316
+
317
+
If a parameter already has an explicit description — via `Annotated[x, "..."]` or `Field(description=...)` — that description takes precedence over the docstring. This makes it safe to adopt docstring-based descriptions incrementally: existing annotations keep working, and docstrings fill in the gaps.
0 commit comments