Skip to main content
Glama
GnoPulse MCP

GnoPulse MCP

Official
by gnopulse

Swap route

gno_dex_route

Finds a route between two tokens using bounded direct and two-hop discovery, and reports the search scope so agents can assess coverage.

Instructions

Best route between two tokens from bounded direct and two-hop discovery; discloses its search scope.

Input Schema

NameRequiredDescriptionDefault
inYesinput token path
outYesoutput token path
amountYesraw integer amount in the token's smallest unit

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.5

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait — the search is bounded to direct and two-hop paths, so a null result does not prove no route exists — which is genuinely useful. However, it says nothing about whether this is a read-only simulation, what permissions or rate limits apply, or whether the route is executable, leaving significant gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted clauses. The trailing 'discloses its search scope' is mild self-referential meta-commentary that a reader could do without, but it costs almost nothing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Three required params and no output schema, so the agent has no structured view of what a 'route' returns — path, hops, expected output amount, price impact — and the description does not fill that gap. It is adequate to trigger the call but not to interpret the result.

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 all three parameters (in, out, amount) are already documented including the raw-integer amount constraint. The description adds only the loose mapping of 'two tokens' to in/out, which is already obvious; baseline 3 applies.

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?

States a specific verb+resource ('best route between two tokens') and narrows it with 'bounded direct and two-hop discovery', so an agent knows this is a route-finding tool rather than a raw quote or hop listing. It does not explicitly distinguish itself from close siblings like gno_dex_quote or gno_swap_hops, which keeps it short of a 5.

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 phrase 'bounded direct and two-hop discovery' implies a usage constraint (routes longer than two hops are out of scope) but never states when to prefer this over gno_dex_quote or gno_swap_hops. Usage is inferable rather than instructed, which is the definition of a 3.

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