Skip to content

Prefer Pydantic model docstrings for tool schema descriptions#57

Merged
JohnRichard4096 merged 3 commits intomainfrom
feat/tool-desc
Apr 25, 2026
Merged

Prefer Pydantic model docstrings for tool schema descriptions#57
JohnRichard4096 merged 3 commits intomainfrom
feat/tool-desc

Conversation

@JohnRichard4096
Copy link
Copy Markdown
Member

@JohnRichard4096 JohnRichard4096 commented Apr 25, 2026

Summary by Sourcery

Clarify how Pydantic model docstrings and field descriptions are used in JSON Schema generation and ensure tools schema generation prefers model-level descriptions, while updating docs and metadata accordingly.

New Features:

  • Document Pydantic BaseModel best practices for tool parameters in both English and Chinese guides.

Enhancements:

  • Use Pydantic model class docstrings as the primary description for generated FunctionPropertySchema objects, optionally falling back to parameter-level descriptions.
  • Update simple_tool documentation to require descriptive Pydantic models for complex object structures.

Build:

  • Bump project version from 0.8.3 to 0.8.3.1.

Documentation:

  • Fix and refine multiple documentation code blocks, callouts, and formatting in suspend and builtins guides, and adjust ModelAdapter property headings.

@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented Apr 25, 2026

Reviewer's Guide

Adds Pydantic model docstring handling for tool schemas, updates documentation with best practices and formatting fixes, and bumps the patch version.

Sequence diagram for Pydantic model description resolution during tool schema generation

sequenceDiagram
    actor Developer
    participant simple_tool
    participant _python_type_to_property_schema
    participant _convert_pydantic_model_to_property_schema
    participant FunctionPropertySchema

    Developer->>simple_tool: define tool(address: UserAddress)
    simple_tool->>_python_type_to_property_schema: python_type=UserAddress, description="address param description" (optional)
    _python_type_to_property_schema->>_python_type_to_property_schema: has_desc = bool(description)
    alt python_type is Pydantic BaseModel
        _python_type_to_property_schema->>_convert_pydantic_model_to_property_schema: model_class=UserAddress, desc=description if has_desc else None
        _convert_pydantic_model_to_property_schema->>_convert_pydantic_model_to_property_schema: resolve description = model_class.__doc__ or desc or fallback
        _convert_pydantic_model_to_property_schema-->>FunctionPropertySchema: create(type="object", description=resolved description, ...)
    else other Python types
        _python_type_to_property_schema-->>FunctionPropertySchema: create schema with description (or "No description")
    end

    FunctionPropertySchema-->>simple_tool: parameter schema with final description
    simple_tool-->>Developer: registered tool with JSON Schema using Pydantic model docstring when available
Loading

File-Level Changes

Change Details Files
Use Pydantic model docstrings as JSON Schema descriptions, optionally falling back to existing parameter descriptions.
  • Extend _convert_pydantic_model_to_property_schema to accept an optional description parameter and use the model doc or fallback description when setting the schema description.
  • Update _python_type_to_property_schema to accept an optional description, track whether a description was explicitly provided, and pass it through when converting Pydantic models so function arg descriptions are only used when the model lacks a docstring.
src/amrita_core/tools/manager.py
Document Pydantic BaseModel best practices for tool parameters in both English and Chinese guides.
  • Add a new 'Pydantic Model Best Practices' section describing precedence of class docstrings over function arg descriptions and demonstrating correct use of Field descriptions.
  • Include a full example UserAddress model and process_address tool function showing how JSON Schema descriptions are derived.
  • Update simple_tool docstring to recommend providing a description on Pydantic models.
docs/guide/concepts/tool.md
docs/zh/guide/concepts/tool.md
src/amrita_core/tools/manager.py
Fix documentation formatting issues in suspend guides, builtins guide, and ModelAdapter API reference.
  • Adjust closing ::: markers indentation in English and Chinese suspend guides to render tip/admonition blocks correctly.
  • Fix fenced code block language and fence counts in the Chinese builtins guide XML example.
  • Normalize emphasis formatting for the 'protocol' property heading in ModelAdapter API reference (both English and Chinese).
docs/guide/concepts/suspend.md
docs/zh/guide/concepts/suspend.md
docs/zh/guide/builtins.md
docs/guide/api-reference/classes/ModelAdapter.md
docs/zh/guide/api-reference/classes/ModelAdapter.md
Bump project patch version to reflect the new behavior and docs.
  • Update project version from 0.8.3 to 0.8.3.1 in pyproject.toml.
pyproject.toml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@JohnRichard4096
Copy link
Copy Markdown
Member Author

@sourcery-ai title

@sourcery-ai sourcery-ai Bot changed the title Feat: Pydantic class comments Prefer Pydantic model docstrings for tool schema descriptions Apr 25, 2026
Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 3 issues, and left some high level feedback:

  • When using model_class.__doc__ as the schema description, consider stripping whitespace and handling empty/whitespace-only docstrings so you don't end up with blank descriptions (e.g., desc = (model_class.__doc__ or '').strip() or desc or f'Pydantic model {model_class.__name__}').
  • Several Markdown code fences in the docs were changed from language-tagged (e.g., python, xml) to bare ```/```` fences; if syntax highlighting is still desired, it would be better to keep the language tags while still resolving any nesting issues.
  • The changes to the ::: lines in the suspend guides (extra leading spaces before :::) may alter how callouts/admonitions render in your docs toolchain; double-check whether those spaces are necessary or should be removed to preserve the original layout.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- When using `model_class.__doc__` as the schema description, consider stripping whitespace and handling empty/whitespace-only docstrings so you don't end up with blank descriptions (e.g., `desc = (model_class.__doc__ or '').strip() or desc or f'Pydantic model {model_class.__name__}'`).
- Several Markdown code fences in the docs were changed from language-tagged (e.g., ```python, ```xml) to bare ```/```` fences; if syntax highlighting is still desired, it would be better to keep the language tags while still resolving any nesting issues.
- The changes to the `::: ` lines in the suspend guides (extra leading spaces before `:::`) may alter how callouts/admonitions render in your docs toolchain; double-check whether those spaces are necessary or should be removed to preserve the original layout.

## Individual Comments

### Comment 1
<location path="src/amrita_core/tools/manager.py" line_range="226-229" />
<code_context>

 def _convert_pydantic_model_to_property_schema(
-    model_class: type[BaseModel], globalns: dict[str, Any]
+    model_class: type[BaseModel], globalns: dict[str, Any], desc: str | None = None
 ) -> FunctionPropertySchema:
     """Convert a Pydantic model to FunctionPropertySchema recursively"""
</code_context>
<issue_to_address>
**suggestion:** Consider normalizing the model docstring before using it as the schema description.

Directly using `model_class.__doc__` can introduce leading/trailing whitespace or blank lines, depending on formatting. Consider normalizing it first, e.g. `(model_class.__doc__ or '').strip()`, before falling back to `desc` or the default so schema descriptions remain clean and consistent.
</issue_to_address>

### Comment 2
<location path="src/amrita_core/tools/manager.py" line_range="265-271" />
<code_context>

 def _python_type_to_property_schema(
-    python_type: Any, globalns: dict[str, Any], description: str = "No description"
+    python_type: Any,
+    globalns: dict[str, Any],
+    description: str | None = None,
 ) -> FunctionPropertySchema:
     """Convert Python type to FunctionPropertySchema with full JSON Schema support"""
     # Handle basic types
+    has_desc = bool(description)
+    description = description or "No description"
     if python_type is str:
</code_context>
<issue_to_address>
**question:** Empty-string descriptions are treated as missing and replaced with "No description"; clarify if this is intended.

Because `has_desc = bool(description)` and `description = description or "No description"`, an explicit empty-string description is treated the same as `None`: `has_desc` becomes `False`, the description is not forwarded to `_convert_pydantic_model_to_property_schema`, and it gets replaced with "No description". If you only need to distinguish `None` from "user provided", using `has_desc = description is not None` would keep explicit empty descriptions while still avoiding overriding model docstrings unless the caller supplies something.
</issue_to_address>

### Comment 3
<location path="docs/guide/concepts/suspend.md" line_range="318" />
<code_context>
 - Need to process chunks but don't want to write manual loops? Use **callback mode**, start with `chat.begin()` then `await chat` to wait for completion.
 - Need streaming output to terminal or WebSocket? Use **iterator mode** with the `async with chat:` context manager.
 - Regardless of mode, outer suspension (`wait_to_suspend`) works normally.
-:::
+  :::

</code_context>
<issue_to_address>
**issue (bug_risk):** The added indentation before `:::` may break the intended block/admonition formatting.

This moved `:::` from column 0 to two-space indentation, which may stop the docs tooling from recognizing the block/admonition. If the change wasn’t intentional, please restore it to start at column 0.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread src/amrita_core/tools/manager.py
Comment thread src/amrita_core/tools/manager.py Outdated
Comment thread docs/guide/concepts/suspend.md Outdated
@cloudflare-workers-and-pages
Copy link
Copy Markdown

cloudflare-workers-and-pages Bot commented Apr 25, 2026

Deploying amritacore with  Cloudflare Pages  Cloudflare Pages

Latest commit: bf2e2f1
Status: ✅  Deploy successful!
Preview URL: https://89c90037.amritacore.pages.dev
Branch Preview URL: https://feat-tool-desc.amritacore.pages.dev

View logs

@JohnRichard4096 JohnRichard4096 merged commit 3161e90 into main Apr 25, 2026
3 checks passed
@JohnRichard4096 JohnRichard4096 deleted the feat/tool-desc branch April 25, 2026 04:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant