Snap Router
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SNAP_API | Yes | The hosted Snap Router API URL, e.g. https://trigeochiral.com | |
| SNAP_XPAYMENT | No | Optional base64 x402 X-PAYMENT payload, to make paid calls past the free tier. Without it you get 25 free calls/day per IP. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| snap_routerA | Tool/service DISCOVERY, not execution. Input: an agent task in plain words. Output: a ranked shortlist of x402 services and MCP tools from the merged x402 Bazaar + MCP Registry catalog (16k+ entries) that can do it, each with price and a 'works well with' hint. One vector pass, ~200ms, no LLM call, hybrid keyword-fill so nothing is missed. Call this FIRST, before loading candidate tools into context, whenever you do not already know which tool serves a task. Example task: 'check a Base token for a honeypot before trading'. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool, there is no possibility of misselection or overlap; its stated purpose (catalog discovery before loading tools) is unambiguous. An agent cannot confuse it with anything else in this server.
The single tool follows a clean snake_case verb/resource-style name (snap_router) that matches the server name. There is no second convention to conflict with.
A one-tool surface is inherently thin, even though a discovery router is arguably a single-purpose operation. The rubric treats 1-2 tools as borderline, and this sits right at that edge.
For a pure discovery role, the tool covers the core 'find candidates' operation, but the surface is a dead end: no way to fetch full details for a given service/tool ID, filter by price/category, or paginate the 16k-entry catalog. Agents can work around this by rerunning searches, but it is a notable gap.