LLM knowledge injection about best practice Unity plugin and tools

[IvanMurzak]

To provide well written markdown injection into LLM memory using MCP Prompt or another better way.

• To find the best way to inject information
• To create well written documentation about best Unity plugins (Feel, DOTween, R3, etc)

[KaiStarkk]

I've been thinking a lot about context lately. Do you know if MCP tools, resources and prompts consume context by default? Because if so I think good practice in MCP design might be to segment best practices information into domains.

E.g. the prompts might be called:

prompt.manifests
prompt.core.cs-api
prompt.core.editor-scripting

prompt.game.manifest
prompt.game.controllers
prompt.game.input
...

prompt.design.manifest
prompt.design.probuilder
prompt.design.audio
...

prompt.plugins.manifest
prompt.plugins.dotween
prompt.plugins.finalik
...

Then you would have only core enabled by default, along with the top-level manifest.

Top level manifest lists the domain manifests (target ~500 tokens).

Each domain manifest lists the next layer down etc.

I know you're already working on a UI for toggling features so the user could control this. A tree structure would make it easier for the agent to request features itself while managing its own context now that some of them have the ability to monitor their context consumption.

[IvanMurzak]

@KaiStarkk

Do you know if MCP tools, resources and prompts consume context by default?

• Yes, LLM consumes that into the context.

I know you're already working on a UI for toggling features so the user could control this

• It is already implemented in 3-4 last releases. For now it let to enable/disable only MCP Tools. Which is far enough at least for now.

I think good practice in MCP design might be to segment best practices information into domains.

• This is a brilliant idea! Love it.

---

There is a breakdown of the interesting implementation of "Prompts" in MCP protocol.
LLM cannot get a Prompt on it's own by AI's decision. Only MCP Client may inject a prompt into LLM by taking it from MCP Server/Prompts. For us it means we can provide list of helpful "Prompts" for a user, and user may any time type type /knowledge-inject-probuilder. The here is how it works:

• here is the call chain MCP Client -> MCP Server -> MCP Plugin
• MCP Plugin executes the method labeled as the prompt with the specific id, it may receive input arguments if needed.
• the method returns a string (prompt)
• and it sends back the response MCP Client <- MCP Server <- MCP Plugin
• in the final end MCP Client injects it into the LLM context in the same way if user just types it down and hits Enter. Here is only a single difference, Prompts API has two types of message author. It could a message from a User, or from an Assistant. Which could be handy in some scenarios.

Long story short. We can use MCP Prompts feature to let a User to inject some knowledge into the context.
Also we can build an MCP Tool for a knowledge injection. Simple tool that takes minimal or no data, and returns a string output which contains knowledge. The MCP tool may have a "path" argument for navigating in the knowledge tree. If we have a knowledge tree it probably should be a dedicated tool for only returning the entire tree to let LLM to know where it should go for taking specific knowledge.

Important to know. There is MCP Server called context7, it has knowledge base about many different things. It could be a good idea to investigate it. Also, @jstricklin may definitely tell more about all of this!

[KaiStarkk]

Thank you, that's extremely helpful.

I hope eventually the LLM clients will get smarter about enabling and disabling their own MCP tools for context management. The responsibility actually sits with the clients IMO, now that we have exposed the ability to enable and disable tools, the clients can do that as they please. The MCP designer's job is just to make the API clear about its purpose and consume minimum tokens to explain the tool/prompt/resource as is applicable.