MCP ecosystem compatibility
What you'll find here
The boundary for treating MCP servers, clients, tools, and resources as policy-bound integration surfaces. MCP metadata can describe where a service lives and what capability it offers, but it never bypasses Craik capability grants, receipts, redaction, or operator approval.
Compatibility ≠ trust.
Compatibility means Craik can represent the integration, route calls through policy, and produce evidence and receipts. It does not mean every external MCP server is trusted or enabled by default.
Supported surfaces
MCP client metadata
Exported memory & context boundaries
Runner & tool routing
Plugin & adapter examples
Secret-safe configuration
Clients and servers
MCP clients store
- Stable ids
- Transport metadata
- Command / endpoint references
- Secret reference names
- Policy envelope ids
MCP clients NEVER store
- Raw bearer tokens
- Passwords or private keys
- Secret query strings
MCP servers are compatible when their advertised tools or resources can be mapped to explicit Craik capabilities. A compatible server still needs a capability grant before execution, and calls that affect external systems produce receipts.
Craik server mode
v0.12.0 adds a compatibility server surface for MCP smoke tests and client integration. It exposes safe read surfaces first:
craik mcp server manifest
The manifest advertises read-only tools for case summaries, approved memory search, and receipt metadata. Gated write tools are hidden by default and only appear when explicitly requested:
craik mcp server manifest --include-write-tools
JSON-RPC compatibility handling is available for local integration tests:
craik mcp server handle --request-json '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Tool calls map to Craik controls before execution. Read calls require
operator authentication. Write calls also require an approved policy
gate and receipt id. Denials are structured JSON-RPC errors with the
missing control listed in error.data.required_controls.
Client config import/export
Import external MCP client config as redacted Craik metadata:
craik mcp client import --path ./mcp.json
The importer accepts both Craik-shaped MCPClientConfig JSON and
common mcpServers config objects. Environment variable names such as
MCP_TOKEN become secret_ref_names; raw values are not copied into
Craik config. Export prints the same clients in redacted form:
craik mcp client export --path ./mcp.json
Inside the terminal UI, /mcp reads configured MCP client metadata from
Craik local state and summarizes client ids, transports, advertised tool
counts, and stale config references. /mcp verbose expands each client with
grant, receipt, redaction, and tool-policy attributes. Add --json to either
form for structured output.
Tools
A tool route is compatible when every condition holds:
- The requested capability is represented in policy.
- The route requires a grant where policy requires one.
- Input and output can be redacted before public reporting.
- Execution receipts can name the tool, route, policy envelope, and result.
- Failures can be reported without exposing credentials or private local paths.
Tools that cannot be represented with these controls remain unsupported until an adapter adds the missing policy, receipt, or redaction behavior.
Resources
MCP resources are compatible as read surfaces when Craik can attach provenance, scope, and redaction behavior. Resource reads become evidence references or bounded context inputs — never unreviewed durable memory writes.
Resource content containing secrets, private task names, local paths, or operator-only data must be redacted before appearing in public docs, receipts, or export artifacts.
Exports and adapters
Exports preserve the same boundaries used at runtime.
Policy envelopes
Identify the rules that governed an export.
Capability grants
Identify the authority used by an adapter.
Receipts
Identify actions taken and checks performed.
Redaction markers
Replace sensitive values.
Secret references
Remain references, not copied values.
Adapters may translate between MCP schemas and Craik contracts, but they must not collapse policy decisions into plain-text notes. If a source integration cannot preserve capability grants, receipts, or redaction outcomes, the adapter marks that surface as unsupported or requires operator review.
Unsupported surfaces
Boundaries Craik does not treat as compatible.
Importing raw server secrets
Into Craik config.
Executing tools without grants
When policy requires one.
Exporting unredacted I/O
Or resource bodies.
Resource reads as memory writes
Automatic durable writes are unsupported.
Server-provided instructions
Higher priority than project, operator, or policy instructions.
Tool success without receipts
When policy requires receipts.
Compatibility checklist
- The client or adapter is represented by a stable id.
- Command, endpoint, and secret values are references — not raw secrets.
- Every tool route maps to an explicit capability.
- Required grants and receipts are configured.
- Public reporting paths apply redaction.
- Unsupported fields are documented with migration or adapter notes.
- Dry runs and compatibility reports avoid private paths, credentials, and private task names.