Let FastMCPError propagate from dependencies

[chrisguidry]

When a dependency raises ToolError or other FastMCPError subclasses, they
were getting wrapped in RuntimeError with a generic "Failed to resolve
dependency" message. This made it hard to use ToolError for validation
in dependencies.

Now FastMCPError subclasses propagate unchanged, matching the pattern
used elsewhere in the codebase.

Closes #2633

🤖 Generated with Claude Code

[coderabbitai]

Walkthrough

The change modifies exception handling in the dependency resolution process to preserve FastMCPError exceptions and their subclasses (such as ToolError and ResourceError) instead of wrapping them as RuntimeError. Previously, all exceptions during dependency resolution were uniformly converted to RuntimeError with context information. Now, when a FastMCPError is raised during dependency resolution, it propagates unchanged. Other exception types continue to be wrapped as RuntimeError with the dependency resolution failure context, maintaining the previous error envelope behavior for non-FastMCP errors.

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description explains the problem, solution, and includes the issue reference and AI tool attribution. However, it doesn't follow the provided template with the Contributors Checklist and Review Checklist sections.	Add the Contributors Checklist and Review Checklist sections from the template to ensure compliance with repository standards.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: allowing FastMCPError exceptions to propagate from dependency resolution instead of being wrapped.
Linked Issues check	✅ Passed	The PR implements the requested enhancement from #2633 by allowing FastMCPError subclasses to propagate unchanged during dependency resolution instead of being wrapped in RuntimeError.
Out of Scope Changes check	✅ Passed	All changes are scoped to the dependency resolution error handling and directly address issue #2633 without introducing unrelated modifications.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 2633-toolerror-in-depends

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ede8ff6 and 63bc9cb.

⛔ Files ignored due to path filters (1)

• tests/server/test_dependencies.py is excluded by none and included by none

📒 Files selected for processing (1)

• src/fastmcp/server/dependencies.py (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

src/fastmcp/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

src/fastmcp/**/*.py: Write Python code with ≥3.10 type annotations required throughout
Never use bare except - be specific with exception types

Files:

• src/fastmcp/server/dependencies.py

🧠 Learnings (3)

📓 Common learnings

Learnt from: CR
Repo: jlowin/fastmcp PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-17T03:06:14.522Z
Learning: Applies to src/fastmcp/**/*.py : Never use bare except - be specific with exception types

📚 Learning: 2025-12-17T03:06:14.522Z

Learnt from: CR
Repo: jlowin/fastmcp PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-17T03:06:14.522Z
Learning: Applies to src/fastmcp/**/*.py : Never use bare except - be specific with exception types

Applied to files:

• src/fastmcp/server/dependencies.py

📚 Learning: 2025-12-17T03:06:14.522Z

Learnt from: CR
Repo: jlowin/fastmcp PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-17T03:06:14.522Z
Learning: Applies to src/fastmcp/**/__init__.py : Be intentional about re-exports; core types that define a module's purpose should be exported; specialized features can live in submodules; only re-export to fastmcp.* for fundamental types

Applied to files:

• src/fastmcp/server/dependencies.py

🧬 Code graph analysis (1)

src/fastmcp/server/dependencies.py (1)

src/fastmcp/exceptions.py (1)

• FastMCPError (6-7)

⏰ 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). (4)

• GitHub Check: Run tests: Python 3.10 on ubuntu-latest
• GitHub Check: Run tests with lowest-direct dependencies
• GitHub Check: Run tests: Python 3.13 on ubuntu-latest
• GitHub Check: Run tests: Python 3.10 on windows-latest

🔇 Additional comments (2)

src/fastmcp/server/dependencies.py (2)

24-24: LGTM! Clean import addition.

The import of FastMCPError is necessary for the enhanced exception handling below and follows the module's import organization pattern.

---

192-195: Exception handling correctly isolates and propagates FastMCPError subclasses.

The implementation properly:

• Catches specific FastMCPError before general Exception, ensuring appropriate handlers execute
• Uses bare raise to preserve the original exception traceback
• Wraps unexpected errors with helpful context about which dependency failed
• Follows the coding guideline to always use specific exception types

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[marvin-context-protocol]

Test Failure Analysis

Summary: The workflow failure was caused by a transient GitHub API timeout during the uv installation step, not by the code changes in this PR.

Root Cause: The astral-sh/setup-uv@v7 action attempted to fetch the latest uv version from GitHub's API, which timed out after 10 seconds. This prevented the test job from even starting. All other jobs in the same workflow run passed successfully, confirming the code changes are working correctly.

Suggested Solution: Simply re-run the failed workflow. This is a false negative caused by external infrastructure issues. No code changes are needed.

Detailed Analysis

The failure occurred in the "Run tests: Python 3.10 on ubuntu-latest" job during step 2 (Install uv):

2025-12-18T16:29:30.1243198Z Could not determine uv version from uv.toml or pyproject.toml. Falling back to latest.
2025-12-18T16:29:30.1245960Z Getting latest version from GitHub API...
2025-12-18T16:29:40.1559570Z ##[error]Github API request failed while getting latest release. Check the GitHub status page for outages. Try again later.
2025-12-18T16:29:40.1572395Z ##[error]Connect Timeout Error

The workflow never reached the actual test execution phase. All other jobs in the same run succeeded:

• ✅ Run integration tests
• ✅ Run tests with lowest-direct dependencies
• ✅ Run tests: Python 3.13 on ubuntu-latest
• ✅ Run tests: Python 3.10 on windows-latest
• ❌ Run tests: Python 3.10 on ubuntu-latest (infrastructure failure)

Optional Future Improvement: Consider pinning a specific uv version in the workflow to avoid reliance on GitHub API calls during CI, making the workflow more resilient to API outages.

Related Files

• .github/workflows/ - Workflow files using astral-sh/setup-uv@v7
• pyproject.toml - Could optionally specify a uv version to avoid API lookups