CausalLayer MCP
Server Details
Deterministic AI liability attribution with Bitcoin-anchored proof certificates.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.1/5.
All tools have clearly distinct purposes: pre-response evaluation, preprocessing, submission via two paths, two verification methods, and various queries/simulations. No functional overlap.
All tool names follow a consistent verb_noun pattern (e.g., evaluate_prospective_response, submit_incident, verify_certificate). No mixing of styles or vague verbs.
10 tools cover a specialized domain without bloat. Each tool is justified for the incident attribution lifecycle, from preprocessing to verification.
The tool set covers incident submission, parsing, verification, pre-action gating, jurisdiction, and remediation simulation. Minor gaps exist (e.g., listing certificates), but core workflow is complete.
Available Tools
10 toolsevaluate_prospective_responseAInspect
Deterministic prospective-evaluation gate (FK-METHOD-2026-006). Pass a ProposedAction BEFORE the agent delivers a response; receive one of three verdicts: 'allow', 'require_revision' (with specific factor-keyed directives), or 'block'. Uses the same four-factor engine that issues post-hoc certificates, so a single incident chains: prospective_pre_image -> response -> certificate -> anchor. This is a policy gate on structured action metadata, NOT a content safety classifier on raw prose. Thresholds are per-jurisdiction (EU strictest, US most permissive); read via GET /api/v2/gate/thresholds. Overrides are allowed but REQUIRE a governance rationale so the audit trail is complete. Cost: 1 credit. Pure deterministic.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The structured ProposedAction to evaluate. | |
| overrides | No | Optional per-call threshold override. Rationale REQUIRED for audit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: determinism, four-factor engine, incident chaining, cost of 1 credit, per-jurisdiction thresholds, and override audit requirements. It clearly clarifies it is not a content safety classifier.
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 detailed but efficient, covering all necessary aspects. It is front-loaded with the main purpose. While a bit lengthy, every sentence adds value, and the structure is logical.
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 tool with nested objects, no output schema, and 2 parameters, the description covers input structure, behavior (verdicts, chaining), costs, and thresholds. It lacks explicit return format details but adequately describes the three verdict outcomes.
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%, so baseline is 3. The description adds context by explaining the 'action' object as a ProposedAction and mentions the three verdicts, but does not add significant meaning beyond the schema for individual parameters.
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 identifies the tool as a 'deterministic prospective-evaluation gate' for evaluating a ProposedAction before delivery, returning one of three verdicts. It distinguishes itself from siblings by stating it's 'a policy gate on structured action metadata, NOT a content safety classifier on raw prose.'
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 specifies when to use the tool ('before the agent delivers a response') and explains the three verdicts. It mentions per-jurisdiction thresholds and the requirement for overrides with rationale. However, it does not explicitly compare to siblings or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_incidentAInspect
Claude-powered structured extractor. Parses unstructured text (news articles, court filings, emails, PDFs, incident reports, logs) into the typed JSON schema required by submit_incident. Returns a ready-to-submit incident object with extracted agents, events, severity, jurisdiction, and financial impact. NOTE: This is a pre-processing convenience tool — the deterministic scoring engine itself remains LLM-free. Cost: 10 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Unstructured text to extract from. Can be a news article, court filing, incident report, email, PDF text, log output, or any description of an AI incident. | |
| context_hint | No | Optional hint about the source type (e.g., 'court filing', 'news article', 'internal incident report') to improve extraction accuracy. | |
| jurisdiction_hint | No | Optional ISO country code hint if the jurisdiction is known (e.g., 'AU', 'US', 'EU'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is Claude-powered (LLM), costs 10 credits, and clarifies that the main scoring engine remains LLM-free. This adds behavioral context, though it could mention potential imperfections or error conditions.
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 concise sentences front-load key information. Every sentence adds value: purpose, input types, output, note about scoring engine, and cost. No irrelevant details.
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 no output schema, the description explains the return format and connects to submit_incident. It lacks details on error handling or extraction reliability, but covers the core aspects adequately.
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 baseline is 3. The description adds value by explaining the output structure (agents, events, severity, etc.) and tying the parameters to the overall extraction goal, going beyond the schema's parameter 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 clearly states it is a structured extractor that parses unstructured text into a JSON schema for submit_incident. It lists various input types and explicitly differentiates from the deterministic scoring engine and sibling tools like submit_incident.
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 use before submit_incident by stating it returns a ready-to-submit incident object. It mentions cost and that it's a pre-processing convenience tool, providing clear context for when to use, though it does not explicitly state when not to use or offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_anchor_statusBInspect
Return the index of all CausalLayer Tessera anchor batches, or one batch's full JSON (signed Merkle root, leaves, OpenTimestamps proof reference). FREE.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Optional anchor version, e.g. '2026-05-16-v1.6.4-simulation-calibration'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'FREE', which does not communicate behavioral traits like authentication needs, rate limits, or side effects. The tool is read-only, but this is implied rather than stated.
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 a single sentence but includes extraneous 'FREE.' that adds little value. It is reasonably concise but could be better structured, e.g., separating the two output modes.
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 simplicity (one optional param, no output schema, no annotations), the description is nearly complete. It explains the two possible outputs. However, it lacks details on error behavior or the format of the index/JSON, limiting completeness.
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 description does not add value beyond the input schema, which already documents the single optional parameter with an example. Since schema coverage is 100%, the baseline score 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 clearly states the tool returns either an index of all anchor batches or the full JSON of a specific batch. It identifies the resource (CausalLayer Tessera anchor batches) and the specific action. Since sibling tools are unrelated, no differentiation is needed.
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 no guidance on when to use this tool versus alternatives. The only hint is 'FREE', which is ambiguous and not actionable. No exclusions, prerequisites, or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_issuer_registryAInspect
Return the CausalLayer issuer registry, or one issuer record. The registry lists all trusted public-key fingerprints, key algorithms, validity windows, and the anchor-log repo for each active issuer. FREE — no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer_id | No | Optional issuer id, e.g. 'causallayer-prod-2026-q2'. If omitted, returns the full registry. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool returns data (implied read-only) and lists registry contents. It also notes no API key needed. No side effects or destructive actions are mentioned, which is consistent with a query tool.
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, no unnecessary words. Front-loaded with the core function, then lists registry fields and ends with cost/access note. 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?
For a simple tool with one optional parameter and no output schema, the description is complete. It explains input behavior (full registry vs. single record) and what the output contains (fields), sufficient for correct 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% with a description for the optional issuer_id parameter that matches the tool's overall purpose. The description adds little beyond the schema, meeting the baseline but not exceeding it.
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?
Description clearly states the tool returns either the full CausalLayer issuer registry or a single issuer record, listing included fields (fingerprints, algorithms, etc.). This distinguishes it from sibling tools like verify_certificate or get_anchor_status.
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?
Description mentions 'FREE — no API key required', which provides basic usage guidance but lacks explicit when-to-use-this vs. alternatives. Given the tool's simplicity, this is adequate but not exceptional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_jurisdiction_overlayAInspect
Multi-jurisdiction overlay (FK-METHOD-2026-004). Given a canonical attributable apportionment (party-id -> share), the union of all jurisdiction role tags on each actor, and the union of jurisdiction-specific flags, return side-by-side post-overlay shares for AU, EU, US, UK, CA (or a chosen subset) with the specific rules that fired in each, citation URLs, and a parties × jurisdictions matrix. v1 ships full implementations for AU and EU; US/UK/CA are research stubs marked is_stub: true. Use GET /api/v2/jurisdiction/catalog to discover support and stub status. Cost: 1 credit. Pure deterministic.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | Yes | Union of jurisdiction-specific flags. AI Act / PLD flags drive the EU overlay; ACL / CPS 230 / VAISS flags drive the AU overlay. | |
| actors | Yes | All actors with the union of jurisdiction-specific role tags. EU and AU tags coexist on the same actor record. | |
| attributable | Yes | Canonical pre-overlay apportionment as { party_id: share }. Sum should approximate 1.0; the function renormalises within tolerance. | |
| jurisdictions | No | Optional subset to compute. Defaults to all five. | |
| primaryJurisdiction | No | Engine-level jurisdiction string (e.g. 'EU', 'DE', 'AU'). Used by the EU gate to decide engagement. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is 'Pure deterministic', has a cost of 1 credit, that US/UK/CA implementations are stubs, and that the function renormalizes input. It lacks explicit read-only indication but the context implies a query 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?
The description is well-structured with front-loaded purpose, followed by specific details. Every sentence adds value (stub status, discovery endpoint, cost, determinism). 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?
Given the tool's complexity (5 params, nested objects, no output schema), the description covers input, behavior, output, and discovery. It mentions output as 'side-by-side shares, rules, citations, matrix' but lacks detail on error handling or rate limits. Still highly complete.
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%, so baseline is 3. The description adds significant value by explaining which flags drive which overlays (AI Act/PLD for EU, ACL/CPS230/VAISS for AU), that actors have coexisting EU and AU tags, and that attributable sum renormalizes. This enriches the schema's context.
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 ('compute') and resource ('multi-jurisdiction overlay'), specifies the output (side-by-side shares, rules, citations, matrix), and distinguishes from sibling tools by being the only jurisdiction-overlay tool. It also includes a discovery endpoint for support.
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 context ('Given a canonical attributable apportionment...') and provides explicit guidance to use GET /api/v2/jurisdiction/catalog for discovering support. However, it does not explicitly state when not to use this tool or how it differs from siblings like evaluate_prospective_response.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_remediationAInspect
Counterfactual remediation simulator. Given a certificate's verdict + fourFactorScoring + agents and a list of remediation IDs from the FK-METHOD-2026-003 catalog, return the apportioned shares each remediation would have produced (in isolation) and the composite shares if they all stack. Every remediation cites a specific statute or standard. GET /api/v2/remediation/catalog for the list of IDs. Cost: 1 credit (same price as verify_certificate). Pure deterministic; same inputs produce a byte-identical result.
| Name | Required | Description | Default |
|---|---|---|---|
| agents | Yes | Agent registry (id + type) so the simulator can map remediation targetType to specific party ids. | |
| verdict | Yes | The verdict block from the CausalCertificate. | |
| remediations | Yes | List of remediation IDs from the catalog (e.g. vendor_adversarial_eval_suite, deployer_human_in_loop). Each may optionally pin appliedToParty to a specific agent id. | |
| fourFactorScoring | Yes | The fourFactorScoring block from the CausalCertificate. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: deterministic (byte-identical result), cost (1 credit same as verify_certificate), and output (apportioned shares, composite shares). It also notes that each remediation cites a statute/standard, adding context beyond the schema.
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 a single paragraph that efficiently covers purpose, inputs, outputs, catalog access, cost, and determinism. It is front-loaded with the purpose. It could be slightly trimmed, but each sentence serves a purpose.
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 explains inputs and outputs reasonably, but the output format (return structure) is not fully detailed: it mentions 'apportioned shares' and 'composite shares' without a schema, leaving some ambiguity. For a complex tool with no output schema, more clarity on return shape would improve completeness.
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 baseline is 3. The description adds meaning: for 'agents', it explains mapping to party ids; for 'verdict' and 'fourFactorScoring', it specifies they come from CausalCertificate; for 'remediations', it gives examples and optional 'appliedToParty'. This adds value beyond the schema definitions.
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 identifies the tool as a 'Counterfactual remediation simulator' with a specific verb+resource. It states it computes apportioned shares from verdict, scoring, agents, and remediation IDs. It distinguishes itself from sibling tools like verify_certificate and evaluate_prospective_response by focusing on remediation simulation.
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 specifies the required inputs (verdict, fourFactorScoring, agents, remediation IDs) and how to obtain the remediation IDs (GET /api/v2/remediation/catalog). It mentions cost (1 credit) and determinism, guiding when to use. However, it does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_incidentAInspect
Submit an AI incident for deterministic causal liability attribution. Returns a signed CausalCertificate, per-agent liability allocation, evidence-chain completeness, regulatory mapping, and (where keys are configured) a Bitcoin-anchored proof. Cost: 50 credits. Three guardrails apply: PII scan, deterministic-only acknowledgement, and minimum evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| agents | Yes | ||
| events | Yes | ||
| category | No | ||
| currency | No | ||
| severity | No | ||
| description | No | ||
| jurisdiction | No | ||
| pii_acknowledged | No | G1: Set to true ONLY if caller has confirmed PII handling is permitted by their data agreement. False payloads with detected PII will be rejected. | |
| deterministic_only | Yes | G2: Must be true. Acknowledges CausalLayer is deterministic and not LLM-based. | |
| financial_impact_cents | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full transparency burden. It discloses the cost, guardrails, and return types, but lacks details on side effects, failure modes, or authentication needs. The description is adequate but not rich.
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-loading the purpose and then listing key behavioral aspects (cost, guardrails). Every sentence adds value, and there is no 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?
Given 11 parameters, no output schema, and no annotations, the description is insufficient. It omits explanations of complex nested structures (agents, events), error conditions, and return value details. The description does not adequately cover the tool's full context.
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 only 18%, requiring the description to compensate. However, the description only mentions 'title, agents, events, deterministic_only' implicitly via guardrails and does not explain most parameters (e.g., category, jurisdiction, financial_impact_cents). The schema has many nested fields with no narrative 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 submits an AI incident for deterministic causal liability attribution, naming specific return values (CausalCertificate, liability allocation, etc.). It distinguishes from siblings like evaluate_prospective_response and simulate_remediation by focusing on formal submission with attribution.
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 mentions the credit cost and three guardrails (PII scan, deterministic-only, minimum evidence), providing constraints on usage. However, it does not explicitly tell when to use this tool over alternatives, though the context from sibling names helps infer differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_otel_traceAInspect
Convert an OpenTelemetry OTLP JSON trace into a FaultKey incident and return the same deterministic CausalCertificate as submit_incident. Each span becomes an event; service.name groups spans into agents; W3C trace_id and span_id propagate as evidence pointers on the causal graph edges. Cost: 50 credits (same as submit_incident). Three guardrails apply: PII scan, deterministic-only acknowledgement, and minimum evidence (auto-satisfied when the trace has at least 1 span).
| Name | Required | Description | Default |
|---|---|---|---|
| otlp | Yes | OTLP JSON payload with resourceSpans[]. See https://opentelemetry.io/docs/specs/otlp/#json-protobuf-encoding | |
| title | Yes | ||
| category | No | ||
| currency | No | ||
| jurisdiction | No | ||
| pii_acknowledged | No | G1: Set to true ONLY if PII handling is permitted by your data agreement. OTLP traces frequently leak user/session ids in attributes. | |
| deterministic_only | Yes | G2: Must be true. Acknowledges CausalLayer is deterministic. | |
| financial_impact_cents | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses conversion process (spans to events, service.name to agents, trace_id/span_id propagation), cost, and guardrails. No annotations provided, so description carries burden well. No mention of side effects or destructive actions, but tool is creation-oriented.
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?
Single paragraph of four sentences, efficient and informative. Could be slightly more structured but content is well-organized.
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?
Explains key mappings and guardrails but lacks details on return value format and several parameters. Complex tool with 8 params and nested otlp; description does not fully equip agent for all edge cases.
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?
Adds meaning for otlp, title, deterministic_only, and pii_acknowledged. However, with 38% schema coverage, several parameters (category, currency, jurisdiction, financial_impact_cents) are undocumented in description. Partially compensates but incomplete.
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 converts an OTLP JSON trace into a FaultKey incident and distinguishes itself from submit_incident by returning the same deterministic CausalCertificate. Specific verb and resource.
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?
Mentions cost (50 credits), guardrails (PII scan, deterministic-only, minimum evidence), and auto-satisfaction of minimum evidence with 1+ span. Does not explicitly contrast with sibling submit_incident but the purpose is specific to OTLP traces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_certificateAInspect
Independently verify a CausalCertificate end-to-end (signature, Merkle integrity, issuer status against the registry). Cost: 1 credit. In production env, certificates from non-active issuers are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| certificate | Yes | CausalCertificateV1 object as returned by submit_incident.certificate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost and production rejection behavior. No annotations provided, so description carries full burden. Lacks details on error handling, side effects, or rate limits, but the read-only nature is implied by 'independently verify'.
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, no extraneous information. Purpose is front-loaded, and each sentence serves a clear function.
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 verification steps, cost, and production behavior. Lacks return value or error details, but with no output schema, some gap remains. Adequate for a simple verification 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 coverage is 100% with a single parameter. Description adds value by specifying the parameter is 'CausalCertificateV1 object as returned by submit_incident.certificate', guiding the agent on source.
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?
Clearly states the tool verifies a CausalCertificate end-to-end, listing signature, Merkle integrity, and issuer status. The specific verb 'verify' and resource 'CausalCertificate' distinguish it from siblings like 'verify_certificate_recompute'.
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?
Mentions cost (1 credit) and production behavior (rejection of non-active issuers). Provides context on when to use but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_certificate_recomputeAInspect
Independently re-derive a CausalCertificate from its canonical input and compare byte-for-byte against the claimed certificate. This is the strongest verification path: it requires no trust in the issuer or signing key. Cost: 1 credit (same price as verify_certificate). Returns PASS only if every checked field (certificateId, request_hash, merkleRoot, verdict, causalGraph, fourFactorScoring, deviationTaxonomy, euRuleOverlay, cascadeAttenuation, damages, underwriting) matches identically.
| Name | Required | Description | Default |
|---|---|---|---|
| certificate | Yes | The CausalCertificate object claimed by the issuer. | |
| canonicalInput | Yes | The original incident body that produced the certificate — the same JSON originally posted to submit_incident or submit_otel_trace. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: recomputation, byte-for-byte comparison, PASS only if all ten listed fields match, cost of 1 credit. No annotations exist, so description fully carries the burden and does so thoroughly.
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 sentences, each serving a distinct purpose: core action, trust advantage, cost, and field list. No redundancy, front-loaded with key information.
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 no output schema, description covers return condition and all checked fields. References sibling tools for input origin. Fully adequate for an agent to select and 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?
Schema coverage is 100%, but description adds valuable context: 'certificate' is the claimed object, 'canonicalInput' is the original incident body from submit_incident or submit_otel_trace, enhancing understanding beyond schema types.
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?
Description uses specific verb 're-derive' and resource 'CausalCertificate', clearly distinguishing from sibling tools like verify_certificate by emphasizing independent recomputation and byte-for-byte 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?
States it is the strongest verification path requiring no trust, and mentions cost and comparison to verify_certificate. However, lacks explicit 'when not to use' or contrast with other verification methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!