MCP server examples with security policy

The control gap

Examples teach architecture only when they show different authority levels instead of placing every tool behind one permissive development credential.

DataForSEO reports 720 monthly US searches for `mcp server examples`, $8.62 CPC, and keyword difficulty 18. Use examples to expose security structure: a documentation search reads bounded content; issue creation writes one repository; a database update changes rows; a refund moves value. Giving all four the same rule teaches an unsafe abstraction.

For each example define canonical tool, resource selector, identity requirement, allowed environment, decision, approval owner, expiry, downstream credential boundary, and evidence. Start with asserted identity in shadow mode only, then require verified principal and delegation for production. Where no server-side adapter exists, wrap execution with the SDK and record whether the outcome is caller-observed.

A safe read-only example still needs boundaries. Documentation search may reveal internal material, database lookup may cross tenants, and file retrieval may follow attacker-controlled paths. Specify collection, tenant, classification, result limits, and logging minimization rather than assuming the absence of a write makes authorization unnecessary.

For a write example, show the pause explicitly. The client sends a structured tool call, Endram returns `require_approval`, the owner reviews the exact resource and arguments, and execution resumes only with bound authority. Alter one protected field after approval and demonstrate that the invocation is rejected.

Publish failure behavior alongside the happy path. Include invalid identity, unknown tool, missing resource, expired approval, duplicate grant, provider timeout, and partial result. Examples that omit these states encourage integrations that treat every non-success as retryable and accidentally repeat external side effects.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "invoke_tool" rather than every operation exposed by the tool.
• Scope the target to example read, write, financial, and administrative MCP tools and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

MCP server examples with security policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: mcp-example-write-boundary
match:
  identity_verified: true
  tool: ["github.create_issue", "database.update", "payments.refund"]
  environment: production
decision: require_approval

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted invoke_tool, including denied requests.
• The exact example read, write, financial, and administrative MCP tools selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?