Skip to content

FastMCP: Support dynamic annotation updates #1475

Open

Description

@maxisbey

Problem

FastMCP will support resource annotations (audience, priority, lastModified) via the @mcp.resource() decorator (see #1468). However, annotations are set once at decoration time and cannot be updated as the server runs.

This is problematic for lastModified especially. If you annotate a file resource, there's no easy way to keep the timestamp current as the file changes:

@mcp.resource("file://docs/readme.md", annotations=Annotations(
    audience=["user"],
    lastModified="2025-01-12T15:00:58Z"
))
def read_readme() -> str:
    return open("readme.md").read()

Once deployed, this annotation is stale. If the file updates tomorrow, clients see outdated metadata.

Solution

Allow annotations to be updated dynamically. Possible approaches:

  • Provide a method to update resource annotations at runtime
  • Allow annotation callables/lambdas that compute values on each list_resources() call
  • Return fresh annotations from resource handler functions

This would enable:

  • Accurate lastModified timestamps from file mtimes
  • Dynamic audience/priority based on server state
  • Better integration with external data sources

Issue written by Claude, reviewed by @maxisbey

Activity

  1. fennb commented on Oct 14, 2025

    @fennb
    Contributor

    Hey @maxisbey huh, I didn't really think about this when implementing #1468, good catch!

    Given that #1468 is approved, will it get merged first or does this issue become a blocking factor? (the only reason I ask is that I'm working on something that's depending on the functionality 🙂).

  2. added
    improves spec complianceWhen a change improves ability of SDK users to comply with spec definition
    enhancementRequest for a new feature that's not currently supported
    P2Moderate issues affecting some users, edge cases, potentially valuable feature
    on Oct 14, 2025
  3. maxisbey commented on Oct 15, 2025

    @maxisbey
    ContributorAuthor

    Hey @maxisbey huh, I didn't really think about this when implementing #1468, good catch!

    Given that #1468 is approved, will it get merged first or does this issue become a blocking factor? (the only reason I ask is that I'm working on something that's depending on the functionality 🙂).

    Sorry totally missed this comment!

    Yea definitely wasn't a blocker. It's kind of trickier to solve and I felt it was a bit out of scope for the PR you had which added value as-is. Not super sure on this the best way to solve yet which is why I made the issue :)

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Moderate issues affecting some users, edge cases, potentially valuable featureenhancementRequest for a new feature that's not currently supportedimproves spec complianceWhen a change improves ability of SDK users to comply with spec definition

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions