컨텍스트 객체에 접근하기

The Context object is your tool's gateway to the request: it carries shared state plus helpers for logging and progress.

Add a parameter type-hinted as Context and FastMCP injects it automatically. Clients never see this argument.

Drill into ctx.request_context.lifespan_context to get the exact object your lifespan yielded at startup.

Now your tool runs work against the shared pool instead of opening a brand new connection on every call.

Call ctx.info to send a log line to the client, which is far more useful than a hidden print on the server.

For slow work, ctx.report_progress streams percent-done updates so the host can show the user a moving bar.

The model never fills in ctx. FastMCP recognizes the type hint and supplies it, so it stays out of your tool schema.

Most context helpers are awaitable, so define context-using tools as async functions to call them cleanly.

The parameter name is up to you; the type hint is what matters. People often just call it ctx by convention.

Each tool call gets its own request context, but they all point at the same long-lived lifespan state underneath.

The context also exposes request metadata, so a tool can inspect details about the specific call it is handling.

How do you get the Context object inside a FastMCP tool?

You reach shared state via ctx.request_context.lifespan_context and use ctx for logging and progress. Next: shutting down cleanly. 🔌