agent-surety
Server Details
Counterparty risk transfer for the agent economy: agents post bonds behind their promises, wronged c
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- jdhart81/viridis-agent-fleet
- GitHub Stars
- 0
- Server Listing
- viridis-agent-fleet
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 3.5/5 across 10 of 10 tools scored. Lowest: 2.7/5.
Each tool has a distinct and well-defined purpose related to surety bonds and agent capabilities. There is no overlap between tools like post_bond, activate_bond, file_claim, slash_bond, etc., making it easy for an agent to select the correct one.
Most tools follow a consistent verb_noun pattern (e.g., activate_bond, file_claim, post_bond). The slight exception is bond_status, which is noun_verb, but it remains clear and predictable within the set.
With 10 tools, the count is well-scoped for the domain of surety bonds and agent operations. Each tool serves a necessary function without redundancy, striking a good balance between coverage and simplicity.
The tool set covers the full lifecycle of a bond: posting, pricing, activating, listing, status, claiming, slashing, releasing, and audit verification. The inclusion of describe_agent for capabilities ensures no obvious gaps for the intended purpose.
Available Tools
10 toolsactivate_bondBInspect
Mark a POSTED bond ACTIVE (idempotent). funding_ref links the payment rail transaction that funded the stake.
| Name | Required | Description | Default |
|---|---|---|---|
| bond_id | Yes | ||
| funding_ref | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions idempotency, which is helpful, but lacks details on side effects, reversibility, error states, or what 'ACTIVE' entails. The behavioral disclosure is insufficient for a state-mutation 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, front-loaded with purpose, no redundancy. Every word earns its place.
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?
Has an output schema, so return values are covered. However, the description lacks context about the bond lifecycle (e.g., must be POSTED, what happens if already ACTIVE) and does not guide when to use this tool relative to siblings. Adequate but with gaps given the tool's complexity.
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 0%. The description adds meaning to 'funding_ref' by explaining its role, but provides no extra context for 'bond_id'. Partial improvement over schema alone.
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 verb 'mark active' and the resource 'bond', specifying it applies to POSTED bonds and is idempotent. It distinguishes from sibling tools like post_bond and release_bond by indicating a state transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that funding_ref links the payment transaction, implying use after funding, but does not explicitly state when to use versus alternatives (e.g., post_bond) or mention prerequisites like 'bond must be in POSTED state'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bond_statusCInspect
Current record for a bond (state, balances, claims, audit head).
| Name | Required | Description | Default |
|---|---|---|---|
| bond_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies read-only access by stating 'current record' but does not explicitly confirm non-destructive behavior or mention authentication needs, rate limits, or side effects. The mention of 'audit head' hints at data access but remains minimal.
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 of 8 words, conveying the core functionality without fluff. It is appropriately front-loaded, though it could benefit from a slightly more explicit structure (e.g., starting with a verb).
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 low complexity (one parameter, no nested objects, output schema exists), the description covers the basic resource and fields. However, it omits usage guidance, behavioral safety, and parameter details, leaving gaps that an agent must infer. The output schema exists, so return values need not be explained, but the description could still mention the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (bond_id) with no description. The description adds only that bond_id identifies the bond, which is already clear from the parameter name. It does not specify format, source, or constraints (e.g., length, valid values). With 0% schema description coverage, more detail is needed.
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 resource (bond) and what the record includes (state, balances, claims, audit head). It implies a retrieval operation, distinguishing it from sibling tools like activate_bond or list_bonds that perform actions or list all bonds. However, a more explicit verb like 'retrieve' would improve clarity.
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?
No guidance is provided on when to use this tool versus alternatives such as list_bonds (for listing all bonds) or verify_audit (for audit-specific checks). The description lacks context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_agentCInspect
Return capabilities and input contract.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description does not disclose whether the tool is read-only, safe, or any side effects. For a tool that likely queries internal state, this is a significant gap.
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 extremely brief (4 words). While concise, it could provide more context (e.g., 'Returns the agent's current capabilities and expected input contract') without becoming wordy. Adequate but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description should hint at what that output contains. It only vaguely refers to 'capabilities and input contract' without elaboration. Incomplete given the available 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?
There are zero parameters and schema coverage is 100% trivially. The description adds no param info, but none is needed. Baseline 4 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 states the tool returns capabilities and input contract, which clearly indicates a self-description function. It distinguishes from sibling bond-related tools by being a meta-tool for introspection.
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?
No guidance is provided on when to use this tool versus alternatives. Siblings are all bond operations, so it is unique, but explicit context or prerequisites are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
file_claimAInspect
File a claim against an ACTIVE bond. Claims pay out ONLY when an arbitration ruling upholds them (see slash_bond).
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| bond_id | Yes | ||
| claimant | Yes | ||
| amount_minor | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the payout condition but does not mention whether the action is reversible, idempotent, or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and no extraneous words. Efficient communication.
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 annotations, the description is moderately complete. It covers the core action and a key condition but misses parameter details and error handling. An output schema exists, so return values are not needed, but the description could provide more context on valid inputs.
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 0%, and the description adds no parameter-level meaning. It only mentions the bond must be ACTIVE but does not explain the purpose of 'reason', 'claimant', or 'amount_minor'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('File a claim') and the specific resource ('against an ACTIVE bond'). It also distinguishes the payout condition, which differentiates it from sibling tools like slash_bond.
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 when the tool is effective (payout only after arbitration ruling) and references a sibling tool (slash_bond) for further context. However, it does not explicitly exclude alternatives or state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_bondsAInspect
List bonds, optionally filtered by state (POSTED|ACTIVE|RELEASED|EXHAUSTED).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose important behavioral traits such as read-only nature, authentication requirements, rate limits, pagination, or ordering. The description only states the basic operation, leaving significant uncertainty about side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It front-loads the core purpose and parameter options efficiently.
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 list tool with one parameter, the description covers the basic purpose and parameter enumeration. However, it lacks details on output schema (though output schema exists), pagination, ordering, or any pagination behavior. Given the low complexity, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'state' with anyOf string|null and default null, but no enum values. The description adds meaningful enumeration ('POSTED|ACTIVE|RELEASED|EXHAUSTED') and clarifies that filtering is optional. This compensates for the 0% schema description coverage.
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 'List' and the resource 'bonds', and specifies an optional filter by state with enumerated values (POSTED|ACTIVE|RELEASED|EXHAUSTED). This distinguishes it from sibling tools like bond_status (specific bond) and activate_bond (action).
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies use for listing bonds with optional state filtering, but does not mention alternatives like bond_status for individual bond details. Context from siblings suggests some differentiation, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_bondAInspect
Post a surety bond behind an agent's promises. principal is a positive integer in minor units; expires_at is the ISO-8601 coverage window end. The bond fee (2% default) is computed and frozen at post.
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | No | ||
| currency | No | USD | |
| principal | Yes | ||
| expires_at | Yes | ||
| principal_agent | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the bond fee is computed and frozen at posting, and clarifies parameter formats (minor units, ISO-8601). However, it does not mention side effects, permissions, or whether the operation is reversible.
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 very concise: two sentences, front-loaded with the main action, and no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be detailed. However, the description lacks explanation of 'coverage' and 'principal_agent', and the phrase 'behind an agent's promises' is vague. It covers the core but leaves gaps for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains 'principal' (minor units integer) and 'expires_at' (ISO-8601 end) but does not describe 'coverage', 'currency', or 'principal_agent' beyond their names. Only 2 of 5 parameters are clarified.
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 'Post' and the resource 'surety bond', and the context of 'behind an agent's promises' distinguishes it from sibling tools like 'list_bonds' or 'activate_bond'.
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 for posting a bond but does not explicitly state when to use this vs alternatives (e.g., 'price_bond' for cost estimation or 'activate_bond' for activation). No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_bondAInspect
Underwrite a surety bond: deterministic actuarial premium quote from a counterparty's track record (attestations, notarized deliveries, completed bonds lower the rate; slashes raise it or decline outright). Integer-only model uw-v1; the returned quote_hash lets any party recompute and verify the quote. Pure — never mutates bond state.
| Name | Required | Description | Default |
|---|---|---|---|
| slashes | No | ||
| attestations | No | ||
| duration_days | Yes | ||
| slashed_minor | No | ||
| coverage_minor | Yes | ||
| bonds_completed | No | ||
| successful_deliveries | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is 'Pure — never mutates bond state' and describes the deterministic integer model and quote_hash for verification, providing clear behavioral expectations beyond the schema. No annotations exist, so this is well-handled.
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-organized into four succinct sentences covering purpose, factors, computation model, and purity. It is front-loaded with the main action and avoids redundancy, earning its space.
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 complexity (7 parameters, no annotations, output schema present), the description covers purpose, behavioral traits, and key influencing factors. It does not detail all parameters or usage prerequisites, but the existence of an output schema reduces the need to explain return values, making it adequately 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?
The description adds meaning for parameters like attestations, slashes, and bonds_completed by explaining their effect on pricing. However, it omits explanations for slashed_minor, coverage_minor, and duration_days, leaving some parameter semantics unclear despite 0% schema coverage.
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 'underwrites a surety bond' and provides a 'deterministic actuarial premium quote,' which aligns with the tool name 'price_bond'. It distinguishes from siblings by noting it never mutates bond state, contrasting with post_bond or activate_bond.
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 explains the pricing model and that the quote is verifiable via quote_hash, implying its use before bond creation. However, it does not explicitly contrast with siblings or specify when not to use, though context suggests it's for preliminary pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
release_bondAInspect
Release the remaining stake to the principal after the coverage window elapses — refused while any claim is still open.
| Name | Required | Description | Default |
|---|---|---|---|
| bond_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses a key behavioral trait (refusal if claim open) but lacks details on side effects, idempotency, or what happens on success, leaving some uncertainty.
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, front-loaded sentence with no wasted words. It efficiently conveys the action and a critical condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and refusal condition, but given the presence of an output schema (not shown) and a simple parameter, it omits details like expected output, prerequisites, or error cases, which would make it more 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 coverage is 0%, but the description does not add meaning to the bond_id parameter beyond what is in the schema. It only describes the overall action, not the parameter's format or constraints.
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 releases the remaining stake to the principal after the coverage window elapses, with a specific condition (refused if any claim open). It distinguishes from sibling tools like file_claim or slash_bond by focusing on stake release.
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 after the coverage window and when no claims are open, but does not explicitly compare to alternatives (e.g., slash_bond for penalties) or specify when not to use it beyond the refusal condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slash_bondAInspect
Execute an arbitration ruling against a claim. Requires the ruling's case id + content hash from agent-arbitration — no ruling, no slash; a given ruling pays at most once. Payout caps at the bond's available balance (over-claims exhaust the bond).
| Name | Required | Description | Default |
|---|---|---|---|
| upheld | No | ||
| bond_id | Yes | ||
| claim_id | Yes | ||
| ruling_hash | Yes | ||
| ruling_case_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses key traits: requires a ruling, single-payout guarantee, over-claim exhaustion. No contradictory info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main action, no wasted words. Highly efficient.
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 prerequisites, payout guarantee, and cap. Output schema exists so return values are covered. Could mention failure modes but adequate given complexity.
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 0%; description adds meaning for ruling_case_id and ruling_hash ('ruling's case id + content hash') but not for bond_id, claim_id, or upheld. Partial compensation.
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 verb 'Execute an arbitration ruling' against a resource 'claim'. Specifics like requiring case id and content hash distinguish it from siblings like file_claim or bond_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?
Explicitly states prerequisites (ruling case id + content hash) and constraints (no ruling, no slash; pays at most once; caps at available balance). Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_auditCInspect
Validate the tamper-evident audit hash chain for a bond.
| Name | Required | Description | Default |
|---|---|---|---|
| bond_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 says 'validate', implying a read-only operation, but it does not disclose potential side effects, required permissions, behavior on failure, or other traits. This is insufficient for full transparency.
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 with no extraneous information. It is efficiently written, though it could benefit from additional context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an existing output schema, the description lacks essential context such as what the validation result looks like, error conditions, or prerequisites. For a verification tool, more detail is expected to ensure correct usage.
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 0% for the single parameter 'bond_id'. The description does not explain the parameter's meaning or format beyond the schema's type and title. It adds no semantic value.
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 validates an audit hash chain for a bond. It uses a specific verb ('validate') and identifies the resource ('tamper-evident audit hash chain'). While distinct from sibling tools like 'bond_status', it doesn't explicitly differentiate, but the unique function is clear.
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?
No guidance is provided on when to use this tool versus alternatives, or what prerequisites or constraints exist. The description merely states the action without contextual usage information.
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!
Your Connectors
Sign in to create a connector for this server.