Skip to main content
Identifying a real problem is often the most valuable contribution you can make to FastMCP. Start with a clear issue: a reproducible bug or a concrete use case that current behavior does not support. That report is a contribution on its own, and maintainers can handle the implementation. If your issue leads to a merged change implemented by a maintainer, you receive contributor credit for that change. This guide covers which changes FastMCP accepts, how contributions enter review, and how to develop and validate a change. Report vulnerabilities privately through the security policy. Community participation follows the Code of Conduct.

​
Choose a contribution

A useful bug report states the problem, includes a minimal reproducible example, and explains the expected behavior. Search existing issues and pull requests first, including closed PRs: the contribution gate may have closed a proposal while it waits for assignment. Simple, scoped bug fixes, documentation improvements, and authentication providers are welcome. Enhancements need a maintainer-approved design in an issue before implementation. Third-party integrations generally belong in a separate package. For a proposed in-repository community module, read Contrib Modules and discuss its maintenance model first. FastMCP prioritizes readable Python, clear APIs, and fixes at the source of a problem. A working implementation can still be unsuitable if it changes an intentional contract or adds a workaround that the framework must maintain indefinitely.

​
Issues and assignment

External PRs must link an issue with an auto-close keyword such as Fixes #123. The author must also be assigned to that issue, unless it carries the prs welcome label. You can open a linked PR before assignment; it waits with a failing gate check while maintainers evaluate it. A PR without a valid issue link is closed. Assignment commits maintainers to reviewing a contribution, not to merging it. Assigning an author reruns the gate and can reopen their previously closed PR. Update that PR rather than opening a duplicate. The issue reporter has first claim on implementing the fix; an open issue does not by itself mean a maintainer has accepted a proposed solution. Do not post comments just to claim an issue or ask to be assigned. A concise report, a scoped linked PR, or a substantive design discussion gives maintainers something concrete to evaluate. The gate exempts maintainers and trusted contributors. Draft PRs are checked when marked ready for review.

​
Contributor credit

This policy recognizes community contributions. Maintainers are generally exempt from supplemental credit checks: reporting, reviewing, or backporting another maintainer’s change does not require adding them as a contributor. Routine backports preserve existing community attribution without repeating the credit review. If your issue leads to a merged change implemented by a maintainer, we credit you as a contributor to that change. This applies to bug reports, enhancement requests, and documentation issues. You do not need to write code, diagnose the root cause, or propose an implementation: identifying the problem or explaining the use case is a contribution. Credit includes co-authorship of the merged commit and attribution alongside the PR author in the release notes. If this is your first contribution to FastMCP, you are included under New Contributors in the release that first includes the change. Maintainers and agents working on their behalf handle this as part of preparing, merging, and releasing the PR. Opening an issue does not guarantee that it will be implemented. The PR author adds a Co-authored-by trailer to the implementation commit and the PR description, using an email associated with your GitHub account. Prefer your GitHub-provided noreply address; if your preferred identity is unclear, ask rather than guessing an email. Honor requests to omit attribution. Preserve attribution for anyone whose implementation work is carried forward, and credit each issue author whose report contributed to the change. Closing an unrelated or duplicate issue alone does not earn co-authorship. The merging maintainer preserves those trailers through the chosen merge strategy and verifies the landed commit. For a squash merge, explicitly include them in the final squash commit message. The release author carries that recorded attribution into the release notes and verifies the preview, investigating individual PRs or issues only when credit appears missing or inconsistent. The same completed notes feed the GitHub release and docs changelog. A thank-you in the PR description alone does not fulfill this policy.

​
Working with an agent

AI assistance is welcome under the same standards as other contributions. You remain responsible for understanding the change, verifying its behavior, and responding to review. Avoid generated boilerplate that obscures the problem or substitutes speculation for a reproduction. Have your agent read AGENTS.md. It contains the required checks, repository conventions, and a table routing tasks to the repository skills. Use the testing and review procedures on your own change before submitting it. Skills live in .agents/skills/, with discovery links in .claude/skills/.

​
Set up the repository

Use Python 3.10 or newer and uv. Fork the repository for an external contribution, clone your fork, then install the workspace dependencies and commit hooks:
The workspace contains several distributions. Most framework code lives in fastmcp_slim/fastmcp/; fastmcp_tasks/ and fastmcp_remote/ hold the task and remote packages. Tests live under tests/, and the documentation source lives under docs/. Extend the tests nearest the behavior you change. Target main for current development. Fixes specifically for older supported lines target their maintenance branch, such as release/3.x or release/2.x.

​
Implement and verify

Establish what the public API promises before writing a regression test. A test that fails on existing code only demonstrates a difference; docs, protocol requirements, history, and maintainer decisions establish whether that difference is a bug. If the intended behavior is unclear, settle that question in the issue. Keep the change scoped to one problem and fix the causal code path. Avoid speculative explanations, sweeping unrelated changes, and generated boilerplate; maintainers may close contributions that do not meet these requirements. Trace the callers and adjacent behavior that share it. In particular, preserve supported explicit overrides when changing a default. Use full type annotations, specific exceptions, and the surrounding code’s conventions. For a bug fix, run the regression on unchanged code and confirm it fails for the reported reason, then run it with the fix. Assert the actual result and relevant types. Exercise neighboring supported behavior as well. The Testing Guide covers fixtures, protocol tests, HTTP helpers, and subprocess tests. Before committing, run these commands in order, followed by the static checks:
Prek runs lint, formatting, typing, and other repository checks; pytest is separate. Hooks also run on commit. Fix failures before committing, and use a new commit rather than amending to repair a failed hook.

​
Update documentation

Document new capabilities and changes to public behavior alongside the implementation. Explain the use case before the code, include imports, and keep examples runnable. Add new pages to docs/docs.json so they appear in navigation. When a setting changes, update docs/more/settings.mdx. Edit source docstrings for API-reference changes. Do not manually edit docs/python-sdk/, docs/public/schemas/, or the generated MCP server configuration schema; automation maintains those outputs. The docs/v2/ and docs/v3/ trees are frozen version snapshots, apart from maintenance release changelog entries. Check documentation links and examples from the repository root:
just provides convenience commands. Without it, run npx --yes mint@latest broken-links from docs/. Preview rendering with just docs, or run npx --yes mint@latest dev from that directory. The docs tests check Python syntax and FastMCP imports; execute changed examples too, since those checks do not prove behavior. The live site serves published-docs, so merging a docs change into main does not publish it immediately. See Releases for the publication workflow.

​
Submit and follow through

Write a short PR description explaining the problem and the resulting behavior, with a focused example when it helps. Include the issue link and explain any compatibility decision. Keep “Allow edits by maintainers” enabled when available so maintainers can finish small adjustments without replacing your contribution. Review the entire diff, not just your latest commit. A useful review checks the intended contract, root cause, supported behavior, tests, and documentation. Green CI is evidence that checks passed; it does not decide whether a behavior change belongs in FastMCP. Read review-bot comments and maintainer replies, evaluate concrete findings, and respond to requested changes. A new push needs checks against that revision. Stay involved until the PR is resolved; assignment is a commitment to follow through.

​
Maintenance and automation

The maintenance status page reports automation health and the contributor queue twice a day. Check its timestamp before treating a status as current. The accompanying status.json uses the fastmcp-maintenance/1 schema; idle means there was nothing to do, while degraded means a run failed. Automation labels and deduplicates issues, enforces the contribution gate, explains CI failures, and checks new dependency releases nightly. Duplicate issues and reports still missing a reproduction after seven days without an author reply close automatically. Maintainers can request work with /marvin. A separate triage agent may open draft fixes for unclaimed issues; it does not assign contributors, comment, mark drafts ready, or merge. Maintainers decide assignments, merge readiness, changes to supported behavior or APIs, releases, and security-report classification. Release publishing and docs deployment run automatically after the corresponding maintainer actions; see Releases.