tollboothswap-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a distinct stage of the swap workflow: metadata, token resolution, safety check, pricing, transaction building, and receipt verification. The only near-overlap (get_quote vs build_swap) is clearly separated by free indicative vs paid transaction-building.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern, with get_ prefixed for fetch operations and build_, resolve_, check_ for actions. This makes the tool set predictable and easy to navigate.
Tool Count5/5
Six tools is well-scoped for a token swap service, covering every essential step from token discovery to receipt verification without excess. Each tool has a clear purpose and no redundant entries.
Completeness5/5
The tool surface fully covers the swap lifecycle: resolve_token → check_token → get_quote → build_swap → get_receipt, with get_service_info providing necessary context. There are no obvious missing operations for the stated purpose.
Average 4.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the specific metadata fields, which is useful, but it does not disclose any behavioral details like potential network calls, response size limits, or failure modes beyond what annotations imply.
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?
The description is a single, front-loaded sentence that wastes no words. It names the verb and resource first, then lists the specific metadata categories. Perfectly concise.
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?
With no parameters, a rich output schema, and informative annotations, the description is complete for this simple metadata retrieval tool. It clearly states what the tool returns and does not need to explain return values because the output schema exists.
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?
The tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter information because none exist, which is appropriate. The listed items in the description actually describe return values, but the schema and output schema cover those.
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 clearly states the tool retrieves Tollbooth service metadata and lists specific items (supported chains, swap fee, x402 toll pricing). This distinguishes it from sibling tools that deal with swaps, tokens, quotes, and receipts.
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 description implies usage when service metadata is needed, but does not explicitly say when to use this tool versus alternatives or provide exclusions. Sibling tools are listed but not referenced, leaving the agent to infer distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it costs an x402 toll (auto-paid via TOLLBOOTH_PAYER_KEY) and returns a signed receipt. Annotations already flag the tool as non-read-only and non-idempotent, so the description enriches rather than contradicts. It does not fully explore side effects or edge cases, but it covers the most important cost behavior.
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?
The description is three sentences, each earning its place: purpose, cost, and return values. It is front-loaded with the core action and avoids fluff or repetition of schema fields.
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?
For a moderately complex tool with 7 parameters and an output schema, the description covers the essential context: what it builds, for whom, the associated cost, and what is returned. It does not fully explain edge cases like when TOLLBOOTH_PAYER_KEY is absent, but the output schema and rich parameter descriptions fill most gaps. Slightly more detail on the toll behavior would make it a 5.
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?
The input schema has 100% coverage with detailed descriptions for every parameter (chain, taker, amount, safeMode, etc.). The tool description does not add any parameter-specific meaning beyond what the schema already provides, so it meets the baseline for high schema coverage without adding extra value.
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 uses a specific verb ('build') and resource ('unsigned swap transaction for the taker wallet'), clearly distinguishing it from sibling tools like get_quote (which only fetches a quote) and get_receipt. It also specifies the purpose (to sign and submit) and the output (transaction, quote, receipt).
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?
The description clearly implies when to use this tool: when you need an unsigned swap transaction for a taker wallet to sign. It does not explicitly mention alternatives or when not to use it, but the context and sibling list make the differentiation clear. This is close to a 5 but lacks a direct exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds that the receipt is signed and that the tool verifies its signature, which is a behavioral trait beyond simple retrieval. No contradiction with annotations.
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?
The description is one concise sentence, starting with the action and directly conveying purpose. Every word earns its place, with no redundancy or filler.
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?
For a one-parameter fetch tool with an output schema, the description is nearly complete: it states the purpose, explains the source of the id, and mentions signature verification. Minor gaps like error-handling behavior are not critical given the simple scope.
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?
The input schema fully describes the single parameter 'id' as the receipt id returned by build_swap. The description only says 'by id', adding no semantic detail beyond the schema, so the baseline of 3 is appropriate.
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 clearly states the action ('Fetch') and the resource ('signed Tollbooth receipt'), and adds 'verify its signature' to specify additional behavior. It is distinct from sibling tools like build_swap or get_quote, which involve construction or pricing.
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?
The description provides clear context by noting the id is returned by build_swap, implying this tool is used after a swap is built. It does not explicitly list alternatives or exclusions, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds the key behavioral fact that the tool 'costs an x402 toll' and specifies return values (verdict, risk score, findings). This goes beyond annotations, which already mark it as idempotent and non-destructive. No contradiction with readOnlyHint=false is present.
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?
Two focused sentences: first states purpose and checks, second states outputs and cost. Every sentence earns its place with no redundant phrasing.
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?
Given the output schema exists and annotations are present, the description sufficiently covers purpose, key behaviors, returns, and cost. The tool is moderately complex but the description is complete enough for selection and invocation.
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?
Input schema provides 100% coverage with descriptions for both chain and token, including enum values and address format. The description does not add new parameter semantics, so baseline 3 is appropriate.
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?
Description states a specific verb-resource pair: 'Token safety screen before trading,' and enumerates concrete checks (honeypot, rug-pull, freeze/mint authority, transfer hooks, sell tax, blacklists). This clearly distinguishes it from sibling tools like build_swap or get_quote.
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?
The phrase 'before trading' gives clear context and implies it should be used as a pre-trade safety step. It does not explicitly name alternatives or state when not to use it, but the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already convey safety and side-effect behavior. The description adds 'free indicative quote' and 'output amount includes Tollbooth's fee', which are meaningful behavioral details beyond the annotations. No contradiction.
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?
Two concise sentences, front-loaded with the primary action and key context (free, indicative, fee included). Every part is useful, with no filler.
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?
Given the output schema exists and annotations cover safety, the description provides sufficient context for a quote tool: usage timing, fee inclusion, and decision support. It doesn't mention potential prerequisites like token resolution, but that is indirectly covered by schema and sibling tools.
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?
The input schema provides descriptions for all 5 parameters (100% coverage), including chain enum, amount format, and slippage default. The description does not add parameter-specific guidance, so the baseline score of 3 is appropriate.
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 clearly states the tool gets a free indicative swap quote and explicitly distinguishes it from build_swap (execution). It also adds the specific detail that output includes Tollbooth's fee, making the purpose precise and unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to 'Use before build_swap to decide whether to trade', providing clear when-to-use guidance and implicitly naming the alternative. This is helpful for tool selection and sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description explains that curated majors return one verified match, while other symbols return live DEX matches ranked by liquidity, which informs the agent about result variability and how to handle imitations. This adds behavioral context not captured in annotations.
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?
The description is two sentences, front-loaded with the core purpose and examples, and each sentence provides distinct value. No redundancy.
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?
The tool is simple with two well-documented parameters, an output schema exists, and annotations cover safety and idempotence. The description explains the nuanced return behavior (verified vs. ranked matches) and its place in the swap workflow, making it complete.
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?
The schema already provides full descriptions for both parameters, including the chain enum and symbol examples. The description reinforces the symbol examples but does not add meaningful new parameter semantics, so the baseline of 3 applies.
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 clearly states a specific action (resolve a token ticker symbol to contract addresses) with concrete examples (PEPE, WIF, USDC) and explicitly positions the tool in the workflow ('Use before get_quote when you only know the symbol'), which distinguishes it from the sibling tools.
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?
The description gives explicit usage guidance: 'Use before get_quote when you only know the symbol.' It also details the two modes (curated majors vs. live DEX matches), helping the agent decide when the tool is appropriate. However, it does not explicitly state when not to use it, such as when the address is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tollboothswap-mcp MCP server](https://glama.ai/mcp/servers/soundsparkaudiolab/tollboothswap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/soundsparkaudiolab/tollboothswap-mcp)

Score Badge

Copy to your README.md:

[![tollboothswap-mcp MCP server](https://glama.ai/mcp/servers/soundsparkaudiolab/tollboothswap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/soundsparkaudiolab/tollboothswap-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/soundsparkaudiolab/tollboothswap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server