Ability to pass system context to Apollo MCP server on boot

MCP Server
1

Hi! Looking for the proper approach for adding a bit of ‘system’ context on boot. When writing a hand-rolled tool, one suggested approach would be to use the description field on the tool to describe a given action and narrow possibilities, but here, with operations defined as queries, there’s no way to define this kind of metadata.

Example use case:

Our db uses id and _id and internalID. On boot, we would like to declare that only internalID be used. Given a query like:

”Look up so and so by id ‘foo’', the LLM would first use id (incorrect) instead of (correctly) using internalID . Front-loading critical systems knowledge like this in mcp-config.yml feels quite valuable!

Suggestions on approach? This MCP server will be deployed on our network and generally accessible internally to devs and other teammates, so we need to keep this as low-code as possible. Ideally, users only need to update their mcpServers config in order to get going, not things like .cursorrules, etc, and not encode rules in the mcpServers config other than the URL of the apollo MCP server.

Edit / Solution: Looking around WunderGraph’s implementation, it appears context is provided in the graphql operation through a simple comment in the file. I just created a new systemContext.graphql file, added it as an operation, and the system now has all of our common rules.

Would be great if we could add this to the MCP docs!

1 Like
2

@chriss This approach is really interesting and could be valuable for others facing similar challenges. To make sure I understand your solution correctly, I’m curious about a couple of details:

  1. What does your systemContext.graphql look like? I’m imagining something like this, but I’m not sure:
# System Context: Always use 'internalID' for lookups, never 'id' or '_id'
SystemContext {  
  __typename  
}
  1. How do you make your AI agent pick this tool with system context before using other tools in the MCP server? Did you do any specific prompting engineering to improve the chances?
3

Yup, that’s exactly it. The way I prompt engineered it was to name the query (operation) llmSystemContext as a hint, and I also placed it at the at the root of my operations folder; other operations are organized by folder. I treated it exactly like I would treat a CLAUDE.md file, with emphasis and pseudo-markdown.

So far this has worked perfectly, but that said we’re just getting started with our MCP server and have yet to test it extensively.

(Another approach i’ve considered is amending the root Query field (in our schema, independent of the MCP server) with a verbose description, since all queries branch from that starting point. Haven’t tested it though, since that feels like it could be buried compared to an llmSystemContext.graphql file, right where we’re building things.)