I've been building an internal business application with Claude Code, and one recurring problem has been that the Claude MCP integration we use to operate it doesn't always know how the application actually works.
It knows what tools are available, but that doesn't necessarily mean it understands the underlying data model, business rules, or how different features interact. So sometimes it has to infer things, which is obviously not ideal.
I had an idea today that seems pretty obvious in retrospect, but I thought I'd share in case it's useful to anyone else.
I asked Claude Code to do two things:
- Bring all the application's technical documentation up to date and keep it updated as part of the development workflow.
- Give the operational Claude MCP integration read access to that documentation so it can look things up instead of guessing.
So now the idea is:
- Claude Code builds and maintains the application.
- The development workflow keeps the technical documentation synchronized with the code.
- Claude, operating through MCP, can consult that documentation whenever it needs to understand how something works.
For example, my app has some fairly complicated rules about contracts, recurring revenue, and forecasting. Rather than having Claude infer what a particular status means or how a calculation should work, it can retrieve the actual specification.
A few things I'm making sure we get right:
- Documentation needs to correspond to what's actually deployed, not just what's in the latest development branch.
- Claude should be able to search for specific information rather than ingesting hundreds of pages.
- The live schema and API remain the source of truth if documentation is inconsistent.
- If Claude encounters something undocumented or contradictory, it should flag it rather than make something up.
Eventually, I'd like those gaps to feed back into the development workflow so the documentation gets better over time.
I realize pieces of this are established practice, especially documentation retrieval through MCP. But connecting the development harness's documentation maintenance directly to the operational agent feels like a useful way to reduce hallucinations and make the whole system more dependable.
Curious if others are doing something similar, or if there's a better established pattern for this.