rubic_get_bridge_status

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

No annotations are provided, so the description carries the full burden. 'Check the status' implies a read-only operation, but it does not disclose what the output contains, what statuses exist, or error behavior for invalid hashes. This adds minimal value beyond the name.

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 zero waste. It earns its place, but its brevity may contribute to under-specification in other dimensions. It is concise, though slightly too terse to be considered fully helpful.

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?

Without an output schema, the description must explain return values or behavioral nuances. It does not mention what 'status' looks like, whether it returns a pending/success/failed state, or any chain-specific details. For a simple tool, this is still inadequate context for an agent to interpret results or handle errors.

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

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

Schema coverage is 100%: srcTxHash is described as 'Source transaction hash to check status.' The description does not add extra meaning beyond the schema, but the baseline of 3 applies because the schema already defines the parameter clearly. No additional syntax or format details are provided.

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 uses a specific verb 'Check' plus resource 'status of a cross-chain bridge transaction,' clearly distinguishing from siblings like rubic_get_bridge_quote and get_bridge_quote. The name reinforces the Rubic context, making the tool's role unambiguous.

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?

There is no explicit guidance on when to use this tool versus alternatives like execute_bridge or get_bridge_quote. The description implies usage for checking a transaction status, but provides no context about prerequisites (e.g., needing a srcTxHash from a prior bridge transaction) or exclusions.

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