Skip to main content
Glama
Sign In

The Wild

by dev.workers.mhoydich.the-wild-x402
OverviewDiscussionsAdmin

How to buy one act

buy_kit
Read-onlyIdempotent

The exact HTTP contract for one paid act, from the published manifest: route, price and atomic amount, body, headers, the seal recipe, the signer rule and the reconcile rule. This tool never pays: pay with your own x402 client against the route it returns, only when your human asked.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "act": "<act>"
    },
    "name": "buy_kit"
  }
}

Input Schema

NameRequiredDescriptionDefault
actYesprayer and keep and witness are $0.01; votive candles are $1 (day), $3 (week), $9 (month).
spiritNoOptional spirit id: fills the route (or, for witness, the body).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description reinforces this with 'This tool never pays', which is a meaningful behavioural boundary rather than a contradiction. It also discloses the shape of what is returned (seal recipe, signer rule, reconcile rule), which annotations cannot convey. It does not mention auth requirements, caching, or whether the manifest can change between calls.

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?

Two sentences, dense but each earns its place: the first enumerates the returned contract fields, the second states the critical non-payment rule and the human-approval gate. The field list is long but front-loads the 'exact HTTP contract' framing before detail.

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?

With no output schema, the description must describe return content, and it does so by naming each component of the contract the agent will receive. Combined with a fully documented two-parameter schema and read-only annotations, an agent has enough to call it correctly. Minor gap: the concrete serialization/format of the returned contract is not stated.

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% and both parameters are enumerated with their own descriptions, including per-act pricing in the `act` description. The prose adds no additional meaning about how `act` or `spirit` affect the output beyond what the schema already says. Baseline 3 applies when the schema carries the parameter burden.

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?

The description states a specific resource and payload: the exact HTTP contract for one paid act, enumerating route, price/atomic amount, body, headers, seal recipe, signer rule and reconcile rule. It is clearly a lookup/manifest tool rather than a payment tool, which distinguishes it from any real payment path. It does not name or contrast with the sibling tools (altar, field, spirits, verify_witness), so full sibling differentiation is missing.

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 gives a clear usage rule: never pay with this tool, use your own x402 client against the returned route, and only when your human has asked. That is a real when-to-use constraint plus a guardrail. It stops short of stating when to prefer a sibling (e.g., verify_witness or spirits) instead.

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

All The Wild toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources