Why keep test plans in code if Jira can slap an MCP?

Been seeing this question come up with teams that attempt to retrofit their workflows for agents. “*Why keep test plans / stories / product context in code? Just expose Jira through MCP tools.*” Something like: * list\_stories * get\_story * update\_story Voila! *Technically* the agent now has access to everything. But access ≠ understanding. The difference is similar to someone who has "**read the entire library**" vs someone "**with a library card**". A library card technically gives access to every book. But someone who has actually read the library understands relationships, patterns, structure, context, etc. Apply the same logic to your code. Imagine your codebase was stored as individual files, in a remote SaaS, and accessed purely via MCP tools: * list\_files * read\_file * upsert\_file Technically your agent has the entire codebase available. But practically, losing out a bunch of capabilities: * local indexing optimized for retrieval * folder structure as implicit context * grep/find across everything * reading nearby context naturally * faster iteration during multi-step reasoning for chain of thought The agent doesn’t just access the code - it starts understanding the shape of it. The same principle apply to product knowledge too. If stories, tests, and knowledge lived in a native/code-like form, agents can build a richer model of the business instead of pulling one record at a time through tools. Curious if others have thought about this. Do people think MCP + tools is sufficient? Or is there something fundamentally different about agents having native/local access to structured context?