MemeSwap MCP

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

Adds real value beyond the annotations: the output is unsigned material requiring external signing, trades on fee-enabled swaps carry a 0.85% fee, and the tool stops short of authorize/sign/submit/confirm. The annotations already convey non-read-only, non-idempotent, open-world behavior, so the fee and unsigned-output disclosure are the meaningful increments.

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?

Dense, front-loaded, and the exclusion ('Not a launch/create-token tool') and boundary ('does NOT authorize...') are placed where they matter. Terse fragments are efficient, though 'NFA' is ambiguous jargon for an agent.

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 7-parameter, no-output-schema build tool with 43% schema coverage, the description should say more about what the returned 'unsigned swap material' looks like and confirm the quote-then-build ordering. It covers safety and fees well but leaves parameter and output expectations under-specified.

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 only 43%, yet the description adds almost no parameter meaning beyond restating side (buy/sell). It never explains chain, amount units, or slippageBps, and only implicitly ties the quote parameter to a prior quote call. Modest help over a thin schema.

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 ('Builds unsigned swap material') plus scope ('buy (or sell) a listed meme coin') and the backing endpoint. It explicitly rules out the closest confusable sibling job by saying 'Not a launch/create-token tool', so an agent can separate it from create/credential and token 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?

Gives clear usage context: this produces material a wallet must review and sign, and it does NOT authorize, sign, submit or confirm. That defines the handoff boundary, though it never explicitly says to call memeswap_quote first (only the schema's quote description implies the ordering) and states no exclusion relative to memeswap_xquote.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the data comes from GET /api/chains and includes keys, explorers, and aggregators, giving useful context beyond the annotations, though it omits auth and rate-limit details.

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 a single front-loaded sentence with no filler. The slash-separated purpose and parenthetical return categories are slightly terse, but every element contributes to understanding the tool.

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, zero-parameter, read-only list tool with no output schema, the description gives enough context: source endpoint and returned categories (keys, explorers, aggregators). It does not explain pagination or exact response shape, but the annotations and simplicity keep this from being a major gap.

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 schema has zero parameters, so the baseline of 4 applies. There are no parameter semantics for the description to clarify or compensate for.

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 names a specific resource (networks), a purpose (meme research / buy routing), and the underlying endpoint GET /api/chains. It distinguishes itself from action-oriented siblings like memeswap_quote or memeswap_portfolio, though it does not explicitly say 'list all supported networks'.

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 phrase 'for meme research / buy routing' implies when the tool is useful, but it does not state prerequisites, exclusions, or an explicit alternative tool to use instead. Usage is left to inference from the purpose statement.

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

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

Annotations already establish this is a non-read-only, non-idempotent, non-destructive, open-world write. The description adds meaningful behavior beyond that: the auth constraint (wallet-session only), the likely API_GAP failure mode for agents, and the critical 'show once, never log' secret handling rule.

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?

Dense and front-loaded: the action and endpoint come first, then the operational caveats. The final fragment ('show once, never log') is terse but earns its place as a security-critical instruction; nothing is padded.

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-output-schema mutation tool, the description covers auth context and secret handling, which is the most important gap. However, with 0% param coverage and zero required params, it leaves the caller without guidance on scopes/ttl defaults, so it is only minimally 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?

Schema description coverage is 0% and the description documents none of the three parameters (label, scopes, ttlDays). The word 'scoped' faintly gestures at the scopes array, but no syntax, limits, or meaning is conveyed, so an agent must infer everything from the bare schema.

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+resource ('Create scoped user API token') and includes the endpoint, so an agent understands it mints credentials rather than listing or revoking them (cf. siblings memeswap_list_credentials / memeswap_revoke_credential). It does not explicitly name those siblings, so it stops short of a 5.

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 offers context on how the endpoint is normally reached ('wallet-session only on portal; agents get API_GAP or one-time secret once'), which implies when it will succeed or fail, but gives no explicit when-to-use-vs-alternative routing or prerequisites for the caller.

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

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

The annotations already cover read-only, idempotent, open-world, non-destructive behavior. The description adds meaningful context beyond those: it is a public GET endpoint, returns display name, avatar URL choices, and scores, and explicitly carries no secrets.

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?

A single sentence front-loads the resource, endpoint, returned fields, and safety note. It is appropriately sized with no filler and no repetition of the tool name.

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 read-only tool with rich annotations and no output schema, the description is nearly complete: it explains the public nature, the GET method, the returned data categories, and the no-secrets constraint. It lacks only explicit guidance about when to prefer this over sibling profile tools.

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% and the only parameter's schema description already states 'Public EVM or Solana address. Never a key or seed.' The tool description reinforces the wallet context but does not add format or syntax details beyond the schema.

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 resource and operation through 'Public game/profile card for a wallet (GET /api/game/me)' and names the returned fields. It is clearly a read, which distinguishes it from sibling write tools like set_profile and set_avatar, though it does not explicitly name an alternative.

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?

There is no explicit when-to-use guidance or routing to related tools. The phrase 'Public game/profile card' and 'No secrets' imply that it is for public profile data only, but no conditions or alternatives are stated.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so safety is covered. The description adds genuinely new behavioral context: the source endpoint, the fact that it validates fee-route configuration at 0.85%, and a scope limit (not per-token data). It does not describe response shape, but the added context is substantive.

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 tight fragments, with the core purpose front-loaded and no filler; every clause carries information (endpoint, what is verified, fee rate, scope exclusion).

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-parameter, no-output-schema health probe, the description tells the agent what a successful call means and what the tool is not for. Return-field specifics are absent, but the tool's simplicity makes this near-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 takes zero parameters and the schema has additionalProperties=false with 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 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 resource and effect: a health/readiness check backed by GET /api/health that confirms the origin is up and fee routes are configured. The trailing 'Not per-token data' explicitly separates it from the token-oriented siblings (memeswap_token, memeswap_tokens). The phrase 'Readiness for meme research / buy routing' is slightly jargon-y but still legible.

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?

Usage is implied (call it to verify the service is up and fee routing is configured before researching or buying), and the 'Not per-token data' clause excludes one sibling. No explicit when-to-use condition or named alternative is given, so guidance remains inferential.

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

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive), and the description adds two things they don't cover: a hard security guarantee ('Never returns secrets') and the auth precondition ('Requires live user API'). It doesn't mention pagination or result shape, keeping it short of a 5.

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 short clauses, front-loaded with what is returned, then the security guarantee, then the auth requirement. Every clause earns its place with no 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?

With no parameters and no output schema, the description covers the essentials: what is listed, that it is safe to read, that secrets are excluded, and that a live user API is needed. Pagination/result volume is the only notable omission.

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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate.

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 precise verb (List) plus resource (scoped API credential metadata) and even names the underlying endpoint, so it is unmistakably distinct from siblings like memeswap_create_credential and memeswap_revoke_credential.

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 prerequisite 'Requires live user API' is a useful condition, but there is no explicit when-to-use versus alternatives such as memeswap_list_wallet_refs or guidance on when a credential list is the right call. Usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds meaningful context beyond annotations: it names the read endpoint, the required auth scope ('scoped token'), and the returned content shape ('[{wallet, override}] + active letter'). It does not cover pagination or error behavior, but for a read-only list the added auth and return details are useful.

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 a single compact sentence that front-loads the action and return shape, then adds endpoint and auth requirements. Every clause carries useful information with no 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 zero-parameter, read-only list tool with rich annotations, the description covers the essential context: what is listed, the endpoint, auth prerequisites, and the return shape. It could be more complete by clarifying 'active letter' or listing behavior on token failure, but nothing critical for invocation 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 takes zero parameters, and the schema has no properties to document. The description does not need to explain parameter syntax, so the 0-parameter baseline of 4 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: 'List wallet refs' plus 'active letter', and includes the HTTP method/path (GET /api/v1.1/me/refs). It distinguishes itself from write-oriented siblings like memeswap_set_wallet_refs or memeswap_select_wallet_ref by naming the read/list operation, though it does not explicitly 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?

Prerequisites are stated ('Requires live user API + scoped token'), and the list operation implies a read context, but there is no explicit guidance on when to choose this over alternatives like memeswap_set_wallet_refs or memeswap_select_wallet_ref. Usage is therefore implied rather than fully specified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope guarantees beyond that ('No custody / no auto-trade') and notes that the human signs, which is genuine added context. It stops short of saying what the tool actually returns or that the 'connect wallet / set avatar' steps are instructions rather than side effects, leaving mild ambiguity against the readOnlyHint.

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 purpose is front-loaded in the opening clause and the whole description is one compact sentence with no filler. The fragment 'wallet-ref duct' is garbled and slightly impairs comprehension, but the structure is otherwise efficient.

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?

With no parameters and no output schema, the description carries the burden of explaining what an agent gets back, and it does not: it never says this returns onboarding guidance/steps. Annotations cover the safety traits, so the remaining gap is the return expectation and the relationship to the sibling action tools.

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 takes zero parameters and the schema is empty with additionalProperties=false, so there is no parameter meaning for the description to supply. The baseline for a parameterless tool 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?

The description names a concrete domain (onboarding a human signer for non-custodial meme buys via MCP) and enumerates the covered steps, so the general subject is graspable. However, it never makes clear that this is a help/orientation resource rather than an executor, even though sibling tools (memeswap_set_avatar, memeswap_set_profile, memeswap_set_wallet_refs, memeswap_create_credential) cover the very actions it lists. Without that distinction an agent cannot reliably tell this tool apart from its siblings.

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?

There is no explicit statement of when to call this tool versus the sibling tools it references, nor any indication of ordering (e.g. 'call this first before creating credentials'). Usage is only implied by the word 'onboarding'; nothing is stated about alternatives or exclusions.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, open-world), so the bar is lower. The description adds real value beyond them by disclaiming auth semantics: 'Address is routing input, not proof of ownership' tells the agent no credential/ownership check is required, which is not derivable from the annotations.

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?

Two short sentences with no filler, and the primary purpose plus endpoint lead the text. Tight and front-loaded; not padded.

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?

Four parameters with 0% schema coverage, no output schema, and no explanation of what the response contains or what sol/dust/chains do. For a tool whose inputs are entirely undocumented, the definition leaves too much unspecified for reliable invocation.

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 description coverage is 0% and the description only gestures at one of four parameters ('Address'). The meaning of sol, dust, and chains is left entirely unexplained, so an agent cannot tell what to pass for three of them. With zero coverage, the description needed to compensate and largely did not.

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?

Names the resource (portfolio/holdings) and grounds it in a concrete endpoint (GET /api/portfolio), so the agent knows this is a read of an address's holdings. It stops short of distinguishing itself from siblings like memeswap_token/memeswap_tokens, leaving some ambiguity about whether 'holdings' means balances, positions, or value.

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?

"Before/after a meme buy" gives a concrete usage context that an agent can act on. No alternatives or exclusions are named, so it doesn't reach the top band, but the scenario is clear rather than merely implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing that the result is indicative, non-executing, and time-limited (expiring quotes), which the annotations cannot express.

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 short sentences with zero waste: what it is, what it does not do, and what to do next. The non-execution caveat is front-loaded ahead of the pipeline advice.

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 could reasonably say more about the quote payload, and the six parameters (four required) are largely undocumented given the 17% schema coverage. It is adequate about workflow position but incomplete about inputs and return shape.

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 description coverage is only 17% — only 'amount' carries a description and 'side' has an enum. The description names no parameters at all, leaving chain, token, from, and slippageBps undocumented in both places, so it fails to compensate for the coverage gap.

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+resource ('Indicative buy/sell quote for a listed meme coin') and pins the underlying endpoint (GET /api/quote). The phrase 'Does not execute' immediately distinguishes it from the write-side sibling memeswap_build.

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 names the follow-up step ('Next step: memeswap_build') and gives a timing rule ('Quotes can expire; request a fresh quote before build'), which is strong contextual guidance. It does not, however, explain when to prefer this over the sibling memeswap_xquote, so it falls short of full alternative routing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety and repeat-call profile is covered by structured data. The description adds the valuable auth context ('Requires live user API'), but says nothing about irreversibility, effect on the active session, or error behavior beyond that.

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?

A single front-loaded sentence: verb, resource, identity constraint, endpoint, and prerequisite, with no filler. Every clause earns its place.

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 mutation with annotations present and no output schema, the description is adequate but stops short. It omits outcome/error semantics and any note about whether revoking the active credential terminates the session, which an agent needs before calling a destructive endpoint.

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 description coverage is 0%, so the description carries the burden and does explain the lone parameter's meaning and format ('16-hex id'). That is more than the bare pattern in the schema, though it does not state the source of the id (e.g. from list_credentials).

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 ('Revoke one credential') plus the identity format and the underlying endpoint. An agent can immediately distinguish this from sibling memeswap_create_credential and memeswap_list_credentials without opening the schema.

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?

'Requires live user API' is a prerequisite, not usage guidance. It does not say when to revoke versus rotate or recreate a credential, nor what happens if the id is unknown; usage is only implied by the verb.

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

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

Annotations already disclose the safety profile (not read-only, not idempotent, not destructive, open-world). The description adds the auth scope requirement (refs:write) and the live-API precondition, which is genuinely beyond the annotations, but says nothing about what happens to the previously active ref or persistence.

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?

One tight sentence with the action front-loaded and the endpoint plus prerequisites appended. Nothing is wasted, though the endpoint in parentheses is a slightly awkward way to pack in context.

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 mutation with annotations and full schema coverage, the definition covers action, endpoint, and auth needs. It still leaves open what selecting an active ref changes and whether prior state is replaced, which matters for a non-idempotent write.

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% and the single 'override' parameter is fully documented in the schema (A-Z letter for the wallet-ref duct). The description adds no syntax or format detail beyond that, so the baseline 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 (select) plus the resource (active wallet-ref letter) and even the underlying endpoint PUT /api/v1.1/me/refs/active. This distinguishes it from memeswap_list_wallet_refs and memeswap_set_wallet_refs, though it does not explicitly name those siblings.

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 clear prerequisite (requires live user API + refs:write), which is real usage context. However it never states when to choose this over set_wallet_refs or list_wallet_refs, so selection guidance is only implied.

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

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

Annotations already declare non-readonly, open-world, non-idempotent, non-destructive. The description adds real behavioral context beyond that: the auth requirement and the v0.2 limitation that raw uploads are unsupported, which is exactly the kind of caveat an agent needs before calling. It stops short of saying what happens to wallet/avatar state on success or failure.

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?

Two compact sentences with the action front-loaded and the constraints trailing; nothing is padded. The endpoint path is mildly extraneous but plausibly useful for debugging.

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 mutation tool with no output schema, the description covers auth and the v0.2 capability gap, which is the most decision-relevant fact. It is still incomplete on the return behavior and on how 'note' interacts with the upload, leaving the agent to infer that the call is effectively a stub.

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 50%: only 'wallet' is documented, and the description adds nothing about the 'note' parameter at all. The phrase 'wallet/profile image' vaguely ties the wallet param to the target, but with a low coverage schema the description should have compensated for the undocumented 'note' field and it does not.

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 ('Upload wallet/profile image') and even names the backing endpoint, so it is distinguishable from siblings like memeswap_set_profile or memeswap_build. The only weakness is that it is unclear whether the operation actually succeeds, since no image parameter exists.

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 discloses a prerequisite (session bearer) and, more importantly, that 'MCP does not accept raw image uploads in v0.2' — effectively a when-not-to-use signal. But it never contrasts this with memeswap_set_profile, which is the obvious alternative for profile changes, so routing guidance is incomplete.

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

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

Annotations cover the write/idempotency profile, and the description adds substantial context beyond them: the auth requirement, that MCP cannot sign the message, and that it currently only returns guidance until an agent session duct exists. That last point is critical for an agent to avoid expecting a real mutation.

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?

Two compact, front-loaded sentences that prioritize the action, then the blocker. Slightly jargon-heavy ('agent session duct'), but no wasted text.

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 5-parameter write tool with no output schema and 40% coverage, the description covers the crucial auth and no-op caveats but leaves optOut and the wallet requirement unexplained. It is adequate but not thorough.

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 description coverage is only 40%, but the description names name, emoji, and 'preset' avatar, partially compensating. It says nothing about optOut or the required wallet field (which the schema itself documents), so coverage remains incomplete.

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 ('Set display name / emoji / preset avatar') and even names the endpoint. It distinguishes itself from the sibling memeswap_set_avatar by qualifying 'preset avatar', though the boundary between the two tools remains slightly ambiguous.

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 reveals the precondition (wallet session bearer or signed profile message) and the fact that MCP cannot sign, which implies when the tool is usable. However, it gives no direct guidance on when to pick this over memeswap_set_avatar or what the caller should do about the signing gap.

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

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

Annotations already declare the write/non-readonly, non-idempotent and open-world profile, so the bar is lower; the description still adds real value beyond them by naming the auth requirements (live user API + refs:write token) and the 'public addresses only' safety constraint. It does not say what happens to existing refs on replacement, keeping it from a 5.

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 short telegraphic fragments, front-loaded with the verb+resource and no filler. Slightly clipped to the point of being choppy, but nothing is wasted.

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 mutation tool with no output schema, the definition covers the endpoint, auth, and address-safety constraint, which is enough to call it safely. It omits return behavior and the effect of replacing an existing list, leaving a real gap.

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?

With only 50% schema description coverage and 2 parameters, the description's 'Public addresses only' reinforces the wallet field but adds no syntax, format, or meaning for the 'active' override param beyond what the schema already documents. Baseline 3 for schema doing most of the work.

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 ('Replace wallet-ref list') plus the underlying endpoint PUT /api/v1.1/me/refs, which cleanly separates it from the sibling memeswap_list_wallet_refs and memeswap_select_wallet_ref. It does not name those alternatives explicitly, so it stops short of a 5.

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?

Gives prerequisites ('Requires live user API + refs:write token'), which implicitly signals when the tool is callable, but offers no explicit when-to-use versus memeswap_select_wallet_ref or list_wallet_refs. Usage context is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so safety is covered. The description adds a genuinely useful constraint outside the structured data: OAuth cannot be completed programmatically and requires a human browser session, which shapes how the agent should act on the results.

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?

Two short sentences, purpose first, caveat second. No filler and no redundancy with the schema or annotations.

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 zero-argument read tool this is nearly sufficient, but with no output schema the description could briefly indicate what a provider listing contains, which would help the agent interpret results.

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 takes zero parameters, so the baseline of 4 applies; there is nothing for the schema or description to disambiguate.

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 (List) and resource (social connect providers) and even names the underlying endpoint. No sibling tool in the set covers provider discovery, so the agent can distinguish it immediately.

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?

Usage is implied rather than stated: the note about OAuth needing a human browser session hints that this tool is for discovery and cannot complete a connection, but there is no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is fully covered. The description adds the HTTP method and endpoint path, which is useful route context but not richer behavioral detail like rate limits or response shape, so 3.

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?

Single sentence, front-loaded with the core purpose and context, and no redundant words. Highly efficient.

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 two-param read tool with rich annotations, the description covers purpose, use context, and endpoint. However, with no output schema it does not describe what the 'deep profile' contains, and parameter semantics remain thin, leaving some gaps.

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 description coverage is 0%, so the description must compensate. It maps chain and address to path segments via ':chain/:address', implying they are identifiers, but gives no examples of valid chain values or what address represents, adding only partial meaning.

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 resource ('one meme coin') and operation ('deep profile') plus context ('before a buy decision (risk/market)'). The phrase 'one meme coin' implicitly distinguishes it from the plural memeswap_tokens list tool, but no sibling is named explicitly, keeping it at 4.

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 a clear use context: run this before a buy decision for risk/market analysis. It does not name alternatives (e.g., memeswap_tokens for listing) or exclusions, but the when-to-use is explicit, matching a 4.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful context beyond them: the underlying endpoint and the staleness caveat ('Observations can be stale'), which affects how an agent should present results.

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?

Two tight sentences: the resource first, then routing and freshness caveat. Every clause earns its place with no restatement of the name or annotations.

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?

With no output schema, the description still conveys what comes back (market rows) and a key freshness caveat, and it routes to the sibling for lookups. Missing details like ordering, pagination, or which fields the rows contain keep it from a 5.

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 takes zero parameters, so there is nothing for the description to disambiguate; schema coverage is 100% and the baseline for a no-parameter tool is 4. The description correctly spends no space re-explaining inputs.

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 ('Listed meme coin market rows from GET /api/tokens') and explicitly distinguishes itself from memeswap_token ('Prefer memeswap_token for one address'). An agent can pick between the two without opening either schema.

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?

Gives a clear trigger ('use when the user asks for hot / new / trending memes to research before a buy') plus an alternative for the single-address case. No explicit when-not or exclusion conditions beyond that, so it lands just short of the top band.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds meaningful context: the 0.85% fee, the unsigned-construction-only security model, no custody/signing/unrestricted submit, and NFA. This is genuine behavioral disclosure beyond the structured hints.

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 workflow ('First read...quote→unsigned build') is front-loaded and the definition is compact with no wasted sentences. It leans on dense jargon/fragments ('NFA', arrow notation) that slightly reduce parseability but remain efficient.

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-parameter, annotation-covered helper the description orients the agent well, but with no output schema it never says what the agent receives back (guidance text) nor points to the concrete sibling tools to call next (quote/build/chains). Adequate but with clear gaps.

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 takes zero parameters, so per the rubric the baseline is 4; there are no parameters for the description to clarify and schema coverage is vacuously 100%.

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 purpose: a first-read guidance tool for buying meme coins or researching memecoins through a quote→unsigned build flow. It also carves out scope ('Not a token launcher'). However, it does not distinguish itself from close siblings like memeswap_onboarding_help or explicitly tie to memeswap_quote/memeswap_build.

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 clearly signals when to read it ('First read for agents helping users buy a hot meme coin or research memecoins'), which is a strong routing cue. It lacks named alternatives or explicit 'when not to use' beyond the launcher exclusion.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds real value beyond them: it clarifies the tool only produces unsigned material, that the wallet signs externally, and that nothing is submitted — a workflow-critical distinction.

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 tight sentences, front-loaded with purpose, then workflow, then the negative constraint. No filler, though the endpoint notation is slightly redundant ornamentation.

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 9-parameter tool with no output schema and near-zero schema description coverage, the description leaves the caller without enough to construct a valid request (which chain/token identifiers, amount units, slippage semantics) or to understand the shape of the returned unsigned material.

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 description coverage is only 11% across 9 parameters, and the description explains none of them — fromChain/toChain/from/to/token/order/slippage semantics, address format, or whether amount is in source or target units are all unstated. With low coverage the description is supposed to compensate, and it does not.

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 (quote) plus the distinguishing scope (cross-chain, buy a meme) and the artifact returned (unsigned material + endpoint GET /api/xquote). It implicitly separates itself from the single-chain memeswap_quote, though it never names the sibling, so differentiation is left to inference.

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?

"when the user wants to buy a meme across chains" gives a usable trigger condition, but there is no when-not guidance and no explicit routing to memeswap_quote or memeswap_build as alternatives. Adequate but with a clear gap.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely non-redundant behavior: it is 'provider-reported' and 'may lag final chain state,' which tells the agent not to treat the result as authoritative chain truth.

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?

Two short sentences with the core identity first and the caveat second. Nothing is wasted and it 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 read-only lookup with no output schema, the identity plus freshness caveat is serviceable, but with four undocumented parameters and no return-shape hint, the definition leaves real gaps an agent would need to guess around.

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 description coverage is 0% for four parameters (bridge, txHash, toChain, fromChain), and the description mentions none of them. With txHash required and three optional scoping fields, the agent gets no guidance on which of bridge/toChain/fromChain are needed to disambiguate a lookup, so the description fails to compensate for the schema gap.

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 ('bridge transaction status') and the underlying endpoint, which is enough to separate it from memeswap_xquote (quotes vs. status). It does not explicitly name the sibling it partners with, so it falls short of the top mark.

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 implies the usage context (checking a bridge transaction after submission) via the endpoint and freshness caveat, but never states when to call this versus alternatives like memeswap_xquote or when it is not appropriate. Usage is left to inference.

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