Public internet HP bar. Agents smack it over MCP. They cannot complete payment.
Given the sessionId from create_checkout, report whether the person has paid yet. Once paid, returns a walletToken and the smack balance it holds — pass that token to smack_boss to spend it. Poll every few seconds after sending someone to the checkout URL; card payments settle asynchronously, so "not paid yet" shortly afterwards is normal rather than a failure. Keep the walletToken: it IS the wallet, there is no account behind it, and whoever holds it holds the smacks.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The sessionId returned by create_checkout. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses asynchronous payment settlement, explains polling expectations, and warns that the walletToken is the wallet itself with no backing account. It also clarifies the return content (walletToken and smack balance) rather than leaving the output mysterious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, successful result, polling/async guidance, and the critical token-custody warning. It is front-loaded with the core purpose and contains no filler or redundant restatement of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description covers the input source, expected return values, polling behavior, asynchronous failure mode, and downstream action. The exact shape of the 'not paid yet' response is not specified, but 'report whether' and the polling guidance make the behavior sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes sessionId as 'The sessionId returned by create_checkout' with 100% coverage. The description reinforces this relationship but does not add new format, constraint, or edge-case detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'report whether the person has paid yet' given the sessionId from create_checkout. This clearly differentiates it from create_checkout (creating the checkout) and smack_boss (spending tokens), and implies a different identifier source than get_wallet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: poll every few seconds after sending someone to the checkout URL, and treat 'not paid yet' as normal due to asynchronous card settlement. It names the downstream next step (pass token to smack_boss) but does not explicitly list exclusions such as 'use get_wallet instead once you have a walletToken.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a Stripe Checkout Session for one smack pack and return its URL. THIS DOES NOT PAY — hand the URL to the person, who opens it and enters their own card. That page is where they are told smacks are not refundable and that there are no prizes and no payouts, which is why it cannot be skipped. Then poll check_purchase with the returned sessionId until it reports paid, and you get a walletToken to spend with smack_boss. Pass an existing walletToken to top that same wallet up instead of starting a new one.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | Which pack to buy. Call list_packs for the valid ids and prices. | |
| walletToken | No | Optional. A walletToken from an earlier purchase, to add these smacks to that wallet rather than creating a second one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, and it is explicit that this step does not pay/charge, that the checkout page cannot be skipped, and that refund/payout terms are shown there. It also discloses the needed follow-up polling behavior, which is exactly the kind of side-effect context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: first sentence states the action, then warnings, then the polling contract, then the optional-parameter behavior. It is front-loaded with the core purpose and does not pad.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full purchase flow, side effects, and the follow-up contract, which is substantial for a tool with no output schema. It is slightly ambiguous that it says 'return its URL' but later refers to 'the returned sessionId', so the exact response shape is not pinned down.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real meaning for walletToken by explaining it tops up an existing wallet rather than creating a second one, and it reinforces pack selection via list_packs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: it creates a Stripe Checkout Session for one smack pack and returns a URL. It also names the follow-up tool (check_purchase) and the downstream walletToken use, which separates 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete workflow: hand the URL to the person, poll check_purchase, then use the walletToken with smack_boss. It also explains when to pass an existing walletToken (top up vs. new wallet). It does not state explicit 'don't use this when' exclusions, but the workflow is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the world boss everyone is currently hitting: its name, lore, tier, current and maximum hit points, active affixes, the live momentum multiplier, and how much damage has been dealt. Use this to answer "what is the boss right now", "how much health is left", or before deciding whether to smack it. One boss exists at a time and everyone in the world shares it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it explains the live/shared nature of the resource: one boss at a time, visible to everyone, with current HP, active affixes, and a live momentum multiplier. It does not explicitly state that the operation is read-only/non-mutating, but for a zero-parameter getter the behavior is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first lists the complete payload, the second gives user-facing use cases, and the third clarifies global state. No filler or redundant clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument tool with no output schema, the description covers what the agent gets (fields), when to call it, and its singleton/shared semantics. An agent can confidently invoke it without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema already covers everything (100% coverage); baseline 4 applies. No additional parameter explanation is needed or possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return'), a specific resource (the world boss), and enumerates all returned fields, making it distinguishable from siblings like get_leaderboard and smack_boss. The title is vague, but the description compensates fully.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives three concrete use cases — current boss identity, remaining health, and pre-attack decision — and the shared-world context adds scope. It does not name alternative tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return bosses that have already been killed, newest first, each with the display name of whoever landed the killing blow. That engraving is permanent and is the only thing anyone actually wins. Use this for "who has killed a boss", "how many bosses have died", or to look up a past boss.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many graves to return. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden. It discloses sort order, result contents, and the permanence of the killing-blow record, which implies an immutable historical read. It does not mention auth, rate limits, or empty-result behavior, but those are minor for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core behavior is front-loaded in the first sentence, the second adds useful permanence context, and the third provides clear use cases. All sentences earn their place, with only the rhetorical phrase about the only thing anyone wins giving it slight extra flavor rather than purely operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter read tool with no output schema, the description adequately conveys the return shape, ordering, and intended use cases. It could have explicitly noted how limit applies or what an empty graveyard looks like, but those are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, limit, is fully documented in the schema with a range and default value, so schema coverage is 100%. The description itself does not add extra parameter semantics, but none is necessary beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns bosses already killed, newest first, each with the display name of the killer. It is semantically distinct from siblings like get_boss and get_leaderboard, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases: who killed a boss, how many bosses have died, and looking up a past boss. It does not provide exclusions or name alternative tools for different scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the damage leaderboard for the current boss — display names and total damage, highest first — together with the most recent hits. Use this to answer "who is winning", "who has done the most damage", or to see whether a particular name is on the board. Resets when the boss dies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many entries to return. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful facts: results are sorted highest first, recent hits are included, and the leaderboard resets when the boss dies. It does not explicitly state that the call is read-only or free of side effects, but 'Return' strongly implies a pure query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences that front-load the core behavior, then supply use cases and the reset caveat. No sentence is redundant, and the structure helps an agent scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations or output schema, the description is nearly complete: it covers purpose, response shape, ordering, intended queries, and lifecycle. The one gap is the structure of the 'most recent hits' portion and how `limit` applies to it, which would be clearer with an output schema or one more sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single `limit` parameter is fully documented in the schema (100% coverage), including its default of 10. The description adds no extra meaning about `limit`, so it stays at the high-schema-coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and resource: 'Return the damage leaderboard for the current boss', and spells out the output ('display names and total damage, highest first'). This makes it easy to distinguish from siblings like get_boss or smack_boss, which are about boss state and attacks rather than rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly lists when to use the tool: to answer 'who is winning', 'who has done the most damage', or to check if a name is on the board. It does not mention sibling alternatives or say when not to use it, so it meets the clear-context bar but not the full exclusion/alternative bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current state of The Pixel (thepixel.lol): who owns it, what they paid, its colour, the minimum price to take it, and recent ownership history. Use this for "who owns the pixel" or "what would it cost to buy it". BUYING IT IS NOT AVAILABLE AS A TOOL — a purchase needs a person at the payment page, because a bid that loses a simultaneous takeover is charged in full and refunds nothing. Send the human to https://thepixel.lol to buy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple read operation by explaining that purchase is intentionally not available, why (simultaneous takeover bids are charged in full and refund nothing), and what to do instead. This is strong, honest behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and data contents, then moves to usage guidance and a critical warning. Every sentence earns its place, and the formatting makes the 'not a purchase tool' warning impossible to miss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain what the agent will receive, and it does: owner, price paid, colour, minimum price, and ownership history. It also covers business-critical context about buying and directs the user to the correct action. For a zero-parameter read tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. The description adds no parameter-level details because none exist, but it does clarify what the returned concept 'minimum price to take it' means in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return the current state') and resource ('The Pixel'), and enumerates exactly what data is included (owner, payment, colour, minimum price, history). It also gives explicit example queries ('who owns the pixel', 'what would it cost to buy it'), which differentiates it from sibling tools like get_leaderboard or get_wallet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('Use this for...') and when not to attempt a purchase, since buying is not available as a tool and requires sending a human to the payment page. This is clear, actionable routing with an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the smack balance held by a walletToken. Use it to decide whether to keep smacking or to buy another pack.
| Name | Required | Description | Default |
|---|---|---|---|
| walletToken | Yes | A walletToken from check_purchase. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only operation by saying 'Return the smack balance,' but it does not explicitly mention side effects, authorization needs, or error behavior. This is adequate for a simple getter but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded in the first sentence, and the usage guidance in the second sentence earns its place by explaining decision relevance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is nearly complete. It states what is returned and why an agent would call it. Since there is no output schema, it does not explicitly describe the return format, but 'smack balance' and the title 'How many smacks are left' provide enough inference for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents walletToken as 'A walletToken from check_purchase.' The description repeats the parameter name but adds little beyond the schema; its main contribution is clarifying that the balance is 'held by' the token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a specific resource ('smack balance held by a walletToken'). This clearly distinguishes it from sibling tools like get_boss, get_graveyard, and smack_boss, which operate on different game resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: 'Use it to decide whether to keep smacking or to buy another pack.' It does not explicitly mention alternatives or exclusions, but it provides enough context for an agent to know this is a balance-checking decision aid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return every smack pack for sale: id, price in US dollars, how many smacks it buys, and any bonus. Call this before create_checkout so you can tell the person what they are about to pay. Prices are final — no VAT or tax is added at checkout. Also reports the free allowance, so you can mention that trying it costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does meaningful work: it reveals that prices are final, no VAT/tax is added at checkout, and the tool also reports a free allowance. These are non-obvious behavioral details beyond a bare 'list packs' statement, even if it doesn't explicitly declare read-only status or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: the first defines what is returned, the second gives the call-before-create_checkout workflow, and the third adds essential pricing and free-trial context. Each sentence earns its place and the primary action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema read-only listing tool, the description provides everything an agent needs to invoke and use it correctly: return fields, call timing relative to create_checkout, pricing finality, and the free allowance. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the agent to misunderstand. Per baseline for zero-parameter tools, the description needs no parameter-level detail, and the fields it lists instead describe the return content usefully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return every smack pack for sale,' then enumerates the exact fields returned (id, price in USD, smack count, bonus). It also plants a clear differentiation hook by naming create_checkout as the downstream tool, so an agent can distinguish this from purchase and account tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this before create_checkout and explains the purpose: to inform the person what they are about to pay. This gives clear, concrete usage context, though it does not spell out when-not-to-use it or name alternative list-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Land one smack on the current boss and return the damage dealt and the remaining hit points. One swing per call — call it repeatedly to keep hitting.
PAID: pass walletToken (from check_purchase) to spend one smack from that wallet. Paid hits are the real thing — they can crit, they take the momentum multiplier, and only a paid hit can land the killing blow and put a name on the grave forever.
FREE: pass visitorId instead and it costs nothing. Three per visitorId — the count is held for about thirty days — then FREE_EXHAUSTED, which is the limit working and not a fault. It is NOT an hourly allowance: waiting does not give them back. A free smack can never land the killing blow and free damage is capped per boss, so the engraving stays with somebody who paid for it.
Pass one or the other. If both arrive, the wallet is spent.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional display name for the public hit feed, the leaderboard, and — on a killing blow — the grave. Visible to everyone, and permanent once engraved. | |
| visitorId | No | For a free smack. A stable identifier you generate once and reuse so the free allowance is tracked. Any opaque string; a UUID is ideal. Nothing personal in it. | |
| walletToken | No | A walletToken from check_purchase. Spends one paid smack. Takes precedence over visitorId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses crits, momentum multiplier, paid-only killing blows, free-hit limits, the ~30-day window, FREE_EXHAUSTED semantics, per-boss free damage cap, and the wallet-spending tie-breaker. This is exceptionally transparent about side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence contributes: the core action is front-loaded, followed by clearly labeled PAID and FREE sections. The formatting makes the two modes scannable, and no sentence is redundant or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential call semantics, return values, error condition (FREE_EXHAUSTED), parameter relationships, and edge cases like both parameters being supplied. A caller has enough information to invoke it correctly in either free or paid mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema description coverage is 100%, the tool description adds meaning beyond the schema: walletToken is tied to check_purchase and takes precedence, visitorId is a stable reusable identifier tracked for free allowance, and name is public and permanent when engraved. This substantially enriches the raw parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb ('Land one smack'), the resource ('current boss'), and the return values ('damage dealt' and 'remaining hit points'). It also clarifies that each call is exactly one swing, distinguishing it from any batch or multi-hit behavior and from read-only sibling tools like get_boss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly separates paid vs. free usage, explains the implications of each mode, and defines the precedence rule when both parameters are passed. It does not explicitly contrast this tool against sibling alternatives like get_boss or check_purchase, but it does tell the caller how to obtain and spend walletToken.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Universal agent commerce gateway with 18 MCP tools, A2A, x402, UCP, revenue and provider health.
A paid remote MCP for agent memory MCP, built to return verdicts, receipts, usage logs, and audit-re
Self-facilitated x402/MCP payments for hosted endpoints, rail proofs, receipts, and agents.
Add one secure layer between your agents and this server.
Each tool addresses a distinct resource or action: checkout flow tools, boss state tools, leaderboard/graveyard views, wallet balance, and the pixel. No two tools could plausibly be confused, and smack_boss's paid/free modes are clearly documented within a single tool.
All tool names are snake_case and follow a clear verb_noun pattern: get_* for state queries, create_checkout/check_purchase for the payment flow, list_packs for catalog, and smack_boss for the action. The naming is uniform and predictable.
Nine tools cover the full surface of this server: commerce (list/create/check/wallet), combat (smack/get boss), and meta views (leaderboard/graveyard/pixel). Nothing feels redundant, and the count is appropriate for a focused game/payment server.
The domain is fully covered: users can discover packs, pay, verify payment, spend smacks, observe boss state, and view historical results. The intentional omission of a pixel purchase tool is documented as a design decision, and all core workflows have no dead ends.