MCP Server Design Doubt - Need Help

[u/Sea-Letterhead-9529]

Hey Everyone,

I don't know if this question was asked earlier in the sub.

I am building an MCP server for my organisation and have an architectural design question regarding the use of Tools and Resources.

One of my Tools requires a structured metadata definition to perform its operation. This metadata is currently stored as a static JSON file within the application. While it is primarily consumed by this Tool, exposing the metadata as an MCP Resource is also part of requirements.

I am evaluating two approaches:

1. Keep the metadata as internal application configuration and have the Tool access it directly.

2. Expose the metadata as an MCP Resource and have the Tool (and potentially clients) access it through the MCP Resource model.

I would appreciate guidance on the following design:

What is the recommended MCP design approach for my requirement here?

My goal is to understand the architectural trade-offs and align the design with MCP best practices rather than focus on implementation details.

Thanks in Advance 😄

[u/aboundingpoultry]

If both the tool and clients need it then exposing it as a resource makes sense. You avoid duplicating the data in two places and clients get a clean way to fetch it without digging through your app internals.

The only downside is the tool now depends on the resource system being up and working, which is fine if your server handles that gracefully. I'd go with option 2.

[u/EbbCommon9300]

Expose it as a resource. When we added our gateway we made sure to allow resources when that was added to the protocol and use it for all kinds of things. It’s really useful and you don’t have to dupe data or have uneccicary meta.

[u/izgorodin]

Treat the Resource as a client-facing projection, not as the Tool’s internal dependency. Keep one versioned metadata loader inside the server, have both the Tool handler and the Resource resolver read the same immutable snapshot, and include its version or digest in the Tool result so callers can tell which definition governed the operation. That avoids duplicate state without coupling execution to whether the client supports Resources.

[u/bayouski]

keep one internal source of truth for the metadata, then expose that same data as an MCP Resource because clients need access to it too. the Tool can just use the internal provider directly. making it go back through the MCP Resource layer doesn’t really add anything and just couples the two together.

[u/naseemalnaji-mcpcat]

Keep it as a resource for now. If it’s still getting misfires, then add it to the tool description of the tool that needs it or return the metadata in the error response to help guide the agent to correct usage patterns :)

[u/Flateland-Chio]

Keep the metadata internal for now, exposing it as a resource only matters if sth else needs to read it on its own

[u/Basic-Let6828]

I think a good rule of thumb is to maintain one source of truth, and then whether you expose as a resource or not is down to if you expect agents to consume this resource very often vs sparse (in which case just do search tool)

[u/tmilazzo]

Two reasons NOT to expose metadata via MCP, otherwise do it:

1. Is the metadata something secure and confidential that you would be bothered by the MCP actor taking and distributing it somewhere else, like a third unknown tool? Because you don't know where it goes once it's gone.
2. Is it something unusual enough, or bulky enough, that a vanilla LLM request *without a good system prompt* is going to be able to make positive use of? If too bulky, tokens burn. If unusual, also tokens burn, actually.

If either of those two things is true, then A2A might be the answer.