MemeSwap MCP

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

Annotations already mark this as non-read-only, non-destructive, non-idempotent, and open-world. The description adds the critical behavior that this is only a build step and does not sign/submit/confirm, which prevents dangerous misinterpretation as a transaction execution 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?

Three tight sentences, front-loaded with the core action followed by the critical non-actions and the caller requirement. Every sentence adds distinct value.

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 purpose and the non-signing nature, which is important given the annotations and no output schema. However, for a 7-parameter tool with a nested quote object and no output schema, it does not explain the return format, authentication needs, or several required parameters.

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%, so the description must compensate, but it only restates the quote and from bindings already documented in the schema. It gives no additional meaning for side, chain, token, or slippageBps.

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 (Build) and resource (unsigned swap transaction material), plus the endpoint and the binding to a prior quote and from address. This distinguishes it from sibling quote tools and from any signing/submission tool.

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?

Implies the tool must be used after a prior quote and with a public from address, and explicitly says it does not authorize, sign, submit or confirm. However, it does not name the alternative (e.g., memeswap_quote) or state when not to use it.

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 destructiveHint=false, so the safety profile is fully covered. The description adds that the data comes from a specific API endpoint and is static 'supported network' reference data, which is mildly useful context but not rich behavioral detail.

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 compact sentence with no filler, and the resource is front-loaded. It is terse to the point of being cryptic but wastes no words.

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 carries the burden of describing the return shape, and it only gestures at it via three vague category names. The parenthetical hints at content but does not explain the structure an agent would receive.

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 to document; the baseline of 4 applies. The description correctly implies a no-argument fetch by not listing any 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?

The description names a specific resource (supported network metadata) and enumerates the payload categories (keys, explorers, aggregators), which distinguishes it from the credential/wallet/quote siblings. It is a noun phrase rather than a verb+resource, but the referenced GET endpoint implies a read fetch, so the intent is clear.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives among the many siblings. The agent must infer that this is the lookup for chain/network metadata on its own.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower; the description still adds useful context by disclosing that the payload is sanitized and that it reflects origin liveness and fee-route configuration. With no output schema, this is helpful but still thin on what specific fields come back.

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, purpose front-loaded, and the final negative clause earns its place by preventing confusion with the many per-token/token siblings. 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 parameterless, low-complexity health check with no output schema, the description covers what is being verified and that the response is sanitized. It could be slightly more explicit about how an agent should act on a failure, but it is adequate for correct 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?

The tool takes zero parameters, so per the rubric the baseline is 4 and no compensating parameter documentation is needed. Nothing is ambiguous about the (empty) input.

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 (health/readiness of the origin) and clarifies the check's scope: origin up plus fee-route configuration. The closing "Not per-token data" distinguishes it from per-token siblings like memeswap_token/memeswap_tokens, though the verb phrase "Sanitized readiness" is slightly abstract.

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 says what the tool is not (per-token data) but gives no positive guidance on when an agent should call it versus alternatives, nor any prerequisites or failure conditions. Usage must be inferred from the name and the name of the endpoint.

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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that a human signs the wallet connection and credentials are scoped, which is meaningful behavior, but 'wallet-ref duct' and 'security bar unchanged' are vague and no return format is described.

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 front-loaded sentence with a compact list; no wasted words. The unexplained 'wallet-ref duct' slightly reduces precision.

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-param help tool with annotations, it sketches the onboarding sequence, but the steps are compressed and one phrase is unclear. It does not indicate whether it returns live instructions or static text, and there is no output schema to fill that 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 tool has zero parameters and schema coverage is vacuously 100%, so parameter semantics are not at issue. Baseline 4 is appropriate; the description adds no parameter meaning and needs none.

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 (MemeSwap onboarding) and enumerates concrete steps, so an agent knows this is a help/how-to tool. It does not explicitly distinguish itself from memeswap_trading_help or say whether it returns static docs or live state, but the scope is clear.

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?

No when-to-use guidance, no alternatives, no prerequisites. It implies you consult it before onboarding, but does not say to call it before set_profile/set_avatar or what to do if onboarding is already complete.

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 genuinely non-obvious behavior: the address is routing input and does not establish ownership, which tells the agent this is not an authenticated self-lookup. It stops short of disclosing pagination or result shape.

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 tightly written sentences with zero waste; the read-only scope is front-loaded and the ownership caveat follows immediately.

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, 0% schema description coverage, and four parameters, the description should carry more of the load. It never explains what holdings are returned, what `dust` or `chains` do, or whether address is required despite required-parameters being 0.

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% across 4 parameters. The description clarifies that the address may be EVM or Solana (hinting at the `address`/`sol` split), but `dust` and `chains` are entirely unexplained in both the schema and the description, leaving half the surface ambiguous.

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: read-only holdings for a caller-supplied address, with the endpoint GET /api/portfolio. An agent can identify it as a portfolio lookup, though it doesn't differentiate against siblings (which are largely unrelated anyway).

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 'caller-supplied public address' and the routing/ownership caveat imply the context for use, but there is no explicit when-to-use or when-to-avoid guidance relative to alternatives. Use case is inferable 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 readOnly/idempotent/non-destructive/openWorld, but the description adds genuinely new behavioral facts: the call does not execute a swap, and quotes have a finite validity window requiring a refresh before build. That temporal/expiry constraint 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 zero filler; the non-execution fact and the expiry warning are both front-loaded and each 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?

No output schema exists and the description never characterizes the quote result (price, route, expiry timestamp), nor does it cover the undocumented required parameters. For a 6-parameter read tool with 17% schema coverage, this leaves meaningful gaps an agent must guess at.

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' is documented), so the description carries the burden for chain, side, token, from, and slippageBps. It mentions none of them, leaving the enum for 'side', the token identifier format, and slippageBps semantics entirely unexplained.

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 swap quote) and explicitly scopes it as non-executing, which distinguishes it from memeswap_build. It does not name the sibling it competes with (memeswap_xquote) directly, but the 'does not execute / before build' framing makes its role separable.

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 workflow context: get a quote here, then build, and re-quote if it has expired. This tells the agent when to call it relative to memeswap_build. No explicit exclusions or comparison against memeswap_xquote, which is the one remaining 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 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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds one useful trait beyond them: the profile is 'stored' (cached) rather than a live quote, which separates it from the quote siblings. It says nothing about auth needs, freshness, or response shape, so it stays at the baseline-plus level.

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 with no filler, correctly prioritizing the resource and its payload before the route. It is efficient, though arguably too terse given the undocumented parameters.

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 GET tool with no output schema and 0% schema description coverage, the description should at least characterize the returned market/risk fields or the address format. It identifies the endpoint but leaves both the parameter formats and the response contents unstated; 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?

Schema description coverage is 0%, so the description carries the burden, and the embedded route does map the two required params to chain and address, adding meaning about what address refers to. However, it gives no format guidance (e.g. checksummed hex, chain slug conventions) despite the address being minLength 32, so the compensation is only partial.

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 ('one listed token') and its payload ('detailed stored market and risk profile'), and the route (GET /api/token/:chain/:address) pins it to a single-token lookup. It implicitly contrasts with the plural sibling memeswap_tokens, but never states the verb 'retrieve/fetch' or explicitly distinguishes itself from memeswap_quote, so it falls short of 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?

There is no when-to-use, when-not-to-use, or prerequisite guidance. Nothing tells the agent how this differs from memeswap_tokens, memeswap_quote, or memeswap_xquote, leaving the routing decision to inference.

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/openWorld safety profile, so the bar is lower. The description still adds two useful behavioral traits: results 'can be large' (size warning) and 'observations can be stale' (data freshness caveat), which are not derivable from 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?

Three short clauses, each carrying distinct information: what it returns, how to narrow scope, and a data-freshness caveat. No wasted words, front-loaded with the resource.

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-param list read with no output schema, the description gives the agent enough to call it and to prefer the alternative when appropriate. It omits return shape details, but with no output_schema those remain somewhat implied even if the endpoint is named.

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 is 4. The description correctly indicates no filtering inputs are accepted and routes to the parameterized sibling for address-scoped queries.

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 ('Listed token market rows') and names the source endpoint (GET /api/tokens). It clearly distinguishes itself from the single-token sibling by pointing to memeswap_token for one address.

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 tells the agent to prefer memeswap_token when targeting a single address, which is a clear alternative-routing rule. It does not state when-not-to-use in other senses, but the primary sibling distinction is handled.

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 non-open-world, so the safety profile is covered. The description adds real context beyond that: it enumerates the capability boundary (unsigned construction only; no custody, no signing, no unrestricted submit), which tells the agent what this MCP will never do. It could go further on what the returned content actually covers.

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 terse, front-loaded sentences with no waste, and the calling instruction ('Read first') is placed early. It reads as fragments rather than clean prose, but every word 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 parameterless help/policy tool with no output schema and full annotation coverage, the description is close to sufficient. It still leaves the agent guessing what content is returned and how it relates to onboarding_help, which is a gap worth closing for a tool the agent is told to read first.

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 schema coverage is 100%, so there is nothing for the description to document. 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 identifies the tool as a 'Security and product boundary for this MCP,' which tells the agent it returns policy/scope information rather than performing an action. However, there is no verb+resource phrasing and it never clarifies how it differs from a sibling like memeswap_onboarding_help, so the agent must infer that this one is the policy precondition doc.

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?

'Read first' is an explicit sequencing directive that tells the agent when to invoke this tool relative to all others. It stops short of naming alternatives or stating when this can be skipped (e.g., versus onboarding_help), so it is implied-but-not-complete 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 and destructiveHint=false, so the safety profile is covered. The description usefully adds that transaction material is 'unsigned' and only returned 'where available' (i.e., partial results possible) and that nothing is submitted — real context beyond the annotations, though no auth or rate-limit detail.

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, front-loaded with the core purpose and ending on the key boundary ('Does not submit'). Nothing wasted, though it is arguably too terse given the tool's complexity.

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, yet the description only gestures at the return ('unsigned transaction material where available') without covering the quote fields an agent would act on, and nine inputs remain largely undocumented. Adequate as a minimum, but thin for a 9-param cross-chain quote tool.

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?

Nine parameters with only 11% schema description coverage, and the description adds no parameter meaning at all — no explanation of fromChain/toChain vs fromToken/toToken, slippage units, or the order/slippage semantics. The description 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 ('cross-chain route quote') and its output ('unsigned transaction material'), which cleanly separates it from the same-chain memeswap_quote sibling. The endpoint path (GET /api/xquote) confirms the operation. It stops short of explicitly naming the alternative tool.

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?

'Does not submit' implies this is a read/quote step that must be followed by a submission tool, but no sibling is named and no when-not-to-use condition is given. Usage is only implied, leaving the agent to infer that memeswap_build or a submit step comes next.

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.