Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add SEP-1034 default values support for elicitation#2545

Merged
jlowin merged 1 commit intomainfrom
sep-1034-elicitation-defaults
Dec 4, 2025
Merged

Add SEP-1034 default values support for elicitation#2545
jlowin merged 1 commit intomainfrom
sep-1034-elicitation-defaults

Conversation

@jlowin
Copy link
Member

@jlowin jlowin commented Dec 4, 2025

Adds tests and documentation for SEP-1034 default values in elicitation schemas. FastMCP automatically supports this via Pydantic's Field(default=...) - no code changes needed.

Closes #2544

- Add comprehensive tests for default values in elicitation schemas
- Document default values support in elicitation docs
- Confirms FastMCP automatically supports defaults via Pydantic

Closes #2544
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 4, 2025

Walkthrough

Documentation was added to the elicitation guide describing how to use Pydantic Field(default=...) to provide default values for elicitation fields. The new "Default Values" section covers primitive types, integers, numbers, booleans, and enums, and includes code examples demonstrating a TaskDetails model with a defaulted priority parameter and its usage within an elicitation flow. This documentation confirms existing support for field defaults through Pydantic without requiring additional DX changes.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description check ⚠️ Warning The description is sparse and lacks proper completion of the provided template checklist items; required checkboxes are not marked and documentation/testing status is unclear. Complete all checklist items in the description template, explicitly checking off relevant items and confirming that tests, documentation, and self-review have been completed.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: adding documentation and testing for SEP-1034 default values support in elicitation schemas.
Linked Issues check ✅ Passed The PR successfully adds documentation confirming and explaining the automatic support of elicitation defaults via Pydantic Field(default=...), directly addressing the objectives in issue #2544.
Out of Scope Changes check ✅ Passed The changes appear to be purely documentation additions focused on elicitation defaults, which aligns with the PR's stated objective of documenting SEP-1034 support.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch sep-1034-elicitation-defaults

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (3)
docs/servers/elicitation.mdx (3)

283-295: Clarify that defaults are Pydantic-specific; address the dataclass/TypedDict gap.

Line 256 indicates that dataclasses, TypedDicts, and Pydantic models all work for structured responses, but your defaults section only demonstrates Pydantic's Field(default=...). This leaves users uncertain whether defaults are supported for dataclasses (via field(default=...)) or TypedDict.

Since the PR objectives emphasize documenting automatic support through Pydantic, consider either:

  1. Explicitly note that defaults via Field(default=...) are Pydantic-specific, or
  2. Show equivalent patterns for dataclasses if they're also supported

Add a sentence after line 294 to clarify scope:

Fields with default values are automatically marked as optional (not included in the `required` list), so users can accept the default or provide their own value.
+
+**Note:** Default values via `Field(default=...)` are supported specifically for Pydantic models. If using dataclasses or TypedDicts, use `field(default=...)` or equivalent patterns.

296-316: Add a comment explaining Field() vs. simple assignment in Pydantic.

Your code example correctly uses Field(default=..., description=...) but new users may wonder why you're not using simple assignment like priority: Priority = Priority.MEDIUM. Clarify that Field() is used when you need to attach metadata (like description for the form label) along with the default value.

Add an explanatory comment to the model definition:

class TaskDetails(BaseModel):
    title: str = Field(description="Task title")
    description: str = Field(default="", description="Task description")
+  # Field() allows us to attach metadata like 'description' alongside the default value
    priority: Priority = Field(default=Priority.MEDIUM, description="Task priority")

Alternatively, add a note after the code block explaining this distinction.


315-317: Add expected behavior and next steps to complete the section.

The section ends without explaining the expected user experience: how clients display these defaults, what happens if a user modifies a default value, or where to go next. Per coding guidelines, sections should end with next steps or related information.

Add context after the code example (after line 316):

When you provide a default value, the client will pre-populate the form field with that value. Users can either accept the default and submit, or modify it to provide their own input. This reduces friction for common scenarios.

**Next:** Learn about gathering information progressively with [Multi-Turn Elicitation](#multi-turn-elicitation).

This gives users clarity on behavior and guides them to the next relevant section.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7f8a010 and 52ded48.

⛔ Files ignored due to path filters (1)
  • tests/client/test_elicitation.py is excluded by none and included by none
📒 Files selected for processing (1)
  • docs/servers/elicitation.mdx (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
docs/**/*.mdx

📄 CodeRabbit inference engine (docs/.cursor/rules/mintlify.mdc)

docs/**/*.mdx: Use clear, direct language appropriate for technical audiences
Write in second person ('you') for instructions and procedures in MDX documentation
Use active voice over passive voice in MDX technical documentation
Employ present tense for current states and future tense for outcomes in MDX documentation
Maintain consistent terminology throughout all MDX documentation
Keep sentences concise while providing necessary context in MDX documentation
Use parallel structure in lists, headings, and procedures in MDX documentation
Lead with the most important information using inverted pyramid structure in MDX documentation
Use progressive disclosure in MDX documentation: present basic concepts before advanced ones
Break complex procedures into numbered steps in MDX documentation
Include prerequisites and context before instructions in MDX documentation
Provide expected outcomes for each major step in MDX documentation
End sections with next steps or related information in MDX documentation
Use descriptive, keyword-rich headings for navigation and SEO in MDX documentation
Focus on user goals and outcomes rather than system features in MDX documentation
Anticipate common questions and address them proactively in MDX documentation
Include troubleshooting for likely failure points in MDX documentation
Provide multiple pathways (beginner vs advanced) but offer an opinionated path to avoid overwhelming users in MDX documentation
Always include complete, runnable code examples that users can copy and execute in MDX documentation
Show proper error handling and edge case management in MDX code examples
Use realistic data instead of placeholder values in MDX code examples
Include expected outputs and results for verification in MDX code examples
Test all code examples thoroughly before publishing in MDX documentation
Specify language and include filename when relevant in MDX code examples
Add explanatory comments for complex logic in MDX code examples
Document all API...

Files:

  • docs/servers/elicitation.mdx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Run tests: Python 3.10 on windows-latest
  • GitHub Check: label-issue-or-pr

@marvin-context-protocol marvin-context-protocol bot added the documentation Updates to docs, examples, or guides. Primary change is documentation-related. label Dec 4, 2025
@jlowin jlowin merged commit acf4db0 into main Dec 4, 2025
15 checks passed
@jlowin jlowin deleted the sep-1034-elicitation-defaults branch December 4, 2025 15:43
@jlowin jlowin added the enhancement Improvement to existing functionality. For issues and smaller PR improvements. label Dec 4, 2025
@marvin-context-protocol
Copy link
Contributor

Test Failure Analysis

Summary: The integration test test_call_tool_list_commits in the newly added tests/integration_tests/test_github_mcp_remote.py is timing out and receiving a 429 (Too Many Requests) rate limit error from GitHub's Copilot MCP API.

Root Cause:

  1. The test file tests/integration_tests/test_github_mcp_remote.py was added in this commit (appears to be unintentional, as the PR description only mentions elicitation documentation changes)
  2. The test attempts to call the GitHub Copilot MCP API at https://api.githubcopilot.com/mcp/
  3. The API is returning a 429 rate limit error during test cleanup, causing the test to timeout after 15 seconds
  4. This is blocking the integration tests workflow from passing

Suggested Solution:

Option 1 (Recommended): Remove the unrelated test file

  • The test file appears to have been added unintentionally, as this PR is about elicitation default values documentation
  • Remove tests/integration_tests/test_github_mcp_remote.py from this commit

Option 2: If the test file was intentionally added, fix the rate limiting issue:

  1. Add retry logic with exponential backoff for 429 errors
  2. Consider using pytest-retry or similar to automatically retry failed tests
  3. Add a longer timeout specifically for this test (currently using the global 15s timeout)
  4. Consider marking this specific test as @pytest.mark.flaky since it depends on an external API

Option 3: Skip this test in CI

  • Add @pytest.mark.skip(reason="Flaky due to GitHub API rate limits") to the failing test
Detailed Analysis

Relevant Log Excerpt

[31mFAILED[0m tests/integration_tests/test_github_mcp_remote.py::[1mTestGithubMCPRemote::test_call_tool_list_commits[0m - Failed: Timeout (>15.0s)
...
httpx.HTTPStatusError: Client error '429 Too Many Requests' for url 'https://api.githubcopilot.com/mcp/'

Code Context

The test at tests/integration_tests/test_github_mcp_remote.py:99 is attempting to:

  1. Connect to GitHub's Copilot MCP API
  2. Call the list_commits tool with owner="jlowin" and repo="fastmcp"
  3. Validate the response structure

The timeout occurs because the test hangs waiting for a response, and then during cleanup, receives a 429 error.

Related Issue

This PR was meant to close #2544 (SEP-1034 elicitation defaults documentation) and should only contain documentation changes. The test file appears to be unrelated to this PR's purpose.

Related Files
  • tests/integration_tests/test_github_mcp_remote.py: Newly added test file causing the failure (line 99: test_call_tool_list_commits)
  • .github/workflows/run-tests.yml: Integration test workflow configuration (line 101-107: runs integration tests with FASTMCP_GITHUB_TOKEN)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Updates to docs, examples, or guides. Primary change is documentation-related. enhancement Improvement to existing functionality. For issues and smaller PR improvements.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SEP-1034: elicitation defaults

1 participant

Comments