docs: add dishka-fastmcp community integration

[bagowix]

Summary

Add dishka-fastmcp to the official integration index as a community-supported
FastMCP integration.

The implementation remains in its standalone repository and PyPI package, in
line with Dishka's policy for new integrations:

• https://github.com/bagowix/dishka-fastmcp
• https://pypi.org/project/dishka-fastmcp/

Scope

This PR only adds the external project link to the hidden integration toctree
and the community-support table. It does not add runtime code or dependencies to
Dishka.

This follows the existing documentation pattern used for other external
community integrations.

Package checks

• Python 3.11-3.14 CI matrix
• Minimum versions: Dishka 1.10.1 and FastMCP 3.2.4
• Ruff, mypy, and Pyright
• 100% test coverage

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[C3EQUALZz]

@bagowix uhmm... Integration with fastmcp already existed, but the author apparently forgot to add it to the documentation. Check this: https://github.com/vfaddey/fastmcp-dishka

[bagowix]

@C3EQUALZz
Thanks for pointing this out! Yes, I’m aware of fastmcp-dishka, and I explicitly credit it as prior art in the project README:

https://github.com/bagowix/dishka-fastmcp#vs-fastmcp-dishka

This project is not intended to claim that it is the first or only FastMCP integration. It is an independent implementation with different lifecycle guarantees:

• REQUEST scopes are opened and finalized inside the injected handler, which keeps sync dependency creation, usage, and cleanup in the same FastMCP worker thread;
• it uses its own ContextVars and public FastMCP middleware hooks rather than private request-state attributes;
• SESSION scope is deliberately not exposed because FastMCP currently has no deterministic session teardown hook.

[Tishka17]

@bagowix for me personally it looks like "almost the same" library as exidting one. Did you contact an author of fastmcp-dishka to collaborate?

Regarding the implementation: I insist on avoiding ContextVars as it potentially leads to leaking resources a

[bagowix]

@Tishka17 Thanks. No, I did not contact the author of fastmcp-dishka.

I looked through that project, but although both libraries solve the same problem, their lifecycle models are different. I want to keep this implementation independent and maintain it myself rather than try to rework the other project around a different approach.

I agree with your concern about ContextVars. My previous comment is outdated: I reworked the implementation before releasing v2.0.0.

The current version:

• does not use its own ContextVars or a Dishka middleware;
• resolves the container through FastMCP's public get_server() and get_context() APIs;
• opens and closes Scope.REQUEST inside the handler, so sync dependencies are created and finalized in the same worker thread.

The release is available on GitHub and PyPI.