Connecting Claude to internal systems: scope a read-only MCP release

I would start with a bounded task such as finding a project's recorded owner, retrieving its approved milestone status, or locating the latest issued document. Avoid a first scope that asks the model to decide whether the entire business is healthy.

For each question, identify the source record and the fields needed. If project status is maintained in two systems with conflicting meanings, resolve that mapping before exposing a search tool. Otherwise, the integration will make inconsistent data easier to retrieve without making it more trustworthy.

The tool contract should return source identifiers, timestamps, and relevant limitations alongside the data. A missing record, denied record, stale source, and unavailable connector should have distinct outcomes. They should not all become an empty result that the model interprets as “nothing exists.”

A tool called search_everything can be difficult to reason about. I would prefer a small number of operations with clear inputs, bounded results, and documented access checks. The names should describe what the caller can actually do.

For an illustrative project lookup, the input might be a project identifier or a constrained search phrase. The output should include only fields needed for the approved task. Avoid returning entire API objects merely because the upstream endpoint supplies them.

The server should validate inputs before calling the source system and validate or normalize outputs before returning them. A language model choosing a tool does not make its arguments safe or meaningful. Limits on result counts and response size also keep accidental broad queries from overwhelming the user or exposing unnecessary data.

Read-only access can still disclose sensitive information. I would test the integration with ordinary users who have different access rights, not only with an administrator account.

The MCP authorization specification describes authorization for HTTP-based transports and token handling requirements. The implementation must also enforce the source system's resource-level permissions. A valid token is not permission to return every project in the organization.

If the design uses a service account, document how it limits results to the requesting user's allowed scope. Do not assume that filtering in the chat interface is sufficient. The server must reject or exclude unauthorized resources before their contents reach the model.

An internal document can contain instructions intended for a person, outdated operational notes, or malicious text copied from an external source. The integration should not let that content change tool permissions or the system's operating rules.

I would keep the first release incapable of writing to the source system. That reduces the actions available if retrieved content influences the model, though it does not eliminate disclosure risk. Results still need access controls and careful field selection.

OWASP's prompt injection guidance describes risks from indirect instructions in retrieved content. In the acceptance tests, I would include a synthetic document that tells the assistant to reveal another project's data and verify that the server's permissions prevent that retrieval.

A useful answer should identify the record it used and the last-known update time when available. If the connector serves a cached copy, the result should state the cache's freshness boundary rather than implying a live read.

The interface should make it easy to open the authoritative record, subject to the same access rules. A source link that works only for the administrator is not a complete user experience. Test it with the actual user roles included in the release.

When the source is unavailable, the tool should return an explicit failure or clearly labeled stale result under the approved policy. I would not allow a model to fill the gap from remembered conversation context and present that as a current system answer.

Create representative questions with expected source records and permitted results. Include exact identifiers, ambiguous names, missing records, stale records, and users who should be denied access. Define what a correct refusal or clarification looks like.

The evaluation should observe both the tool response and the final answer. A correctly restricted tool can still be described misleadingly by the assistant. Conversely, a cautious answer does not prove that the server avoided retrieving unauthorized data.

I would record the client version, server revision, source environment, and test identities. Keep synthetic data separate from production material so the tests can be repeated without exposing client information or creating misleading operational records.

The owner needs to know how to rotate credentials, revoke access, inspect failures, and disable the integration. A read-only release still needs monitoring because stale or missing data can affect decisions.

Keep logs focused on operation identifiers, outcomes, timing, and access decisions. Store sensitive query or result content only where there is a defined need and approved retention. The runbook should explain what evidence is available when a user reports an incorrect answer.

I would also document source API limits and the behavior when those limits are reached. The system should fail clearly or queue work according to its contract, not silently return a partial result as complete.

Once the read-only scope is accepted, the team can evaluate a specific write action with its own approval, replay, and recovery rules. Updating one project field is a different release from sending client communications or deleting records.

The first implementation succeeds when authorized users can retrieve accurate, attributable information and the team can explain its limitations. That is a concrete deliverable to demonstrate before expanding the integration's authority.

I would include a test in which an ordinary user can initially read a synthetic project and then loses access in the source system. The next authorized lookup should respect the changed permission according to the documented freshness and caching rules. A previous successful answer should not become permanent access.

The test should inspect the server response as well as the assistant's answer. If the server returns the full record and the assistant merely declines to display it, the access boundary has already failed. Unauthorized content should be excluded before it reaches the model.

I would also ask an ambiguous question that could refer to two projects with similar names. The integration should request clarification or return only permitted candidates. It should not search more broadly under an administrator credential to make the demonstration smoother. These examples expose the difference between a convenient demo and a release that behaves correctly for real user roles.