MCP server overview
Every Metatate Cloud workspace exposes a hosted MCP (Model Context Protocol) server. It gives AI agents — coding assistants, analytics copilots, review bots — governed answers about your data at the point of use: what an asset means, which rules apply, whether a proposed use is allowed, and why. Instead of pasting policy documents into prompts, an agent asks Metatate and gets a typed answer derived from what your workspace has actually published, with the evidence cited.
The server speaks MCP over HTTP (POST /mcp) and authenticates with a workspace access token. See Connect an agent for setup, or the Claude Code plugin for a packaged integration.
The seven toolsDirect link to The seven tools
| Tool | What it answers |
|---|---|
discover_context | Which assets are governed, with per-asset instruction counts and the canonical scenario keys that are valid in follow-up calls. |
get_decision_context | The full decision picture for an asset: every applicable instruction ranked, the effective decision, and published business context. |
inspect_data_meaning | What a table or column means: classification, sensitivity, PII, and masking facts. Facts only — not a decision. |
inspect_governance_rules | The active governance rules for an asset: instructions with their conditions, obligations, and policy provenance. |
authorize_use | Whether a proposed use of an asset is allowed, denied, or conditional — including optional transfer context — with a decision_id for follow-up. |
validate_query_context | A pass / warn / fail verdict for a SQL query: the query is parsed and every referenced asset is evaluated individually. |
explain_why | The evidence behind one prior decision, looked up by its decision_id. |
discover_context supports database and schema filters today. Its domain, sensitivity, pii, and compliance_tag filters are accepted by the input schema but currently answer with a not_supported error — an explicit refusal, never a silently ignored filter.
Read-only and advisoryDirect link to Read-only and advisory
Every tool is read-only and advisory, by contract:
- Outputs describe decisions; they never perform them. The server never enforces, approves, masks, blocks, or writes anything.
- Tools never mutate workspace governance state and never push to your connected data platforms.
- Answers are inputs to your agent's judgment, not enforcement actions. Enforcement stays in your own systems.
What tools readDirect link to What tools read
Decision-bearing tools read exactly one source: the deployed instruction decisions of your workspace's current deployment publication. Draft policies, unpublished edits, and superseded publications are never consulted. inspect_data_meaning reads published data-meaning facts and is not a decision-bearing path.
Because answers come only from published state, they are typed. A tool returns answered, review_required, or not_enough_published_state — missing, conflicted, or unresolved serving state is reported as a typed answer state with a stable reason code, never as a fabricated decision. Zero applicable published rows is not_enough_published_state, by design. See Typed answer states for the full model, and the quick start to get a first publication live.
The in-app preview (the Tools tab of your workspace's MCP module) and the live endpoint share the same answer model, so what you try in the app is what agents get.
Naming conventionsDirect link to Naming conventions
Every tool input and output key is snake_case (scenario_key, decision_id) — there are no camelCase aliases. Each tool also accepts a 1:1 hyphenated protocol alias (discover-context for discover_context); the underscore names are canonical.
MeteringDirect link to Metering
Every tool call consumes one metered MCP call against your workspace's plan quota. When the quota is exhausted, calls fail with a typed quota_exceeded error rather than degrading silently. See Plans for quotas.