Skip to main content
Glama

swop

by io.github.Travisswop

Get a swop.id storefront

swop_get_store
Read-only

List the real products a swop.id sells on their SmartSite, with USDC prices and each product's x402 buyUrl. An agent with an x402-capable wallet purchases by GETting the buyUrl: the first request returns HTTP 402 with payment instructions (exact USDC amount, network, pay-to address), and retrying with a signed X-PAYMENT header completes the purchase and returns a receipt. Always show the user the product, price, and seller and get their confirmation before paying.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handleYesThe seller swop.id, e.g. "travis.swop.id"

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already indicate a read-only, non-destructive operation, and the description adds valuable behavioral detail beyond that: returned buyUrls require a two-step HTTP 402 payment flow with a signed X-PAYMENT header, and user confirmation must precede payment. No contradiction exists with the readOnlyHint because the mutation happens via external GET requests, not through this tool.

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 front-loaded with the core purpose, then provides the necessary purchase protocol and safety instruction. Every sentence adds essential information, and there is no fluff or repetition of schema fields.

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?

Despite having no output schema, the description covers the returned data (products, USDC prices, x402 buyUrls), the non-obvious payment behavior, and the required user confirmation. For a single-parameter lookup tool, this is complete enough for an agent to call it and act on the result safely.

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?

There is only one parameter and schema description coverage is 100%; the schema already provides the meaning and example for 'handle'. The tool description does not add meaningful parameter semantics beyond what the input schema contains.

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 a precise verb and resource: 'List the real products a swop.id sells on their SmartSite.' It further distinguishes itself from payment-focused siblings by stating that the tool returns prices and x402 buyUrls, not payment execution itself.

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 makes the usage context clear: an agent should use this tool to retrieve a storefront's products and buyUrls, then follow the x402 flow to purchase. It does not explicitly name alternative tools to avoid, but it gives enough workflow context to guide correct use.

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

All swop toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Every tool targets a distinct resource and action: search_markets is for discovery while get_event_markets is for a single event's full detail, and lookup_identity/search_identities, get_prices/get_price_history, and send/pay_x402_link are all clearly separated. There is no realistic pair of tools an agent would struggle to choose between.

Naming Consistency5/5

All tools follow a consistent snake_case, swop_-prefixed, verb-first pattern such as get_*, search_*, create_*, update_*, send, and pay_*. Even slightly longer names like check_predictions_access stay within the same predictable structure.

Tool Count4/5

21 tools is on the higher side, but the server covers several distinct clusters: prediction-market data, account/wallet info, identity resolution, SmartSite commerce, and payments. Each tool has a clear role, so the count is slightly over the ideal range but still reasonable for the apparent scope.

Completeness3/5

The market data and payment send flows are fairly complete, but lifecycle operations are missing: products can be created and listed but not updated or deleted, swaps are quote-only, and there is no prediction-market order execution tool. These are notable gaps, though they do not block the core send/pay and market-data workflows.

Resources