Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@vorionsys/mcp-server Check trust for agent 'my-agent'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server exposing Vorion audit and trust primitives — local trust scoring, proof logging, and remote Cognigate Runtime tools.
This server lets MCP clients (Claude Desktop, Cursor, IDEs, agent frameworks) call Vorion audit and trust primitives directly: check an agent's trust tier, record behavioral signals, run pre-flight tier checks for actions, log proof-chained decisions, and — when configured with a deployed Cognigate Runtime endpoint — submit canary probes, tail tenant audit streams, and perform health checks against a live runtime. Pre-flight checks return a decision; honoring that decision is up to the calling client.
BASIS is to AI-agent governance what OAuth is to delegated authorization — an open standard so an agent trusted by one system can be evaluated by another.
Status: source-available / reference use. This repository is the canonical home for the Vorion MCP server. The npm package
@vorionsys/mcp-serverand its runtime dependencies are currently withdrawn pending IP review (see Install / current status). Use it as a reference for how a governance layer is exposed over MCP, and as the source you build from once the dependency chain is published.
The published npm package is withdrawn (see below), so install from this repo:
# Clone, install, build — then the stdio entrypoint is dist/index.js
git clone https://github.com/vorionsys/mcp-server.git && cd mcp-server && npm install && npm run buildThe build produces an executable stdio server at dist/index.js (the package also exposes it as a vorion-mcp bin). To run it directly once built:
node dist/index.jsOr run from source without building (uses tsx):
npm run devThe server speaks the Model Context Protocol over stdio — it does not print to stdout except MCP frames, and it does not open a port. It is meant to be launched by an MCP client (see Use with Claude Desktop), not run interactively.
Heads-up before you run it: a clean public install does not boot yet. The runtime depends on
@vorionsys/sdk, which pulls a chain of@vorionsys/*packages that are withdrawn pending IP review — so the server currently exits at startup withERR_MODULE_NOT_FOUND. See Troubleshooting for exactly what you'll see and why.
Related MCP server: Agent Identity MCP Server
When an MCP client wires this server in, your agent's tool calls can be governed instead of blindly executed. In practice you get:
A trust score and tier per agent (0–1000, mapped to tiers T0–T7) so a client can decide how much autonomy an agent has earned — not just whether a single call looks safe.
A pre-flight allow/deny (vorion_gate_action / vorion_execute_governed) that checks an agent's tier against the risk of an action before it runs.
Behavioral feedback that moves the score — successes raise trust, failures lower it, and higher-tier agents are penalized more for failures (penalty formula P(T) = 3 + T).
A hash-chained proof log of every ALLOW/DENY decision, so the reasoning behind a governed action is auditable after the fact.
(Optional, remote) tenant + canary visibility against a deployed Cognigate Runtime: who an API key resolves to, a tail of the hash-chained audit stream, and a place to submit canary-probe outcomes.
These are governance signals for a client to act on — they don't themselves block your OS or network; enforcement is up to the client that consumes them.
Tool | Purpose |
| Look up an agent's score (0–1000), tier (T0–T7), and observation tier. |
| Record a behavioral signal ( |
| Pre-flight check: does the agent meet the required tier for an action? |
| Log an ALLOW/DENY decision to the hash-chained proof log. |
| Gate + record signal + log proof in one call (recommended). |
VORION_API_URL + VORION_API_KEY)Tool | Purpose |
| Resolve the calling API key to its tenant id, role, and capabilities. |
| List all tenants on the runtime (admin-only). |
| Tail recent hash-chained audit events for a tenant. |
| Submit a canary probe result (pass / fail / ambiguous) to the runtime. |
| Hit the configured Cognigate Runtime |
Without VORION_API_URL + VORION_API_KEY, the remote tools still appear in the surface but return a structured not configured error — the local trust-engine tools are unaffected.
vorion://tiers — the BASIS 8-tier trust model (score ranges, capabilities, penalty multipliers, penalty formula).
vorion://agents/{agentId}/trust — current trust profile for a specific agent.
Read the source if you want to confirm any of this — it is all in src/index.ts.
The five local trust-engine tools make no network calls. They run entirely in-process against the local trust engine and an in-memory proof log. Nothing is sent anywhere.
No analytics, no usage telemetry, no crash reporting. There is no Sentry/PostHog/"phone-home" code path. The only thing written to a remote service is the explicit remote-tool calls you make.
The only outbound network calls come from the five remote tools, and only when both VORION_API_URL and VORION_API_KEY are set. In that case the server makes HTTPS requests to the Cognigate Runtime URL you configure (e.g. your own deployment), sending your VORION_API_KEY as a Bearer token and the arguments you passed to the tool. If those env vars are unset, no outbound request is ever attempted.
The server logs only to stderr, and only on a fatal startup error. It does not log tool inputs/outputs.
In short: with no env vars configured, this is a fully local server with no telemetry. Any network traffic is an explicit remote tool call to an endpoint you chose.
Do not npm install @vorionsys/mcp-server. That package — along with its runtime dependencies @vorionsys/sdk and @vorionsys/proof-plane — is currently deprecated on npm with the message "withdrawn pending IP review." Install from this repository instead (see Quick start).
Because the dependency chain is mid-review, a clean public clone will install and build but will not yet boot at runtime (the SDK imports withdrawn private @vorionsys/* peers that npm cannot resolve). Treat this repo as reference / source-available until those packages are published. See Troubleshooting.
Because the npm package is withdrawn, point Claude Desktop at your locally built copy rather than npx-ing the published package. After running the Quick start, add the following to claude_desktop_config.json (use the absolute path to your clone's dist/index.js):
{
"mcpServers": {
"vorion": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/dist/index.js"]
}
}
}To enable the remote Cognigate Runtime tools (vorion_tenant_whoami, vorion_tenant_list, vorion_tenant_audit_tail, vorion_canary_submit, vorion_health_check), add the two environment variables, pointing VORION_API_URL at your runtime deployment:
{
"mcpServers": {
"vorion": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/dist/index.js"],
"env": {
"VORION_API_URL": "https://your-cognigate-runtime.example.com",
"VORION_API_KEY": "vrn_live_..."
}
}
}
}The server is registered under the name vorion, so its tools appear as vorion_* in the client. VORION_API_URL and VORION_API_KEY are the only two environment variables the server reads.
The three most common setup failures, in order of likelihood:
1. Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@vorionsys/...' at startup.
This is expected today on a clean public install. @vorionsys/sdk pulls a chain of @vorionsys/* packages (e.g. atsf-core, security, a3i, runtime) that are withdrawn pending IP review and therefore cannot be resolved from the public npm registry. The build (npm run build) succeeds, but node dist/index.js exits immediately. There is no public workaround until those packages are published — this is why the repo is currently labeled reference / source-available. If you have access to the Vorion monorepo, install/link those peers there and run from that workspace.
2. The server starts but immediately exits, or your client says "node: command not found" / a syntax error.
Check your Node version: node --version. This server requires Node.js >= 20 (it uses native ESM and the global fetch). On older Node you'll see module-resolution or fetch is not defined errors. Also make sure you ran npm run build first — args in the Claude Desktop config must point to the compiled dist/index.js (or use npm run dev for the tsx source path), not src/index.ts directly.
3. The remote tools return Remote Cognigate API is not configured (or a network error).
The five remote tools require both VORION_API_URL and VORION_API_KEY to be set in the server's env. If either is missing you'll get a structured not configured error — that's by design, and the local tools keep working. If both are set but you get a network error, the URL is unreachable from where the server runs; if you get 403 on vorion_tenant_list, your key lacks the admin role. Note this is a stdio server: it must be launched by an MCP client (or piped JSON-RPC), not run as an interactive command — a bare node dist/index.js in a terminal will just wait silently for stdin.
# Install dependencies
npm install
# Build (tsc -> dist/)
npm run build
# Run tests (vitest)
npm test
# Typecheck only
npm run typecheck
# Run from source over stdio (tsx)
npm run devRuntime: Node.js >= 20, ES modules (type: module).
Language: TypeScript 5.x, strict mode, NodeNext resolution.
MCP SDK: @modelcontextprotocol/sdk ^1.28.
Vorion deps: @vorionsys/sdk ^0.3.1 (local trust engine) and @vorionsys/proof-plane ^0.1.4 (hash-chained event log) — both withdrawn pending IP review on npm; see Install / current status.
Schema validation: zod.
Test runner: vitest.
Transport: stdio (Claude Desktop, Cursor, etc.). HTTP transport is not implemented.
This package was extracted from the Vorion monorepo at commit 3d7ed92d (April 20 2026 — feat(mcp-server): add remote Cognigate Runtime tools (v0.3.0)).
The remote-runtime work was originally captured in a now-superseded PR in the private monorepo (voriongit/vorion#137). That PR is closed in favor of this standalone repo per founder direction (Apr 24 2026).
License normalized from UNLICENSED to Apache-2.0 at extraction time.
Apache-2.0 — see LICENSE.
Copyright 2026 Vorion LLC. See NOTICE for attribution.
Vorion: https://vorion.org
BASIS specification: https://github.com/voriongit/basis-spec-docs
Submit a canary probe result to the Cognigate Runtime. Canary probes are adversarial or behavioral test cases that measure whether an agent responded correctly. Results classified as pass / fail / ambiguous feed the tenant's behavioral baseline and can trigger AUDITED state on repeated ambiguous outcomes. Returns the stored proofHash for chain verification.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | Agent the probe was run against | |
| outcome | Yes | Classification of the probe result | |
| probeId | Yes | Stable probe identifier | |
| evidence | No | Optional evidence payload | |
| riskLevel | Yes | Risk level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral consequences: results feed the tenant's behavioral baseline, repeated ambiguous outcomes can trigger AUDITED state, and it returns a proofHash for chain verification. This goes beyond basic write semantics, though it omits permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, and each sentence adds value: definition, consequences, and return value. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (including a nested evidence object) and no output schema, but the description covers the core purpose, outcome semantics, side effects, and return value. It could mention error conditions or the evidence parameter, but the schema already describes fields. Overall, sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that pass/fail/ambiguous outcomes feed the baseline and can trigger AUDITED state, giving semantic weight to the outcome enum. It also ties probeId to the canary probe concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Submit a canary probe result') and the specific resource ('Cognigate Runtime'). It explains what canary probes are and how results are classified, distinguishing this from sibling tools like vorion_record_signal or vorion_log_proof. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: when submitting canary probe results after running adversarial/behavioral tests. It explains the outcome classifications and their consequences. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an AI agent's current trust score and tier in the Vorion governance system. Returns the numeric score (0-1000), tier number (T0-T7), tier name, and observation tier. Use this to check how trusted an agent is before allowing it to perform sensitive actions.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | Unique identifier of the agent to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates this is a lookup operation ('Look up', 'Returns') and discloses the exact output fields: numeric score, tier number, tier name, and observation tier. This is transparent for a read-only tool, though it does not discuss authentication, staleness, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and every sentence adds value. The return fields and use case are included without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully enumerates the return values (score, tier number, tier name, observation tier) and explains the operational context. Given the simple single-parameter schema and clear sibling context, the description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, agentId, is described as 'Unique identifier of the agent to look up.' The description adds no additional semantic information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Look up an AI agent's current trust score and tier in the Vorion governance system.' It clearly distinguishes this from sibling tools by focusing on a read-only trust lookup, whereas siblings like record_signal or gate_action imply writing or enforcement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use this to check how trusted an agent is before allowing it to perform sensitive actions.' This provides clear context for when to invoke the tool, though it does not mention alternatives or explicit when-not-to-use conditions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate + execute + log in one atomic call. Checks if the agent has sufficient trust tier, executes the action if allowed, records the outcome as a behavioral signal, and logs a proof. Returns the full governance trail: gate decision, execution result, trust delta, and proof hash. This is the recommended way to run governed tool calls — replaces manual check-then-execute patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| risk | Yes | Risk level | |
| action | Yes | Action to perform | |
| agentId | Yes | Agent performing the action | |
| description | Yes | What the action does |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the atomic operation, the conditional execution, the recording of behavioral signals, and the logging of proof. It also describes the return value (governance trail) including gate decision, execution result, trust delta, and proof hash.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the core function ('Gate + execute + log in one atomic call'), and every sentence adds value: the flow, the return, and the usage recommendation. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the return value comprehensively. It covers the full operation flow, atomicity, and the recommended usage. The parameter details are already in the schema, and the description provides sufficient context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with each parameter having a clear description (e.g., 'Risk level', 'Action to perform'). The description does not add additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Gate + execute + log in one atomic call.' It specifies the exact steps (check trust, execute if allowed, record signal, log proof) and distinguishes itself from sibling tools by combining their functions. This is a specific, well-defined purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the recommended way to run governed tool calls' and states it 'replaces manual check-then-execute patterns,' giving clear guidance on when to use it and positioning it against manual alternatives. This provides strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an AI agent is allowed to perform a specific action based on its current trust tier. Returns whether the action is allowed, the agent's current tier, the required tier, and a reason. Use this as a pre-flight check before executing sensitive operations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action the agent wants to perform | |
| agentId | Yes | Unique identifier of the agent requesting the action | |
| requiredTier | Yes | Minimum trust tier (0-7) required for this action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses return fields (allowed, current tier, required tier, reason) and frames the tool as a pre-flight check, implying no side effects. But it does not discuss error conditions, permissions, or whether any state is modified, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second covers return values and usage. No wasted words, front-loaded with the core question.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple authorization check with fully documented schemas, the description provides essential context: purpose, return values, and usage scenario. It lacks error handling details but is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions (100% coverage), so baseline is 3. The description reinforces the meaning of requiredTier by mentioning 'required tier' but adds no additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an AI agent is allowed to perform a specific action based on trust tier. It uses a specific verb ('Check'), names the resource ('specific action'), and differentiates from sibling vorion_check_trust by focusing on action-level authorization with required tier comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this as a pre-flight check before executing sensitive operations', providing clear when-to-use guidance. However, it does not mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hit the Cognigate Runtime health endpoint. Returns status, uptime, and dependency state (proof store, audit log, metrics). Use this as a pre-flight check before relying on remote governance operations, or to confirm the deployed API is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the response contents (status, uptime, dependency state) and the tool's non-destructive, informational nature. It lacks details on error handling or auth, but for a simple health check this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and purpose. Every phrase adds value: 'pre-flight check,' 'returns status,' and 'confirm reachable' are all useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description covers everything essential: what the tool does, when to use it, and what it returns. It is complete for a simple health check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description needs no parameter details. Baseline 4 applies, and the description correctly omits irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Hit the health endpoint'), the resource ('Cognigate Runtime'), and the return value ('status, uptime, dependency state'). It is distinct from sibling governance tools, which involve trust checks, signals, and actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'pre-flight check before relying on remote governance operations' and 'confirm the deployed API is reachable.' Does not explicitly state when-not-to-use or name alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a governance decision to the Vorion proof chain — an immutable, hash-linked audit trail. Every ALLOW or DENY decision is recorded with the agent ID, action, and reasoning. Returns a proof hash and the current chain length for verification.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action that was evaluated | |
| reason | Yes | Human-readable explanation for the decision | |
| agentId | Yes | Unique identifier of the agent involved in the decision | |
| decision | Yes | Whether the action was allowed or denied |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the audit trail is immutable and hash-linked, and reveals that it returns a proof hash and chain length for verification. This goes beyond basic operation description, though it doesn't cover error cases or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loading the primary purpose, then detailing the content and return value. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logging tool with fully described parameters and a clear return value, the description covers all necessary aspects. It explains both the operation and its output, and the absence of an output schema is mitigated by the explicit mention of the proof hash and chain length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already explains all four parameters. The description adds minimal extra semantic value by naming 'agent ID, action, and reasoning,' but does not deepen understanding beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool logs governance decisions to an immutable proof chain, specifies the decision types (ALLOW/DENY), and lists the recorded data. This distinguishes it from sibling tools like vorion_tenant_audit_tail or vorion_record_signal, though it could be more explicit about those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it (whenever a governance decision is made) but does not explicitly mention when not to use it or name alternative tools. This is a clear context without exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a behavioral signal (positive or negative) for an AI agent. Positive signals (success, compliance pass) increase trust over time. Negative signals (failure, compliance fail) decrease trust — and higher-tier agents are penalized MORE severely per the BASIS penalty ratio P(T) = 3 + T.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of behavioral signal to record | |
| value | Yes | Signal strength from 0.0 to 1.0 | |
| agentId | Yes | Unique identifier of the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond a simple 'record' by explaining the consequence: positive signals increase trust over time, while negative signals decrease trust, with higher-tier agents penalized more severely per the formula P(T) = 3 + T. This is useful behavioral context, though it omits details like authentication, rate limits, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the core action front-loaded in the first sentence. Each subsequent sentence adds meaningful context (positive/negative impact, penalty formula) without any fluff or repetition. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and behavioral consequences, but it is incomplete in operational details. Since there is no output schema, the description should have specified what the caller receives (e.g., confirmation, updated trust score, or error behavior). It also omits prerequisites (e.g., whether the agent must exist) and idempotency characteristics. This is a moderate gap for a recording tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds extra semantic value by mapping the type enum values (behavioral.success, compliance.pass) to positive signals and (behavioral.failure, compliance.fail) to negative signals, and by explaining the penalty formula that relates to the type/value choice. This enriches the schema's bare descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Record a behavioral signal (positive or negative) for an AI agent.' It immediately distinguishes itself from sibling tools like vorion_check_trust (which presumably reads trust) and vorion_log_proof (which logs proofs) by focusing on recording behavioral signals and their trust impact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool by explaining that positive signals (success, compliance pass) increase trust and negative signals (failure, compliance fail) decrease trust. However, it does not explicitly mention alternatives or exclusions, so it stops short of the full 'when-to-use vs when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail the most recent audit events for a tenant (default: caller's own tenant). Each event carries hash-chained provenance: eventId, priorProofHash, proofHash. Use this to verify governance activity is being recorded correctly or to surface the live audit stream in a dashboard / glass window.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Events to return (default 20). | |
| tenantId | No | Tenant to tail. Defaults to caller's tenant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable behavioral context: events carry hash-chained provenance (eventId, priorProofHash, proofHash) and default to the caller's tenant. It implies a non-mutating read via 'tail,' but does not explicitly state its read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, a key output characteristic, and usage scenarios. It is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description provides enough context for an agent to understand what the tool does, when to use it, and a key detail of the returned events. It could explicitly confirm the response shape, but the mentioned fields (eventId, priorProofHash, proofHash) suffice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both 'limit' (with min/max/default) and 'tenantId' (defaults to caller's tenant). The description adds no new parameter-specific info beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Tail the most recent audit events for a tenant' with a specific verb and resource, and notes the default caller's tenant. This distinguishes it from sibling tools like vorion_record_signal or vorion_gate_action, which are mutation-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are given: 'verify governance activity is being recorded correctly' or 'surface the live audit stream in a dashboard / glass window.' This provides clear context, though it does not explicitly name alternative tools or state when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tenants registered on the Cognigate Runtime. Admin-only. Returns id, name, tier, createdAt, and agent counts. Requires an admin-role API key in VORION_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses admin-only access, the API key requirement via VORION_API_KEY, and the exact return fields. It does not mention rate limits, pagination, or error behavior, but covers the most relevant behavioral traits for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each adding value: purpose, access restriction, return contents, and authentication method. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description is complete: it explains what it does, who can use it, what it returns, and how to authenticate. Lacking pagination details is not critical for a tenant list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly avoids parameter detail. With 100% schema coverage trivially satisfied, the baseline 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'all tenants' on the 'Cognigate Runtime', clearly distinguishing it from sibling tools like vorion_tenant_whoami (single tenant) and vorion_tenant_audit_tail (audit logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states 'Admin-only' and 'Requires an admin-role API key', giving explicit access context. It does not name alternatives or exclusions, but the scope 'all tenants' implies enumeration, differentiating it from other tenant-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the calling API key against the deployed Cognigate Runtime. Returns the tenant id, role, and capabilities the key is scoped to. Use this first if you need to confirm which tenant context the MCP session is running in. Requires VORION_API_URL + VORION_API_KEY env vars.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool resolves the API key, returns specific fields (tenant id, role, capabilities), and requires the VORION_API_URL and VORION_API_KEY env vars. This adds meaningful context. It does not explicitly state whether it is read-only or describe error handling, but for a simple lookup tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and return values, followed by usage guidance and requirements. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, when to use it, required environment variables, and return values (tenant id, role, capabilities). With no output schema, this is sufficient. It could add error scenarios or explicit read-only confirmation, but overall it is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description goes further by explaining that the tool uses the calling API key and requires specific environment variables, adding meaningful operational context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves the calling API key against the Cognigate Runtime and returns the tenant id, role, and capabilities. It is specific and distinct from sibling tools like vorion_tenant_list, which lists tenants, whereas this tool identifies the current session's tenant context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this first if you need to confirm which tenant context the MCP session is running in', giving a clear when-to-use scenario. However, it does not mention when not to use it or alternative tools, so it stops short of full alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.2vorion_canary_submitvorion_check_trustvorion_execute_governedvorion_gate_actionvorion_health_checkvorion_log_proofvorion_record_signalvorion_tenant_audit_tailvorion_tenant_listvorion_tenant_whoamiEach tool targets a distinct action within the governance domain, but vorion_execute_governed composites several other tools (gate, signal, log), which could create slight overlap. Descriptions are clear enough to disambiguate intended usage.
All tools share the vorion_ prefix and snake_case, but ordering mixes verb-first (check_trust, record_signal) with noun-first (tenant_list, canary_submit). This is a moderate inconsistency that remains readable.
10 tools is well within the ideal 3-15 range, and each tool covers a necessary aspect of the governance system without unnecessary bloat.
The set covers core governance workflows: trust checks, signal recording, gating, logging, execution, tenant context, audit, canary, and health. Minor gaps like direct agent CRUD exist but are not essential to the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vorionsys/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server