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., "@telos-mcp Score an action 'deploy_contract' for agent-123"
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 for TELOS AI Labs governance.
Exposes TELOS governance primitives -- action scoring, unsigned integrity-hash receipt verification, Purpose Anchor inspection, audit-chain queries, and CCRS counterfactual replay -- as MCP tools, resources, and prompts. Any MCP-compatible client (Claude Desktop, Claude Code, Cursor, Cline, etc.) can call them as native tools.
v0.1 status. This release ships the protocol surface with stubbed engine calls so clients can exercise every tool, resource, and prompt end-to-end without an installed engine. Scores are synthetic and receipts are unsigned integrity-hash receipts (
signature: null,signing_status: "unsigned_integrity_hash"): a key-free SHA-256 over the receipt payload, not a digital signature. v0.2 wires the livetelos-govengine behind the same receipt shape, and a real signature fills the existingsignaturefield then, with no schema break.
Tool | Purpose |
| Score a proposed action against the active Purpose Anchor. Returns verdict ( |
| Verify an unsigned integrity-hash receipt offline (key-free; not a signature check). Returns |
| Return the active Purpose Anchor: purpose, hard boundaries, declared scope, allowed tools, centroid dimensions. |
| Return audit-chain entries within a time window (capped at 100). |
| Queue a CCRS counterfactual replay against an alternate config; returns a |
URI template | Returns |
| A TELOS governance wiki page by relative path. |
| Compiled centroid metadata for one of |
| The audit-chain segment for a given |
Prompt | Purpose |
| Have the model review a proposed action for governance compliance. |
| Walk through the audit chain in a date window. |
Related MCP server: aman-mcp
pip install telos-mcpThe live engine (telos-gov) lands in v0.2, after the clean-facade
republish. v0.1 ships no installable engine extra; the stub is the only
supported engine. (telos-mcp[engine] returns in v0.2 pinned to the
republished clean facade.)
The package installs a telos-mcp console script that starts the server
over stdio. You can also invoke it via python -m telos_mcp.server.
Requires Python 3.10+.
Each client below assumes telos-mcp is installed in a Python environment
on PATH. If you prefer not to install globally, use uvx telos-mcp or
substitute the absolute path to the telos-mcp script in the snippets.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows). Add
the telos-governance entry under mcpServers:
{
"mcpServers": {
"telos-governance": {
"command": "telos-mcp",
"args": [],
"env": {
"TELOS_AGENT_ID": "claude-desktop-default"
}
}
}
}Restart Claude Desktop. The five telos_* tools should appear in the
MCP tool tray.
Use the claude mcp add CLI:
claude mcp add telos-governance -- telos-mcpOr edit ~/.config/claude-code/mcp_servers.json directly:
{
"telos-governance": {
"command": "telos-mcp",
"args": []
}
}Edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project):
{
"mcpServers": {
"telos-governance": {
"command": "telos-mcp",
"args": [],
"env": {
"TELOS_AGENT_ID": "cursor-default"
}
}
}
}Open Cline -> MCP Servers -> Edit Configuration. Add:
{
"mcpServers": {
"telos-governance": {
"command": "telos-mcp",
"args": [],
"transportType": "stdio"
}
}
}From any client, ask:
Use the
telos_get_patool withagent_id="test"and show the Purpose Anchor.
You should see a stub PA back containing "stub": true and the six
canonical centroid dimensions.
git clone https://github.com/TELOS-Labs-AI/telos-mcp
cd telos-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
# Run the server over stdio (what MCP clients spawn):
python -m telos_mcp.server
# Or use the MCP Inspector for interactive exploration:
mcp dev telos_mcp/server.pyv0.1 (this release) -- protocol surface complete, engine stubbed, registry-submission-ready manifest.
v0.2 -- swap stubs for live telos-gov calls (after the clean-facade
republish). Receipts gain a real signature after the signing ceremony, filling
the existing signature field with no schema break. telos-gov becomes a
hard dependency.
v0.3 -- streaming audit subscriptions, per-tenant PA selection via
TELOS_TENANT env, optional HTTP transport.
Apache-2.0. See LICENSE.
TELOS AI Labs: https://telos-labs.ai
Return audit chain entries within a time window.
Capped at 100 entries to keep MCP payloads bounded. For deeper queries,
use the telos://audit/{date} resource per-day.
Args: start_iso: ISO-8601 window start (e.g. "2026-04-25T00:00:00Z"). end_iso: ISO-8601 window end (must be later than start).
Returns: Dict with keys: entries (list, max 100), count, capped (bool), window {start, end}.
| Name | Required | Description | Default |
|---|---|---|---|
| end_iso | Yes | ||
| start_iso | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so the description bears full responsibility. It discloses the 100-entry cap, the return structure including a 'capped' boolean, and the required ordering of parameters.
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?
Well-structured with summary, cap note, args, and returns sections. Concise enough but could be slightly tighter.
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 2 parameters and an output schema (implicit from description), the description covers all necessary context: input format, cap, return shape. No gaps.
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 0%, but the description fully explains both parameters: ISO-8601 format with examples, and the constraint that end_iso must be later than start_iso.
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 it 'Return audit chain entries within a time window' using a specific verb and resource. The sibling tools (telos_score, telos_verify, etc.) have distinct names, so no confusion.
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?
Describes when to use (audit queries) and provides a when-not (deeper queries via the resource). Does not explicitly contrast with siblings but their names imply different functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the active Purpose Anchor for an agent.
The PA is the governance contract: purpose statement, hard boundaries, declared scope, allowed tool list, and the centroid dimensions used to score the agent's actions.
Args: agent_id: Stable identifier of the agent whose PA to load.
Returns: Dict with keys: agent_id, pa_id, purpose, boundaries, scope, allowed_tools, centroid_dimensions, compiled_at, stub.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implicitly indicates a read operation but does not explicitly state it is read-only, nor does it cover permissions, error handling, or edge cases like invalid agent_id.
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 concise and well-structured: a one-line purpose, a helpful paragraph on what the PA is, and clearly labeled Args and Returns sections. Every sentence adds value.
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?
Given the tool's simplicity, the description covers purpose, parameter, and return structure adequately. However, it lacks error handling or prerequisite information, making it slightly incomplete.
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?
Despite 0% schema coverage, the description includes an 'Args' section that clearly describes agent_id as 'Stable identifier of the agent whose PA to load', adding meaning over the schema's minimal title.
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 'Return the active Purpose Anchor for an agent' with a specific verb and resource, and distinguishes from siblings like telos_score and telos_verify which perform different 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?
The description implies usage for retrieving governance settings but does not explicitly state when to use this tool over siblings or provide exclusion criteria. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a CCRS counterfactual replay against an alternate config.
CCRS Mode C re-runs the lifecycle that produced receipt_id under a
different governance configuration (alt thresholds, alt centroids,
alt PA) and reports verdict deltas. Returns immediately with a job id;
poll the result via telos://replay/{job_id} once available.
Args: receipt_id: ID of the receipt to replay against. alt_config_path: Path to the alternate config (YAML) to apply.
Returns: Dict with keys: job_id, receipt_id, alt_config_path, status, queued_at, estimated_runtime_seconds, result_uri, stub.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | ||
| alt_config_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior ('Returns immediately with a job id; poll the result'), includes return keys. No annotations provided, so description carries the burden well. Could mention side effects or permissions.
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?
Well-structured with summary and docstring sections (Args, Returns). Slightly verbose but front-loads purpose. Every sentence adds value.
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?
Covers input parameters, async behavior, and return format. Lacks clarification on CCRS and Mode C terminology. Output schema presumed from description.
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 0%, but description adds detailed semantics: 'receipt_id: ID of the receipt to replay against' and 'alt_config_path: Path to the alternate config (YAML) to apply.' Adds meaning beyond property names.
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?
Explicitly states 'Queue a CCRS counterfactual replay against an alternate config,' with specific verb and resource. Distinct from siblings like telos_score and telos_verify, which are about scoring and verifying.
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?
Implies usage via description of functionality but no explicit when-to-use or alternatives. No exclusions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a proposed agent action against the active Purpose Anchor.
Returns a verdict (EXECUTE / CLARIFY / ESCALATE) plus a 6-dimension
score breakdown across purpose, scope, boundary, tool, chain, and
codebase_fidelity. Each call also mints an unsigned integrity-hash
receipt (shared telos-receipt envelope) that telos_verify -- and the
telos-trust-surface -- can verify with no translation.
Args: action_name: Name of the action being proposed (e.g. "write_file"). action_params: Parameter dict the agent intends to pass to the action. agent_id: Stable identifier of the agent proposing the action.
Returns: Dict with keys: verdict, composite_score, scores, agent_id, action_name, receipt, stub, engine.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| action_name | Yes | ||
| action_params | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It describes the return format and the receipt miniting but does not disclose whether the tool has side effects, requires authentication, or is read-only. The behavior is partially transparent.
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 well-structured with sections, front-loads the core purpose, and provides necessary details. While slightly lengthy, it earns its space given the tool's complexity.
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?
Given the tool has three parameters, an output schema with nested objects, and a complex return, the description covers the verdict, scores, and receipt. It could add more detail on the dimension breakdown but is sufficient for an agent to understand core behavior.
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?
With 0% schema description coverage, the description adds meaningful context for all three parameters via the Args section, explaining each parameter's role. However, it does not detail types or constraints 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 scores a proposed agent action against the active Purpose Anchor, returning a verdict and 6-dimension breakdown. It also mentions the minting of an integrity-hash receipt for verification by telos_verify, distinguishing it from siblings.
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 implies the tool is used to score actions against the purpose anchor but does not explicitly state when to use it over siblings like telos_verify or telos_audit. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an unsigned integrity-hash receipt offline.
Recomputes the receipt's integrity hash over its canonical payload using the shared telos-receipt contract -- the same verifier the trust surface runs -- so the answer matches end-to-end. Key-free; not a signature check.
Args: receipt_json: The receipt to verify, either as a JSON string or as a JSON object (clients may pass either; both are accepted).
Returns: Dict with keys: match (bool), stated_integrity_hash, recomputed_integrity_hash, covered_fields, signing_status, note, reason.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_json | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it recomputes the integrity hash, is key-free, not a signature check, and returns specific fields. This is sufficient transparency for a read-only verification, though potential errors or side effects are not mentioned.
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 well-structured with Args and Returns sections, making it easy to parse. It is concise but contains some redundancy (e.g., 'receipt' mentioned multiple times). Overall, it earns its length without being verbose.
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 single-parameter tool with an implied output schema, the description is quite complete, covering the return keys and the verification process. It lacks error handling info, but given the tool's simplicity, it provides sufficient context for an AI agent.
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 provides only a type: string for receipt_json. The description adds that it can be a JSON string or object, and describes the return dict in detail. This adds significant meaning beyond the schema, though more precise format requirements could help.
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 verifies an unsigned integrity-hash receipt offline, using a specific contract. It explains the action and distinguishes from a signature check. However, it does not explicitly differentiate from sibling tools like telos_score or telos_audit, leaving the AI to infer 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 implies usage via phrases like 'offline' and 'key-free', suggesting it is for verification without keys. But it lacks explicit guidance on when to use this vs. alternatives (e.g., telos_score for scoring, telos_audit for auditing). No when-not-to or exclusion criteria are provided.
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.1.0telos_audittelos_get_patelos_replaytelos_scoretelos_verifyEach tool targets a distinct operation: scoring, verification, fetching purpose anchors, auditing, and replay. There is no overlap, and the descriptions clearly differentiate their purposes.
All tool names follow the 'telos_<verb>' pattern (e.g., telos_score, telos_verify, telos_get_pa, telos_audit, telos_replay). The naming is uniform and predictable, with no mixing of styles.
With 5 tools, the server is well-scoped for its governance/audit domain. Each tool serves a necessary function, and the count is neither too few nor too many.
The tool set covers the core workflows: scoring, verification, fetching governance config, auditing, and replay. A potential gap is the absence of a tool to create or update Purpose Anchors, but the set appears complete for the stated monitoring/analysis purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TELOS-Labs-AI/telos-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
