My AI agent ignored my MCP server and grepped anyway — three things that actually fixed it

I built an MCP server that gives coding agents a compiler-accurate map of a .NET codebase. Thirteen tools at the time — find_usages, impact_analysis, the works. Then I watched Claude Code, with the server connected and healthy, answer a "who calls this?" question by running ripgrep. The tools were right there. It grepped anyway.
Someone on Reddit asked me the exact question I'd been asking myself: how do you make/force/convince the LLM to actually use the CPG MCP? That question got 10 upvotes, which tells me a lot of people are watching their agents do the same thing. Here's what actually moved the needle for me — measured by watching sessions, not vibes.
First: a concrete example invocation inside every tool description. Not prose describing the parameters — an actual call: find_usages(fqn: "MyApp.Services.VendorService"). The model's first guess at how to call your tool comes entirely from the schema plus the description, and a real invocation beats three paragraphs about parameter semantics. A good chunk of wrong-parameter calls disappeared the day I shipped this, and wrong-parameter failures are exactly what teaches an agent "this tool doesn't work, back to grep."
Second: corrective errors instead of generic ones. My server used to return "An error occurred invoking 'find_usages'" when the agent guessed a wrong parameter name — the real cause went to stderr, which no client surfaces to the model. The agent would retry the same broken call once, give up, and grep. Now a failure comes back as a normal result with a machine-checkable shape: the bad parameter name, the list of valid ones, and a message that says what to do ("this tool takes fqn (required), e.g. Namespace.Class.Method"). The agent fixes itself on the next call about as often as you'd hope. This design came out of an r/mcp thread where three engineers who run production MCP servers basically wrote the spec in the comments.
Third — and this is the unglamorous one that matters most: a standing instruction in the project's agent rules. One short paragraph in the repo's agent-facing docs: "This project has a code graph. For usages, impact, or architecture questions, query the slnmap tools first; use grep only as a fallback for things the graph doesn't model." Blunt. Works. The model reads the project context before it reads your tool descriptions, and a sentence there outweighs a paragraph in the schema.
The honest summary: you can't force it. There's no config flag for "prefer my tools." What you can do is make your tool the path of least resistance — discoverable (the standing rule), learnable (the example call), and forgiving (the corrective error). After those three, tool usage in my sessions went from occasional to default.
The meta-lesson generalizes beyond code graphs: an MCP server is an API whose only consumer has no documentation, no Stack Overflow, and no memory of ever using it before. Every session it learns your tool from scratch, from exactly two things — the description and the error messages. Spend your effort there.
The server in question is free and MIT if you want to see the patterns in place: github.com/EMahmoudNabil/slnmap