Skip to main content
Glama

Release bond

release_bond
Destructive

Release the remaining stake to the principal after the coverage window elapses — refused while any claim is still open.

Input Schema

NameRequiredDescriptionDefault
bond_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that: the precondition that open claims block the release, and what actually moves (remaining stake to the principal) rather than relying on the vague name 'release'.

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?

One sentence, front-loaded with the verb and resource, with the failure condition appended after the core action. No redundant restatement of the title or annotations.

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?

An output schema exists, so return values needn't be explained, and the safety profile is carried by annotations. The description covers the action plus the blocking condition; only finer details (irreversibility of the transfer, any authorization requirements) are absent, which is acceptable for a one-parameter mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter bond_id is undocumented in both schema and description. 'bond_id' is fairly self-descriptive, but the description adds no meaning about format, source, or lookup — nothing an agent couldn't infer from the name alone.

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?

States a specific verb and resource ('Release the remaining stake to the principal') with a precise triggering condition ('after the coverage window elapses'), which cleanly separates it from siblings like slash_bond, post_bond, and activate_bond.

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?

Gives an explicit when-not condition ('refused while any claim is still open') and a timing prerequisite, so the agent knows when the call will fail. It doesn't route to an alternative sibling (e.g., file_claim or bond_status) when the condition isn't met, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.