F
licenseNot graded
qualityB
maintenanceCryptographically verifiable, scope-narrowing delegation chains for AI agents, enabling human-anchored authorization across multiple hops.
-
Kevros — Agentic Identity Trust
Server Details
Agentic identity trust: precision decisioning, cryptographic release tokens, hash-chained proof
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ndl-systems/kevros-sdk
- GitHub Stars
- 1
Available Tools
9 toolsattestAttest ActionAInspect
Create a hash-chained provenance record for an action you've taken. Each attestation extends the append-only evidence chain. The hash can be independently verified by any third party. Cost: $0.02 per call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional metadata such as environment, trigger, or session info | |
| agent_id | Yes | Unique identifier of the attesting agent | |
| action_payload | Yes | Structured data describing the action (hashed into provenance) | |
| action_description | Yes | Human-readable description of the action taken |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the behavioral disclosure burden. It reveals that each attestation extends an "append-only evidence chain" (implying irreversibility) and states the cost per call, both of which add value beyond the annotations. It does not detail authorization or rate limits, but the append-only nature is a key constraint that is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a cost clause, with no filler. The purpose, key behavioral trait (append-only), verifiability, and cost are all front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the full schema coverage and presence of an output schema, covers the essential aspects: purpose, behavior (append-only), cost, and parameters. It lacks explicit warnings about prerequisites or failure modes, but the append-only nature is key and stated. Slightly more context about relationship to verification tools would help, but the tool is self-contained for its simple function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all 4 parameters (100% coverage), so a baseline of 3 applies. The description adds no parameter-specific detail beyond implying that `action_description` and `action_payload` capture the action taken, which is already evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "Create a hash-chained provenance record for an action you've taken," identifying the specific verb (create) and resource (provenance record). It distinguishes from sibling verification tools like `verify` and `check-peer` by emphasizing record creation and chain extension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "for an action you've taken" sets a clear context for when to use the tool. However, it does not explicitly exclude verification or other sibling tools, nor does it mention alternatives. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bindBind Intent to CommandAInspect
Declare an intent and cryptographically bind it to a command. Proves that the command was issued in service of the declared intent. Use verify-outcome after execution to close the loop. Cost: $0.02 per call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Unique identifier of the agent declaring intent | |
| goal_state | No | Expected end state for outcome verification | |
| intent_type | Yes | Category of intent (e.g. 'navigation', 'transaction', 'deployment') | |
| intent_source | No | Origin of intent: AI_PLANNER, HUMAN_OPERATOR, or SYSTEM | AI_PLANNER |
| command_payload | Yes | The command that will be executed to fulfill this intent | |
| parent_intent_id | No | ID of parent intent for hierarchical intent chains | |
| intent_description | Yes | Human-readable description of what the agent intends to do |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false, destructiveHint=false, etc., which are uninformative. The description adds valuable behavioral context: 'Proves that the command was issued in service of the declared intent' and states a cost of '$0.02 per call.' These go beyond the basic hints and give the agent a sense of side effects and billing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: core function, proof guarantee, and workflow/cost. Every sentence earns its place, is front-loaded with the primary action, and has no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with an output schema, the description covers the essential lifecycle (bind then verify-outcome), explains the cryptographic purpose, and notes cost. It does not discuss parameter behavior or output format, but those are handled by the schema, making it adequately complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents all 7 parameters. The description adds no specific parameter-level guidance beyond the general intent/command concept. Baseline 3 applies since the description does not need to repeat schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Declare an intent and cryptographically bind it to a command.' It uses a specific verb ('bind') and resource ('intent to command'), and distinguishes itself from sibling verification tools by emphasizing the cryptographic proof and by pointing to verify-outcome as the follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage hint: 'Use verify-outcome after execution to close the loop.' This indicates a sequential workflow. However, it does not explicitly contrast with alternatives like attest, verify, or bundle, so it misses the full 'when/when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bundleGenerate Compliance BundleARead-onlyIdempotentInspect
Generate a certifier-grade compliance evidence bundle. Contains hash-chained provenance, intent bindings, PQC attestations, and verification instructions. Independently verifiable without Kevros access. Cost: $0.05 per call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Agent whose provenance records to include in the bundle | |
| max_records | No | Maximum number of provenance records to include | |
| time_range_end | No | ISO 8601 end time filter (inclusive) | |
| time_range_start | No | ISO 8601 start time filter (inclusive) | |
| include_intent_chains | No | Include intent-command binding chains in the bundle | |
| include_pqc_signatures | No | Include post-quantum ML-DSA-87 block signatures | |
| include_verification_instructions | No | Include step-by-step verification procedure for auditors |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context beyond annotations: the bundle's contents (hash-chained provenance, intent bindings, PQC attestations), the key property of independent verifiability without Kevros access, and the per-call cost of $0.05. This is significant extra behavioral and operational info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short, front-loaded sentences. Each sentence adds unique information: what is generated, what it contains, a key property (independently verifiable), and cost. There is no 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema and well-documented parameters, the description does not need to explain return values or parameter details. It covers the core purpose, contents, verifiability context, and cost, making the tool complete for an agent to decide when to invoke it. The complexity is moderate, but the description plus schema/annotations fully cover the needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 7 parameters, so the schema already carries the parameter meaning. The description does not add extra syntax, formatting, or parameter-specific guidance beyond what is in the schema; it only references the contents generally, which maps to the boolean includes. Hence baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Generate a certifier-grade compliance evidence bundle') and clearly distinguishes from sibling verify/attest tools by emphasizing bundle generation and independent verifiability. It also lists key components (hash-chained provenance, intent bindings, PQC attestations), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool produces a compliance bundle for certifier-grade evidence, independently verifiable without Kevros access, at a known cost. It implies usage when an external verifiable bundle is needed, but does not explicitly mention alternatives or when not to use it relative to siblings like verify or attest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check-peerCheck Peer TrustARead-onlyIdempotentInspect
Check another agent's trust score and governance history. Returns trust score (0-100), chain length, attestation count, and tier. Free, no API key needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ID of the peer agent to look up |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read operation. The description adds value by noting the tool is free, requires no API key, and specifying the exact return fields, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary action and then lists the return values. There is no fluff or redundancy; every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the rich annotations, the existence of an output schema, and the description's inclusion of cost/auth behavior and return fields, the description is fully sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% documentation coverage for the single parameter, with a clear description ('ID of the peer agent to look up'). The tool description does not add further param details, but this is unnecessary given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check') and resource ('another agent's trust score and governance history'), and enumerates the return fields. It distinguishes itself from siblings like verify and status by focusing on peer trust assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a peer's trust, but does not explicitly state when to use it over sibling tools. There is no mention of alternatives or exclusions, though the specificity of the purpose makes the intended context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthHealth CheckBRead-onlyIdempotentInspect
Check the governance gateway health status. Free.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Return additional details such as chain length and PQC signing status |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds 'Free' as a behavioral trait (no cost) and clarifies the target scope, but does not provide deeper details like response structure or side effects beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences. Every word earns its place, with 'Free' conveying a useful behavioral note without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with one optional parameter and an output schema, the description is reasonably complete. Annotations cover safety, the schema covers parameters, and the output schema covers return values. However, the lack of usage guidance and sibling differentiation prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'verbose' is fully described in the schema with its default and purpose. The tool description does not add parameter-level meaning, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the resource ('governance gateway health status'), making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'status' or 'check-peer', so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions it is 'Free' but does not explain scenarios where a health check is preferred over other governance gateway tools, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statusTrust StatusARead-onlyIdempotentInspect
Check your current usage and quota: calls used, calls remaining, tier, rate limits, and billing status. Free.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| include_chain_details | No | Include hash-chain integrity check and latest provenance epoch |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context: 'Free' indicates no monetary cost, and listing 'billing status' implies the tool surfaces financial/account state. This goes beyond the annotation safety profile and gives the agent useful expectations about what the operation checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the primary action ('Check your current usage and quota') and immediately follows with the specific data points. Every word earns its place; no fluff, no irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional boolean parameter) and has an output schema, so the description doesn't need to explain return values. It covers the essential scope (usage, quota, rate limits, billing), mentions cost ('Free'), and is entirely self-contained. The annotations and schema fill any remaining gaps, so no further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter description ('Include hash-chain integrity check and latest provenance epoch'). The tool description itself does not mention the parameter, but since the schema already provides a clear semantic explanation, the description adds no extra value here. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Check' and clearly identifies the resource: 'your current usage and quota'. It enumerates the exact data points (calls used/remaining, tier, rate limits, billing status), making it unmistakably distinct from sibling tools like health or verify, which focus on system status or cryptographic verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to inspect usage and quota. It doesn't explicitly name alternatives or exclusions, but the description's specificity ('calls used, calls remaining, tier, rate limits, billing status') implicitly sets it apart from sibling tools. A 4 is appropriate because it lacks an explicit 'use instead when...' clause, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyVerify ActionAIdempotentInspect
Verify an action against policy bounds before executing it. Returns ALLOW (proceed), CONSTRAIN (proceed with modified values; emitted on the wire as the legacy value CLAMP - both refer to the same verdict, CONSTRAIN is the public name), or DENY (stop). Every verification is recorded in a hash-chained provenance ledger. Cost: $0.01 per call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Unique identifier of the agent requesting verification | |
| action_type | Yes | Category of action to verify (e.g. 'deploy', 'trade', 'send_email') | |
| template_id | No | Named policy template (e.g. 'robotics-arm', 'financial-transaction'). Merged with policy_context. | |
| action_payload | Yes | Action parameters to verify against policy bounds | |
| policy_context | No | Optional policy overrides such as max_values or forbidden_keys | |
| idempotency_key | No | Optional key for idempotent retries - same key returns cached result |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond annotations: it enumerates the three possible verdicts (ALLOW, CONSTRAIN, DENY), explains the legacy CLAMP alias, mentions the hash-chained provenance ledger recording each call, and states the cost per call. This complements the annotation hints effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct, relevant information: purpose, return values, and operational details (ledger + cost). No redundancy or filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, nested objects) and the presence of an output schema, the description covers the essential operational context: when to use it, what it returns, side effects, and cost. It does not delve into error conditions or rate limits, but this is not critical for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema description coverage is 100%, so the description correctly relies on the schema for parameter details. While the tool description references 'policy bounds' which maps to policy_context/action_payload, it does not add specific parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies an action against policy bounds before execution, using a specific verb and resource. It distinguishes from sibling tools like verify-outcome and verify-token by focusing on pre-execution policy verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before executing it' provides clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to understand its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify-outcomeVerify OutcomeAIdempotentInspect
Verify that an executed action achieved its declared intent. Closes the loop: intent -> command -> action -> outcome -> verification. Free (included with bind).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | Unique identifier of the agent whose outcome is being verified | |
| intent_id | Yes | ID of the original intent from governance_bind | |
| tolerance | No | Numeric tolerance for goal matching (0.1 = 10% deviation allowed) | |
| binding_id | Yes | ID of the intent-command binding from governance_bind | |
| actual_state | Yes | Observed end state after action execution, compared against goal_state |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds the conceptual loop and mentions 'Free (included with bind)' but doesn't elaborate on side effects or comparison semantics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose, the second explains the workflow and cost. Minimal fluff, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description outlines the tool's role in a workflow and mentions 'Free (included with bind)', but doesn't mention prerequisites like having a binding_id from governance_bind or how tolerance works. The output schema exists, so return values are presumably covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add extra parameter meaning beyond the schema; it only contextually references 'actual_state' without providing new details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific purpose: 'Verify that an executed action achieved its declared intent.' It distinguishes itself from sibling tools like 'verify-token' by focusing on outcome verification and explicitly outlining the loop: 'intent -> command -> action -> outcome -> verification.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Closes the loop: intent -> command -> action -> outcome -> verification'), implying use after action execution. However, it does not explicitly exclude or compare against alternatives like 'verify' or 'verify-token'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify-tokenVerify Release TokenARead-onlyIdempotentInspect
Verify a release token from another agent. Confirms the token is authentic, was issued by the Kevros gateway, and remains currently authorized after any halt or mode transition. Free, no API key needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| release_token | Yes | Release token string received from governance_verify | |
| token_preimage | No | Deprecated. The gateway now performs verification entirely server-side using the release_token alone; any value supplied here is ignored. Field retained for backward compatibility with v1 SDK callers and will be removed in a future release. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral detail about what verification checks (authenticity, issuer, current authorization) and the lack of an API key requirement, enhancing transparency beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, purpose first, then verification scope, then cost/access. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With schema covering parameters, annotations covering safety, and output schema present, the description adequately covers purpose and usage context for correct invocation. The mention of 'after any halt or mode transition' adds important contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions fully document both parameters, including the deprecation and ignored behavior of token_preimage. The tool description does not add further parameter-level detail, so the baseline 3 applies given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies a release token from another agent, confirming authenticity, gateway issuance, and current authorization. This specific verb-resource combination distinguishes it from general tools like verify and verify-outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: when a release token is received from another agent, especially after halt or mode transitions. It does not explicitly compare against sibling tools like verify or verify-outcome, so no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
verify-token5 fields changed- added
Input schema / properties / token_preimage / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / token_preimage / defaultAdded value: +null - changed
Input schema / properties / token_preimage / descriptionPrevious value: -"Token preimage string received alongside the release token"New value: +"Deprecated. The gateway now performs verification entirely server-side using the release_token alone; any value supplied here is ignored. Field retained for backward compatibility with v1 SDK callers and will be removed in a future release." - removed
Input schema / properties / token_preimage / typeRemoved value: -"string" - changed
Input schema / requiredPrevious value: -[ - "release_token", - "token_preimage" -]New value: +[ + "release_token" +]
1 tool update
- Changed
verify1 field changed- changed
Input schema / properties / idempotency_key / descriptionPrevious value: -"Optional key for idempotent retries — same key returns cached result"New value: +"Optional key for idempotent retries - same key returns cached result"
18 tool updates
- Added
attest - Added
bind - Added
bundle - Added
check-peer - Removed
governance_attest - Removed
governance_bind - Removed
governance_bundle - Removed
governance_check_peer - Removed
governance_health - Removed
governance_verify - Removed
governance_verify_outcome - Removed
governance_verify_token - Added
health - Removed
kevros_status - Added
status - Added
verify - Added
verify-outcome - Added
verify-token
350 tool updates
- Removed
governance_active_schedules - Removed
governance_add_group_member - Removed
governance_add_org_member - Removed
governance_add_timeline_event - Removed
governance_advance_playbook_step - Removed
governance_advance_workflow_step - Removed
governance_agent_communications - Removed
governance_agent_compliance - Removed
governance_agent_heartbeat - Removed
governance_agent_profile - Removed
governance_agent_quota - Removed
governance_analytics_compare - Removed
governance_analytics_summary - Removed
governance_analytics_trends - Removed
governance_anomaly_alerts - Removed
governance_anomaly_baseline - Removed
governance_apply_change_request - Removed
governance_approve_change_request - Removed
governance_approve_enrollment - Removed
governance_approve_gate - Removed
governance_artifact_attestation - Removed
governance_artifact_chain - Removed
governance_assess_risk - Removed
governance_audit_diff - Removed
governance_audit_summary - Removed
governance_batch - Removed
governance_bridge_transfers - Removed
governance_browse_templates - Removed
governance_cache_lookup - Removed
governance_cache_stats - Removed
governance_cancel_schedule - Removed
governance_capability_registry - Removed
governance_cascade_revoke - Removed
governance_cast_vote - Removed
governance_certify_capability - Removed
governance_certify_evidence - Removed
governance_check_audit_access - Removed
governance_check_reversibility - Removed
governance_classification_stats - Removed
governance_comm_clusters - Removed
governance_complete_workflow - Removed
governance_compliance_coverage - Removed
governance_compliance_dashboard - Removed
governance_compliance_evidence - Removed
governance_compliance_map - Removed
governance_compliance_package - Removed
governance_compose_policies - Removed
governance_conclude_ab_test - Removed
governance_configure_cache - Removed
governance_configure_decay - Removed
governance_convert_export - Removed
governance_correlate_agents - Removed
governance_counterfactual - Removed
governance_create_ab_test - Removed
governance_create_alert_rule - Removed
governance_create_anchor - Removed
governance_create_archive - Removed
governance_create_attestation - Removed
governance_create_canary - Removed
governance_create_change_request - Removed
governance_create_escalation_rule - Removed
governance_create_exception - Removed
governance_create_gate - Removed
governance_create_group - Removed
governance_create_mesh_route - Removed
governance_create_org - Removed
governance_create_playbook - Removed
governance_create_policy_override - Removed
governance_create_questionnaire - Removed
governance_create_sandbox - Removed
governance_create_schedule - Removed
governance_create_scoped_token - Removed
governance_create_snapshot - Removed
governance_create_trust_bridge - Removed
governance_create_vote - Removed
governance_create_webhook - Removed
governance_create_workflow - Removed
governance_cross_reference_evidence - Removed
governance_decision_detail - Removed
governance_declare_dependency - Removed
governance_declare_federation - Removed
governance_decommission_agent - Removed
governance_define_slo - Removed
governance_delegate - Removed
governance_delegate_permission - Removed
governance_delete_sandbox - Removed
governance_dependency_graph - Removed
governance_detect_policy_conflicts - Removed
governance_download_export - Removed
governance_download_report - Removed
governance_emergency_override - Removed
governance_emergency_override_audit - Removed
governance_emergency_rotate - Removed
governance_enforce_sandbox - Removed
governance_escalate_violation - Removed
governance_evaluate_alert - Removed
governance_event_correlation - Removed
governance_event_patterns - Removed
governance_evidence_gaps - Removed
governance_execute_playbook - Removed
governance_execute_rotation - Removed
governance_expired_capabilities - Removed
governance_expired_exceptions - Removed
governance_expiring_delegations - Removed
governance_explain_batch - Removed
governance_explain_decision - Removed
governance_export_audit_trail - Removed
governance_export_evidence - Removed
governance_failure_impact - Removed
governance_finalize_report - Removed
governance_fleet_agent_health - Removed
governance_fleet_health - Removed
governance_generate_report - Removed
governance_get_ab_test - Removed
governance_get_agent_capabilities - Removed
governance_get_agent_health - Removed
governance_get_attestation - Removed
governance_get_baseline - Removed
governance_get_capability_scores - Removed
governance_get_classification - Removed
governance_get_composed_policy - Removed
governance_get_enrollment - Removed
governance_get_exception - Removed
governance_get_gate - Removed
governance_get_group - Removed
governance_get_mesh_route - Removed
governance_get_notification_prefs - Removed
governance_get_org - Removed
governance_get_permission_delegation - Removed
governance_get_playbook - Removed
governance_get_protocol - Removed
governance_get_questionnaire - Removed
governance_get_report - Removed
governance_get_rotation - Removed
governance_get_sandbox - Removed
governance_get_simulation - Removed
governance_get_timeline - Removed
governance_get_trust_bridge - Removed
governance_get_workflow - Removed
governance_grant_audit_consent - Removed
governance_health_dashboard - Removed
governance_health_score - Removed
governance_import_template - Removed
governance_integrity_check - Removed
governance_integrity_report - Removed
governance_integrity_status - Removed
governance_intent_ancestry - Removed
governance_intent_children - Removed
governance_intent_lifecycle - Removed
governance_intent_transition - Removed
governance_invalidate_cache - Removed
governance_key_status - Removed
governance_label_data - Removed
governance_learn_baseline - Removed
governance_link_outcome - Removed
governance_list_ab_tests - Removed
governance_list_agent_keys - Removed
governance_list_agents - Removed
governance_list_alert_rules - Removed
governance_list_anchors - Removed
governance_list_archives - Removed
governance_list_attestations - Removed
governance_list_audit_consent - Removed
governance_list_bridges - Removed
governance_list_canaries - Removed
governance_list_capabilities - Removed
governance_list_change_requests - Removed
governance_list_classifications - Removed
governance_list_credentials - Removed
governance_list_delegations - Removed
governance_list_emergency_overrides - Removed
governance_list_enrollments - Removed
governance_list_escalation_rules - Removed
governance_list_exceptions - Removed
governance_list_export_schedules - Removed
governance_list_federations - Removed
governance_list_frameworks - Removed
governance_list_gates - Removed
governance_list_groups - Removed
governance_list_mesh_routes - Removed
governance_list_org_members - Removed
governance_list_outcome_linkages - Removed
governance_list_permission_delegations - Removed
governance_list_playbooks - Removed
governance_list_policy_overrides - Removed
governance_list_proposals - Removed
governance_list_quarantined - Removed
governance_list_questionnaires - Removed
governance_list_regions - Removed
governance_list_remediations - Removed
governance_list_reports - Removed
governance_list_rotations - Removed
governance_list_sandboxes - Removed
governance_list_schedules - Removed
governance_list_scopes - Removed
governance_list_simulations - Removed
governance_list_sla_violations - Removed
governance_list_snapshots - Removed
governance_list_webhook_deliveries - Removed
governance_list_webhooks - Removed
governance_list_workflows - Removed
governance_log_stream - Removed
governance_log_stream_cursors - Removed
governance_mesh_topology - Removed
governance_metrics - Removed
governance_nonce_status - Removed
governance_notification_history - Removed
governance_peer_recommendations - Removed
governance_permission_chain - Removed
governance_policy_chain - Removed
governance_policy_coverage_report - Removed
governance_policy_diff - Removed
governance_policy_history - Removed
governance_policy_impact - Removed
governance_policy_snapshot - Removed
governance_promote_canary - Removed
governance_propose_policy - Removed
governance_protocol_violations - Removed
governance_publish_template - Removed
governance_quarantine_agent - Removed
governance_query_ledger - Removed
governance_rbac_assign - Removed
governance_rbac_roles - Removed
governance_reactivate_agent - Removed
governance_reconstruct_incident - Removed
governance_record_communication - Removed
governance_region_status - Removed
governance_register_agent - Removed
governance_register_agent_key - Removed
governance_register_capabilities - Removed
governance_register_protocol - Removed
governance_register_region - Removed
governance_register_signing_key - Removed
governance_reject_enrollment - Removed
governance_reject_gate - Removed
governance_relay_acknowledge - Removed
governance_relay_inbox - Removed
governance_relay_send - Removed
governance_relay_stats - Removed
governance_release_agent - Removed
governance_remove_group_member - Removed
governance_replay - Removed
governance_replay_audit - Removed
governance_replay_batch - Removed
governance_replay_decision - Removed
governance_replay_results - Removed
governance_report_sla_violation - Removed
governance_reputation_decay - Removed
governance_request_enrollment - Removed
governance_retention_policy - Removed
governance_retry_webhook - Removed
governance_reversibility_score - Removed
governance_revocation_impact - Removed
governance_revoke_agent_key - Removed
governance_revoke_audit_consent - Removed
governance_revoke_delegation - Removed
governance_revoke_emergency_override - Removed
governance_revoke_exception - Removed
governance_revoke_federation - Removed
governance_revoke_permission - Removed
governance_revoke_scoped_token - Removed
governance_risk_dashboard - Removed
governance_risk_thresholds - Removed
governance_rollback_canary - Removed
governance_root_cause - Removed
governance_rotate_agent_key - Removed
governance_rotate_credential - Removed
governance_rotate_key - Removed
governance_route_to_best - Removed
governance_run_simulation - Removed
governance_sandbox_results - Removed
governance_scan_classification - Removed
governance_schedule_export - Removed
governance_schedule_rotation - Removed
governance_score_baseline - Removed
governance_score_questionnaire - Removed
governance_seal_audit_trail - Removed
governance_send_webhook - Removed
governance_set_agent_limit - Removed
governance_set_capability_score - Removed
governance_set_notification_prefs - Removed
governance_set_retention_policy - Removed
governance_set_risk_thresholds - Removed
governance_sign_attestation - Removed
governance_silence_alert - Removed
governance_similar_agents - Removed
governance_simulate_policy - Removed
governance_simulate_rollback - Removed
governance_simulation_results - Removed
governance_sla_dashboard - Removed
governance_sla_metrics - Removed
governance_slo_status - Removed
governance_spatial_anomaly_define_rule - Removed
governance_spatial_anomaly_detect - Removed
governance_spatial_anomaly_history - Removed
governance_spatial_domain_feed - Removed
governance_spatial_domain_ingest - Removed
governance_spatial_domain_register - Removed
governance_spatial_domains_list - Removed
governance_spatial_entities_list - Removed
governance_spatial_entity_deactivate - Removed
governance_spatial_entity_get - Removed
governance_spatial_entity_register - Removed
governance_spatial_entity_update_position - Removed
governance_spatial_fleet_coverage - Removed
governance_spatial_fleet_status - Removed
governance_spatial_fusion_correlate - Removed
governance_spatial_geofence_check - Removed
governance_spatial_geofence_create - Removed
governance_spatial_geofence_deactivate - Removed
governance_spatial_geofence_get - Removed
governance_spatial_geofences_list - Removed
governance_spatial_query_containment - Removed
governance_spatial_query_corridor - Removed
governance_spatial_query_history - Removed
governance_spatial_query_proximity - Removed
governance_spatial_query_separation - Removed
governance_spatial_trajectories_list - Removed
governance_spatial_trajectory_authorize - Removed
governance_spatial_trajectory_check_deviation - Removed
governance_spatial_trajectory_get - Removed
governance_spatial_trajectory_revoke - Removed
governance_stale_agents - Removed
governance_state_at_time - Removed
governance_store_credential - Removed
governance_submit_questionnaire - Removed
governance_suspend_agent - Removed
governance_sync_region - Removed
governance_test_notification - Removed
governance_test_policy - Removed
governance_timeline_gaps - Removed
governance_timeline_milestones - Removed
governance_toggle_mesh_route - Removed
governance_trigger_remediation - Removed
governance_trust_graph - Removed
governance_upcoming_rotations - Removed
governance_update_policy - Removed
governance_validate_composition - Removed
governance_validate_policy_constraints - Removed
governance_validate_protocol_message - Removed
governance_validate_token - Removed
governance_vault_access_log - Removed
governance_verify_bridge_transfer - Removed
governance_verify_capability - Removed
governance_verify_federation - Removed
governance_verify_seal - Removed
governance_verify_signature - Removed
governance_vote_result - Removed
governance_vouch_for_peer - Removed
governance_webhook_dead_letter
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Zero-knowledge attestation for agent capability and trust score claims
Policy gate and signed trust receipts for autonomous agent actions.
HiveMorph polymorphic identity and capability tokens for autonomous agents
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
11
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceW3C DID resolution and agent KYC for autonomous agent counterparties, enabling identity verification and trust scoring.MIT
evermint-mcpofficial
AlicenseNot gradedqualityDmaintenanceTamper-evident receipts for AI agent actions. The notary layer for agent-to-agent transactions.701MIT- AlicenseNot gradedqualityAmaintenanceEnables AI agents to query cryptographically verified facts with zero-knowledge proofs, selective disclosure, and tamper-evident provenance.5851Apache 2.0
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.1/5.0
Disambiguation5/5
Each tool targets a distinct action or resource: attest creates provenance records, bind declares intent, bundle aggregates evidence, verify checks policy pre-execution, verify-outcome validates results, and verify-token authenticates release tokens. Even the verify-* family is clearly differentiated by timing and purpose.
Naming Consistency4/5
Tool names consistently use lowercase imperative verbs, with hyphenated modifiers for multi-word names (check-peer, verify-outcome, verify-token). The pattern is mostly consistent, though some tools are bare verbs (attest, bind, health) while others include a noun, creating a minor deviation from strict verb_noun style.
Tool Count5/5
Nine tools is well within the ideal range for this domain. Each tool serves a clear purpose in the agentic identity trust lifecycle, from evidence creation to verification and peer assessment, without redundancy or excessive sprawl.
Completeness4/5
The tool surface covers the core workflow: intent binding, policy verification, provenance attestation, outcome verification, token verification, and compliance bundling. Minor gaps exist such as missing explicit revocation or role management, but agents can complete the primary governance lifecycle.