MCP connects an agent to tools and data. Review each callable operation and the credential behind it. A read-only docs tool and a tool that writes to GitHub, changes a ticket, queries customer data, or calls a cloud API need different controls. Configuration shows declared reach; tool and target logs prove actual use.
What to map for each MCP tool
Tool and operation
List the declared tool, callable operations, read/write behavior, and whether the call can mutate external or internal state.
Credential
Identify OAuth grant, service token, PAT, app credential, local token, or delegated user identity.
Target system
Connect the tool call to GitHub, Slack, Jira, cloud APIs, incident tools, data stores, package systems, or internal APIs.
Approval and evidence
Record who approved the tool call, why it was allowed, which policy applied, and where the outcome is logged.
MCP tool risk tiers
| Tier | Examples | Default review |
|---|---|---|
| Read-only | Docs search, repo lookup, ticket search, read-only logs. | Allow with owner and logging. |
| Write-capable | GitHub issue writer, Jira transition, Slack sender, PR commenter. | Approve based on target, audience, and reversibility. |
| Privileged | AWS deploy helper, database query tool, customer lookup, incident system action. | Require explicit approval, scoped credential, and outcome evidence. |
Risks worth reviewing first
- Tools that can write, delete, deploy, publish, change tickets, notify customers, or call APIs that affect production.
- Token passthrough or broad standing tokens where the tool carries more authority than the task needs.
- Tools reachable from repo instructions, agent settings, local config, or shared developer environments without clear owner.
- Missing evidence tying human request, agent session, tool call, credential, target, approval, and outcome together.
Starter boundary
Allow read-only and low-impact tools by default. Require approval for write, deploy, publish, destructive, customer-facing, data-access, cloud, or privileged internal-system calls. Block unmanaged token passthrough, ownerless tools, and tools that bypass existing approval paths.
Source notes
- MCP security best practices discuss confused deputy risk, token passthrough, session hijacking, and least-privilege authorization.
- Claude Code permissions docs describe tool permission decisions that are relevant when MCP tools become part of coding workflows.
- Clyra's identity guide connects each credential to the workflow and systems that can use it.
Map one MCP tool path.
Clyra maps tool reachability, credential scope, owner, approval point, and evidence gaps for selected workflows.
Map one workflow