Skip to main content
Glama

Snapback

by io.github.ra1labsworkx-wq
OverviewDiscussionsAdmin

recommend_failover

Read-onlyIdempotent

Should you RETRY the same target, SWITCH provider, FALL BACK to another chain, or STOP? Pass the error + your configured topology (current_chain, available_chains, and/or current_provider, available_providers) and get deterministic routing advice with the reason — so a flaky Solana RPC doesn't get retried 5x when you should switch to Base. Free, no token, no LLM. Reads only what you tell it (no network calls).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorYesthe error you hit
current_chainNothe chain you're on (e.g. 'solana')
available_chainsNofallback chains you can use (e.g. ['base','arbitrum'])
current_providerNothe RPC/provider you're using (e.g. 'helius')
available_providersNobackup providers on the same chain

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "A JSON object (returned as text in result.content[0].text). Diagnosis tools return {matched, family, fix, confidence, source, action_class, auto_safe, gate}; other tools return their own JSON result.",
+  "type": "object"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnly/idempotent/destructive=false), it discloses that the tool is free, requires no token, uses no LLM, makes no network calls, and reads only caller-supplied data — exactly the operational context an agent needs before wiring it into a retry loop. Note the mild tension with openWorldHint=true, but it is not a contradiction of any hint.

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?

Front-loaded with the decision question, then the inputs, then the payoff, then the operational caveats — four tight sentences with no filler. The one long sentence carries the cost-saving rationale and is worth its length.

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?

An output schema exists so return values need no explanation, and the description still characterizes the return as 'deterministic routing advice with the reason'. For a read-only, one-required-param advisory tool, nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description adds real semantic value by grouping the five params into two orthogonal topologies (current_chain/available_chains vs. current_provider/available_providers) and signaling they are combinable via 'and/or'. It does not, however, explain how the tool behaves when only one side of the topology is supplied.

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 opens with the exact decision it resolves (retry / switch / fall back / stop) and names the resource: deterministic failover routing advice from an error plus a topology. It is clearly distinguishable from sibling diagnose_* tools by being a deterministic, no-LLM router rather than a diagnostic.

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?

It states the triggering context (you hit an error and are deciding whether to retry or switch) and the inputs to supply, with a concrete motivating example (flaky Solana RPC retried 5x instead of switching to Base). It doesn't name alternative siblings or say when NOT to use this, so it stops 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.

All Snapback toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources