An MCP server lets a coding agent call tools that can reach repositories, databases and external services. Connecting one is not the same as deciding what it can safely change, or how you will detect a partial failure.
A published discussion of MCP operations supplied in this editorial batch distinguishes the shared tool interface from the authentication, retries, logging and recovery needed around real work. Those are useful design questions before you give an agent access to anything it can modify.
Start with the consequence of a tool call
Classify each connected tool by what it can do, rather than whether it is easy to install. Reading repository documentation is different from editing a source file, opening a pull request, changing cloud resources or writing to a database. The harder an action is to undo, the narrower the permission and the stronger the approval gate should be.
- Read: identify what private files, customer data or internal systems may be returned to the agent.
- Write: identify exactly which repository, project or records the tool may change.
- Destructive: require explicit review before deletion, deployment or changes to live systems.
- External: check which destinations receive tool arguments, results or credentials.
Do not assume an agent's own task instructions enforce these limits. Grant the minimum access needed in the underlying tool and service.
Check identity and credentials end to end
Ask whose permissions the MCP server uses when it calls its backend. If everyone shares one powerful credential, the agent may be able to act beyond the user's intended scope. Check authentication at the client-to-server boundary and authorisation at the service that actually owns the data. Store credentials outside the agent's working files and avoid returning tokens in tool output.
A local server is not automatically safe because it runs on your machine. It may have access to local files and processes. A remote server may simplify shared deployment but introduces network, availability and identity-management dependencies. Choose the arrangement according to the trust boundary, not convenience alone.
Make retries safe before relying on automation
Consider an agent that asks a tool to create a pull request. The request reaches the service, but the tool times out before reporting success. Retrying blindly might create a second pull request. A database write or cloud-resource creation can leave a more damaging duplicate or partial change.
- Determine whether repeating each write operation is safe. Where supported, use an idempotency key or check for an existing result before retrying.
- Record the request and the resulting external object identifier, not merely the agent's success message.
- Define what happens when several steps complete but a later step fails. Some work needs compensating actions or a human recovery decision.
- Test timeout and partial-failure cases with disposable resources before allowing unattended writes.
The MCP interface does not by itself promise that a business operation is atomic, recoverable or safe to repeat. Those guarantees must come from the tool implementation and the service behind it.
Keep tool discovery and context bounded
A large collection of tools can fill an agent's context with definitions irrelevant to the task. Start with a small, named set of tools and clear descriptions. If your client supports discovering tools as needed, check that discovery also respects permissions: hiding a tool's description is not a substitute for denying its execution.
Inspect tool descriptions and returned text as untrusted input. Repository files, issue comments and tool results can contain instructions written by other people. They should not override your task boundaries or authorise new actions.
What to inspect before enabling an MCP server
- Who supplies and maintains the server, and can you inspect its requested capabilities?
- Which backend identities, directories, network destinations and write operations can it access?
- Can permissions be limited to this user, task or repository?
- What is logged when a tool is called, fails, retries or changes external state?
- How will you recognise and recover from an operation that succeeds remotely but reports a timeout locally?
- Can you disable the server quickly without losing the ability to inspect what it previously changed?
Run a small read-only task first, then a reversible write in a test environment. Confirm the service-side result independently. For local command restrictions, see sandboxing coding-agent execution. For checking whether the resulting software actually behaves correctly, see testing code you did not write.
The useful question is not whether an MCP server connects successfully. It is whether its permitted actions, failure modes and recovery path are clear enough for the work you intend to delegate.