# Ability to pass system context to Apollo MCP server on boot

**URL:** <https://community.apollographql.com/t/ability-to-pass-system-context-to-apollo-mcp-server-on-boot/9356>\
**Category:** MCP Server\
**Created:** [August 6, 2025, 4:53pm UTC](https://community.apollographql.com/t/ability-to-pass-system-context-to-apollo-mcp-server-on-boot/9356 "2025-08-06T16:53:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![chriss](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/chriss/32/6293_2.png) [@chriss](https://community.apollographql.com/u/chriss)\
**Post date:** [August 6, 2025, 4:53pm UTC](https://community.apollographql.com/t/ability-to-pass-system-context-to-apollo-mcp-server-on-boot/9356/1 "2025-08-06T16:53:48Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![DaleSeo](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/daleseo/32/5385_2.png) [@DaleSeo](https://community.apollographql.com/u/DaleSeo)\
**Post date:** [August 7, 2025, 3:13am UTC](https://community.apollographql.com/t/ability-to-pass-system-context-to-apollo-mcp-server-on-boot/9356/2 "2025-08-07T03:13:28Z")

</div>

@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:

```graphql
# 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?

---

<div class="post-metadata">

**Author:** ![chriss](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/chriss/32/6293_2.png) [@chriss](https://community.apollographql.com/u/chriss)\
**Post date:** [August 7, 2025, 4:18am UTC](https://community.apollographql.com/t/ability-to-pass-system-context-to-apollo-mcp-server-on-boot/9356/3 "2025-08-07T04:18:34Z")

</div>

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.)