MemeSwap MCP

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral detail: the data's origin (GET /brand/kit.json) and that it is 'relayed as is', telling the agent there is no transformation or filtering of the canonical kit.

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 sentence, front-loaded with the usage trigger followed by the payload and its source. Nothing is redundant or 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?

With no output schema, the description carries the return-value burden and does so well, listing the kit's contents and identifying the endpoint with a 'relayed as is' guarantee. For a zero-parameter, read-only fetch that is 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?

Zero parameters, so the baseline of 4 applies; there is no parameter surface for the description to explain and it correctly adds 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?

The description states a specific verb and resource ('returns the approved brand kit') and enumerates the payload (artwork URLs, colours, logos, copy, usage rules), and its 'before producing any MemeSwap promotion' framing separates it from promotion-producing siblings such as memeswap_reel_post or memeswap_marketing_help.

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?

'Use before producing any MemeSwap promotion' gives an explicit trigger condition, which is strong usage context. It stops short of a 5 because it names no alternative or when-not condition (e.g. what to use for help text versus assets).

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?

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 only give the generic non-read-only/non-idempotent profile; the description adds the critical behavioral fact that the secret is returned once and must never be logged, plus the API_GAP failure mode. Missing details on rate limits or what happens to existing tokens, but the one-time-secret disclosure is high-value behavior beyond structured fields.

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, the endpoint, the session caveat, and the secret-handling warning all appear in one compact sentence with zero filler. The telegraphic jargon ('API_GAP', 'wallet-session') costs a little readability 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 and zero parameter documentation, the description does cover the most consequential return behavior (one-time secret) and the auth-related failure mode. But the three input parameters remain entirely unexplained, which leaves a real gap 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?

Schema description coverage is 0% across all three parameters (label, scopes, ttlDays) and the description adds nothing substantive: 'scoped' loosely hints at the scopes array, but label and ttlDays semantics, defaults, and constraints (max 12 scopes, max 365 days) are nowhere explained in prose.

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 even cites the endpoint POST /api/v1.1/me/credentials. It implicitly separates itself from the credential siblings (list/revoke), but never names them, so differentiation requires the agent to infer from the verb alone.

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?

'Usually wallet-session only on portal; agents get API_GAP' is genuine usage guidance — it tells the agent this call may fail for agents and how to recognize it. However, there is no explicit statement of when to create a credential versus reusing one, nor any pointer to list_credentials/revoke_credential.

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 declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds two useful facts not in the annotations: the data is public (no auth needed) and the returned rows are server-ranked rather than caller-sorted.

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 tightly written sentence that front-loads the action and appends the endpoint and return semantics. No padding, though it is arguably too short for six 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?

With no output schema, no enum hints, and six parameters at zero schema coverage, the description does the minimum: it names the ranking dimensions but not their accepted values. An agent still cannot call this reliably without trial and error.

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 6 parameters, so the description carries the full burden. It names four of them (board, period, role, metric) but gives no valid values, formats, or meanings, and omits 'q' and 'limit' entirely, leaving the agent unable to populate any field confidently.

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 ('read the public Earn leaderboards') and even cites the backing endpoint, so the agent knows exactly what the tool retrieves. It does not distinguish itself from the sibling memeswap_earn_summary, which is the main remaining ambiguity.

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?

'Use to read...' implies the read/query context, but there is no guidance on when this leaderboard tool is preferable to memeswap_earn_summary or which board/period combinations are meaningful. Usage 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 readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description still adds real value: the HTTP method and path, the required Authorization: Bearer header, and the semantics of scope=profile. It does not describe pagination or the shape of the returned summary, which keeps 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?

A single front-loaded sentence: purpose first, then endpoint/auth mechanics, then the scope nuance. Dense but every clause carries information; the semicolon-chained style is slightly run-on but 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?

With no output schema, the description at least says it returns the server summary and names the two quantities (pending and available Earn amounts). Combined with the auth and scope details, an agent has enough to invoke it correctly, though the return format itself stays vague.

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 67% and the undocumented parameter is scope, which the description does cover (scope=profile totals every wallet of the verified profile). It also confirms wallet is used as a query parameter; only the session parameter's meaning is left entirely to the schema, which already documents it well.

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 (read) and resource (pending and available Earn amounts for the session wallet), plus the underlying endpoint. It is clearly distinguishable from most siblings, but it never names the nearest neighbor, memeswap_earn_leaderboard, so the differentiation is inferred rather than stated.

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?

"Use to read ... for the session wallet" gives implied usage, and the scope=profile clause tells the agent about a per-profile aggregation mode. However there is no explicit when-not guidance and no routing to earn_leaderboard or portfolio for related questions, so usage is only partially covered.

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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that it returns a flow in order, the signing messages, and rules, and that the server enforces every rule - useful but modest context beyond 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?

A single front-loaded sentence that leads with the usage condition and then the payload. No filler, no restatement of the name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameters, the description has to say what comes back, and it does (ordered flow, signing messages, plain-word rules). It is nearly complete; it could have mentioned that it covers the referral/Squad steps in relation to the individual sibling tools, but nothing critical 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, so the schema has no semantics to enrich and the baseline is 4. The description correctly implies there is nothing to supply, describing only the returned content.

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 the domain of the tool (growth flows: recruiting, Squads, referral fees, token reels) and what it produces (ordered flow, signing messages, rules). It is clearly a help/orientation tool and distinguishable in topic from siblings like memeswap_trading_help or memeswap_onboarding_help, though it never explicitly contrasts with 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?

"Use first when an agent will recruit people, run a Squad, earn referral fees or post token reels" supplies concrete trigger conditions and an explicit ordering cue ("use first"). It does not name alternative help tools or state exclusions, so it stops short of full when/when-not 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, 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 this a read-only, idempotent, non-destructive, non-open-world operation, so the safety profile is covered. The description adds real substance beyond that: it discloses the returned content (referral link, App Store link, reels with AI disclosure requirements, copy rules) and that output is prose rather than structured data. It does not explain size, caching, or freshness of the guidance.

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 led by the usage trigger, with no filler or restatement of the title. The parenthetical list of returned artifacts is dense but each item earns its place by telling the agent what to expect back.

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 does the work of previewing the return value (attribution links, disclosure rules, copy rules), which is exactly what a zero-parameter help tool needs. No prerequisites, auth requirements, or scope limits are stated, but for a read-only informational endpoint the remaining gap is small.

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 clarify. The parenthetical enumerating outputs is more relevant to return content than to parameters, so no credit or penalty is warranted here.

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 action and resource: it returns promotion instructions with attribution (referral link, App Store link, reels with AI disclosure) plus copy rules. It is clearly a guidance/help tool, but it never distinguishes itself from near-neighbors like memeswap_growth_help, memeswap_onboarding_help, or memeswap_brand_kit, so an agent must infer the boundary.

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 opening clause 'Use when an agent will promote MemeSwap anywhere' gives an explicit trigger condition, which is more than most help tools offer. It stops short of saying when to prefer this over the sibling *_help tools or brand_kit, so the alternative-selection guidance 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=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?

With annotations already declaring non-read-only, non-idempotent, non-destructive, and open-world behavior, the description adds useful operational context: it opens an upload session with a bearer, uploads bytes, and returns specific fields. It does not cover permanence, rate limits, or error conditions, but it meaningfully extends the annotation profile.

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 definition is a single front-loaded sentence that moves from purpose to flow to return values. It is dense but largely earns its length by conveying a multi-step operation compactly.

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 complex mutation tool with no output schema and only 50% schema-description coverage, the description does well by naming the return fields and the upload-session flow. It still leaves some gaps around parameter meaning and post-publication behavior, but it is broadly complete enough to invoke correctly.

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%, so the description needs to compensate. It maps session to bearer and mentions videoUrl, chain, token, caption, and aiDisclosure in the upload body, but it does not explain chain, token, or caption semantics, and it references fileSha256 even though that is not an input-schema parameter. This is useful but incomplete for a 6-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: posting an agent reel about a listed token from an HTTPS video URL. It is clear enough to distinguish from the related memeswap_reel_status sibling by verb, though it does not explicitly name 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?

The phrase 'Use to post...' gives the intended usage, but no explicit when-to-use conditions, prerequisites, or alternatives are provided. The agent can infer that this is the post path versus the status path, but that inference is not spelled out.

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 declare readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds valuable context by listing return fields (status, hiddenReason, removedReason, aiDisclosure, tokenCard) and noting that a session is needed for restricted visibility, though it lacks rate-limit or error behavior 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 that packs the core action, endpoint, return fields, and session condition with no wasted words. It is appropriately sized for 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?

Given no output schema, the description helpfully enumerates key return fields and explains the session's role for seeing restricted content. It covers the essential information an agent needs to call correctly, though it omits error handling or pagination details.

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 50% schema coverage, the session parameter is documented in the schema, but the description adds the purpose of passing it (to see draft/hidden/removed reels). The reelId parameter is not described beyond its name and endpoint path, so the description only partially compensates 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?

The description states a clear verb ('poll') and resource ('one reel'), and includes the endpoint GET /api/reels/<reelId>, making it easy to distinguish from memeswap_reel_post. It does not explicitly name an alternative sibling, so it falls 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 says 'Use to poll one reel' and specifies that passing the creator session reveals draft, hidden, or removed reels, giving clear context for invocation. However, it offers no when-not-to-use guidance or explicit alternatives, which a 5 would require.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true. The description usefully reinforces the non-idempotent nature ('once per wallet') and notes the return payload, but says nothing about required authorization or what happens on a duplicate acceptance.

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 the action, the frequency constraint and the endpoint; 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 4-required-parameter mutation with no output schema, the description covers intent and return shape but omits auth requirements, duplicate-call behavior, and the meaning of 'termsVersion'. 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 coverage is 75%, with 'termsVersion' undocumented in the schema, yet the description adds no parameter guidance. Baseline 3 applies when the schema does most of the work, and the description does not compensate for the one 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 ('record the referrer terms acceptance') and even names the HTTP endpoint. It is clearly distinguishable from read-side siblings like memeswap_referral_terms or memeswap_referral_stats, though it never names the closely related memeswap_referral_accept_message sibling.

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?

'Use once per wallet' is a real usage constraint that informs the agent about call frequency, but no alternatives or prerequisites are named. Nothing tells the agent to call memeswap_referral_accept_message first to obtain the signature, which is implied by the required 'signature' parameter.

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 the description adds real value beyond them: it discloses that each message carries a different timestamp encoding (ISO for the terms acceptance message, epoch ms for the referral message). It omits any auth/prerequisite detail, but that is a minor gap given the safety profile is covered.

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 dense sentence that front-loads the purpose and then enumerates the outputs. Every clause earns its place, though packing two timestamp formats into one sentence is slightly heavy.

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 does the work of describing the returned artifacts — two messages, their formats, and which tool consumes each — which is enough for an agent to chain the calls. Missing only prerequisite/auth context for a read-only helper.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so wallet and termsVersion are already documented, including the default for termsVersion. The description adds no additional meaning about either parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: retrieving the two messages a referrer signs, with fresh timestamps. It even maps each returned message to its consuming sibling (memeswap_referral_accept vs memeswap_referral_code/stats), so the agent can tell it apart from a generic signer.

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 framed with 'Use to get...' and names the downstream tools that consume each message, giving clear context for when this helper is needed before those calls. No explicit when-not or exclusions, so it stops short of a 5.

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

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

Annotations already cover the safety profile (not read-only, open-world, non-idempotent, non-destructive), so the description's job is to add context, which it does: it discloses the accepted-terms prerequisite, the required signed message, and the return payload fields. It does not state auth/permission requirements beyond the signature.

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 that leads with the precondition and return contents, with the ts clarification appended after a semicolon. 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 3 required params, no output schema, and no nested objects, the description covers the trigger condition, the signed-message requirement, the ambiguous ts parameter, and the expected return fields. Sufficient for an agent to call it correctly.

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 67% (wallet and signature documented, ts not), and the description compensates by defining ts as 'the epoch ms inside the signed referral message'. This adds genuine meaning over the bare integer type, though the exact message format remains unstated.

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 ('get the referral code, link, shareText and rules') and even names the backing endpoint (POST /api/referrals/code). It is distinguishable from sibling referral tools by its precondition, though it does not name those siblings directly.

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?

'Use after the terms are accepted' gives an explicit sequencing precondition that tells the agent when this tool is valid, distinguishing it from referral_terms and referral_accept. No exclusion cases or explicit alternative names are provided.

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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful behavioral context by explaining that certain parameters unlock private earnings data versus public counts, which goes beyond 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?

The description is a single sentence and front-loads the main purpose, but the parenthetical about the referral message signature is awkwardly placed after ts, and the phrase 'the referrer own earnings rows' is grammatically unclear.

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 stats tool with no output schema, the description gives enough to understand the two modes and required credentials. However, it leaves ts semantics and the exact shape or availability of returned counts and earnings rows underspecified.

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%, with wallet and signature described in the schema. The description adds that wallet, signature, and ts together are needed for earnings rows, but it does not clarify the meaning or format of ts, and code is only implicitly defined as a referral code.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: read counts for a referral code, and names the underlying API endpoint. It also distinguishes public counts from authenticated earnings rows, though it does not explicitly contrast itself with sibling referral tools like memeswap_referral_code or memeswap_referral_accept.

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 explains the two usage modes: public counts require only the referral code, while referrer-specific earnings rows require wallet, signature, and ts. It does not name alternative tools or specify when not to use this one, but the context is clear.

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, openWorldHint=true and destructiveHint=false, so safety and side-effect behavior are covered. The description confirms it is a GET retrieval but adds little behavioral context beyond annotations, such as versioning semantics or whether acceptance requires the returned termsVersion. A 3 fits when annotations carry the main behavioral load.

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 the usage trigger first and the returned fields second. No filler, nothing repeated from the 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?

With no output schema available, the description compensates by naming the concrete return fields (termsVersion, URLs, message templates). Combined with the annotations covering the safety profile, an agent has everything needed to call this correctly.

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. There is nothing for the description to disambiguate, and it correctly implies a parameterless fetch.

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 (returns/GET) plus the resource (/api/referrals/terms) and enumerates the payload (termsVersion, terms and rules URLs, acceptance message templates). An agent can distinguish this read-only terms fetch from the sibling memeswap_referral_accept mutation 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?

"Use before accepting referrer terms" gives a clear trigger condition tied to the referral acceptance flow. It stops short of naming memeswap_referral_accept explicitly, but the sequencing advice is unambiguous and actionable.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds the return contract (field names) that no output schema provides, which is genuinely useful; it does not mention whether the message/nonce expires or requires a live socket, a minor gap.

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 opens with the trigger ('Use to start a wallet session'), then lists the return fields and the next step with zero wasted 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?

For a one-parameter flow-initiation tool with no output schema, the description supplies the return shape and the follow-up call, which is enough to use it correctly. Expiry/lifetime of the nonce and message 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?

Schema coverage is 100% and the schema already documents the wallet param including its 0x pattern and the 'never a key or seed' warning. The description does not add any input-parameter meaning beyond that, so the baseline 3 is appropriate.

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 action (produce a wallet signing message) and enumerates the exact return payload shape {wallet, ts, nonce, message}. It implicitly distinguishes itself from memeswap_session_open by describing the two-step flow, though the phrase 'start a wallet session' is slightly ambiguous since session_open is what actually opens the session.

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 explicit sequencing: call this first, have the wallet personal_sign the message, then pass the signature to memeswap_session_open. The alternative/next tool is named, leaving little to infer, but there is no statement of when this step can be skipped or what preconditions exist.

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 (write, non-idempotent, non-destructive, open-world), and the description adds real context: the endpoint path, the fact that it mints a bearer token, and what that token authorizes downstream. It does not mention token expiry/reuse semantics or failure modes, but with annotations present this is solid.

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 dense sentence that front-loads the when-to-use clause before the mechanics. No filler, though cramming payload, endpoint, return shape, and downstream uses into a single sentence makes it slightly harder to scan.

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 usefully enumerates the return fields ({token, wallet, expiresAt}) and names the endpoint. Error behavior and the ts/nonce semantics are the remaining gaps, but for a 4-parameter auth handshake this is nearly 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?

At 50% schema coverage only wallet and signature are documented (the latter as a personal_sign over the exact message); ts and nonce rely on the bare schema types. The description merely restates the payload keys in the same order as the schema, adding no meaning to the undocumented parameters.

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 (opens a session by POSTing signed credentials to /api/game/session) and enumerates both the payload and the return shape. It also distinguishes the step from its prerequisite sibling memeswap_session_message by saying to use it after signing the session message.

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 an explicit precondition ('after signing the session message') and states what the resulting token unlocks (social login, earn summary, reel posts). It does not name alternative tools or say when not to call it, so it falls just short of full routing guidance.

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

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 already declare write semantics (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description adds genuinely useful context: the auth requirement and the fact that it returns guidance rather than performing the write. That last point is undercut by opaque jargon ('agent session duct') and no statement of what the guidance response actually contains.

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 action front-loaded and the constraint following, so it is scannable. The phrase 'agent session duct' is unnecessary jargon that costs a little clarity.

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 does cover the auth precondition and the fact that a guidance response comes back, which is more than nothing. But an agent still cannot tell what the guidance says, whether optOut exists, or how this differs from memeswap_set_avatar.

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 40% and the description names just three of five parameters (name, emoji, avatar), saying nothing about the required wallet parameter or the optOut flag. With a required-but-undescribed parameter and low schema coverage, the description does not compensate for the 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 (set display name / emoji / preset avatar) plus the underlying endpoint, so an agent knows exactly what the tool mutates. It does not differentiate itself from the sibling memeswap_set_avatar, which appears to overlap on avatar setting, but the core purpose is otherwise unambiguous.

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 real precondition (wallet session bearer or signed profile message) and warns that MCP cannot sign, which implies the tool is effectively inert/gated. However it never names alternatives such as memeswap_set_avatar or the session/message siblings that would establish the prerequisite, so the agent is left to infer the workflow.

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 it is not read-only, is open-world, and is non-idempotent, so the description need not restate safety. It adds real value by disclosing the return payload {social, profile, badge} and clarifying that social is the cookie consumed by downstream Squads tools — critical since no output schema exists. It still omits auth/rate-limit behavior beyond the session param.

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 dense sentence front-loads the usage and endpoint, then the return shape. It earns most of its words, though packing the endpoint, return object, and cookie explanation into one line makes it slightly dense rather than optimally scannable.

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 login/cookie-establishment call with no output schema, the description supplies the return fields and the downstream role of the social cookie, which is the key information an agent needs. Minor gaps remain around what profile/badge contain and any sequencing failure modes, but it is largely 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 100%, and the schema already documents address, chainId, and session (including its origin in memeswap_session_open and non-storage guarantee). The description only reinforces the session bearer usage, adding no new parameter syntax or format detail, 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 (sign in) and resource (Squads) plus the exact endpoint (POST /api/social/login/wallet-session), so the agent knows precisely what the call does. It is also distinguishable from the related memeswap_session_open, which opens the wallet session this tool consumes.

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 to use it with a session bearer and positions the output (social cookie) as the prerequisite for 'every Squads tool', implying correct sequencing. However, it never states when NOT to use it or names the specific alternative flow to follow if login is unnecessary.

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 this is a non-read-only, non-destructive, non-idempotent, open-world mutation, so the safety profile is covered. The description adds one valuable trait – the outcome is a pending application that a leader later decides on, i.e., not an immediate membership grant – but omits auth requirements, failure modes, or rate limits.

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 that front-loads the action before the endpoint and payload detail. Every element is relevant, though the parenthetical request-body listing is slightly noisy since the schema already defines those fields.

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 3-parameter mutation with no output schema and annotations that cover only the safety profile, the description states the effect and outcome the agent gets back. It still leaves gaps on the auth prerequisite (social cookie) and what happens on duplicate/rejected applications, so it is adequate but not 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 coverage is 67%: 'social' and 'requestId' are already documented in the schema (including the idempotency-key semantics), while squadId carries no schema description. The description only restates the body fields {squadId, requestId} without adding format, sourcing, or constraint detail, so it does not compensate for the uncovered parameter.

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 ('apply to join a Squad') and even pins the endpoint and body shape, which is more than the name alone conveys. It does not explicitly distinguish itself from siblings like memeswap_squad_create or memeswap_squad_directory, but 'apply to join' is unambiguous enough that the agent can separate it from those.

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 leading 'Use to apply to join a Squad' gives implied context for invocation, but there is no statement of when not to use it, no alternative tool named for related goals (e.g., squad_directory for browsing before applying), and no prerequisite such as needing a social session first.

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 safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds one piece of behavior beyond that – it returns the new squad plus its invite link – but says nothing about failure modes, name/tag uniqueness enforcement, or rate limits.

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 dense sentence that front-loads the purpose, embeds the endpoint, and closes with the return value. No wasted clauses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description does compensate by stating what comes back (squad + invite link). However, it omits auth prerequisites and the consequences of duplicate names/tags, leaving the agent under-informed for a creation call.

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 social and requestId are documented in the schema. The description lists {name, tag, requestId} but supplies no meaning, format, or constraint for name/tag beyond what the schema's minLength/maxLength already conveys. Marginal value over the structured fields.

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 verb and resource ('found a Squad') and even cites the underlying endpoint, so an agent can tell it apart from memeswap_squad_apply, memeswap_squad_directory, and memeswap_squad_mine. It stops short of explicitly contrasting with those siblings, which keeps it out of the top band.

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?

'Use to found a Squad' gives an implied when-to-use but names no alternatives, no prerequisites (e.g. must be logged in via memeswap_social_login), and no conditions under which not to call it. Adequate minimum, with clear gaps.

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/open-world, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the response contains invite links and a nextCursor, which tells the agent this is a paginated listing.

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; the action, filter, endpoint, and return shape all fit compactly. Slightly dense but every clause carries information.

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 4-parameter paginated list tool with no output schema, the description covers the core action, one filter, and the paging signal. It omits what limit controls, how to request the next page, and auth expectations for the session cookie, 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 only 25% (only 'social' is documented). The description partially compensates by implying search semantics ('by name or tag') and cursor pagination (nextCursor), but limit, cursor bounds, and defaults remain undocumented in both places.

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 (browse/search) plus resource (squads) and scope (by name or tag), and even names the underlying endpoint. It is clearly distinguishable from siblings like memeswap_squad_mine (own squads) or memeswap_squad_create.

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?

"Use to browse or search squads" gives an implied usage context, but there is no explicit when-not guidance and no named alternative (e.g., memeswap_squad_mine for the caller's own squads). Adequate but leaves routing 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, non-destructive behavior, so the safety profile is covered. The description adds that it 'returns the server answer plus the invite link,' which is useful output context in the absence of an output schema, but it does not disclose auth failure modes or error behavior beyond what the schema states.

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 that includes the endpoint, purpose, and return contents with no padding. Minor awkwardness in 'the caller own squad' but structurally 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 simple single-parameter read tool with no output schema, the description supplies the missing return-value hint (server answer plus invite link) and cross-references the login tool via the schema. It is largely complete, though the return format remains loosely described.

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?

There is one parameter with 100% schema description coverage, so the schema already documents that 'social' is a session cookie from memeswap_social_login. The description adds nothing about the parameter, which is the expected baseline when the schema does 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 (read) and resource (caller's own squad, role, and membership), plus the underlying endpoint. This is clearly distinct from squad_directory (listing squads), squad_apply, or squad_create, though the description doesn't 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?

The phrase 'Use to read the caller own squad' implies the context (checking your own membership), but no explicit when-not or alternative tool is named. An agent must infer that squad_directory is the tool for browsing other squads.

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 read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral context by naming the returned fields (revision, showIdentity, showSize), which compensates for the absence of an output schema.

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 that efficiently covers purpose, endpoint, and return fields without any wasted 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?

For a simple read tool with full schema coverage and safety annotations, the description is complete enough. It compensates for the missing output schema by listing the key returned fields, and nothing essential for correct invocation is omitted.

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 100% and the single 'social' parameter is fully documented in the schema itself. The description adds no further meaning beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (read) and resource (caller squad privacy switches), plus the exact API endpoint. This clearly distinguishes it from the sibling memeswap_squad_set_privacy, which writes the same resource.

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 'Use to read the caller squad privacy switches', which implies the usage context. However, it does not explicitly state when to use this versus alternatives like memeswap_squad_set_privacy or memeswap_squad_mine, nor does it list any 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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation/non-idempotent profile is covered. The description usefully adds that expectedRevision drives optimistic concurrency and that the new revision is returned, but silent on what happens on a revision mismatch or the auth/session requirement (left to the schema).

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 the verb and resource first and the payload/return details parenthetically appended. No filler, though embedding the raw endpoint and JSON body is slightly noisy for an agent-facing description.

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 non-idempotent mutation tool with no output schema and 75% of parameters undocumented in the schema, the description omits conflict-handling behavior, whether both switches must be supplied together, and the session/auth requirement. Not enough for an agent to invoke it confidently beyond the happy path.

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 25% schema description coverage, the description must compensate, and it does not: it merely echoes showIdentity, showSize, and expectedRevision as payload keys without explaining what toggling identity or size visibility means or how the revision guard behaves. Only the 'social' cookie is documented, and that is in 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 verb ('change') and resource ('squad privacy switches') and even names the endpoint, so the agent knows exactly what operation this is. It does not, however, distinguish itself from the sibling memeswap_squad_privacy, which an agent could easily confuse with this write operation.

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?

'Use to change...' gives implied usage context but no explicit when-to-use guidance, no mention of the read counterpart (memeswap_squad_privacy), and no prerequisites such as needing a valid social session or an up-to-date revision. Usable but leaves routing 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, non-destructive, open-world, so the safety profile is covered. The description adds the key return shape (card plus a share link URL), but says nothing about auth/session requirements beyond the implicit 'caller own squad' and nothing about error cases.

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 no filler; the endpoint path is dense but arguably useful for debugging. Nothing redundant, though the parenthetical URL formatting is slightly awkward.

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 sensibly compensates by stating what is returned (the card plus the link). For a simple two-param read tool with rich annotations, this is nearly complete, missing only session/permission caveats.

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 50% (social is documented, squadId is bare), so the description carries extra weight here. It adds real semantics by constraining squadId to the caller's own squad, which tells the agent not to pass arbitrary squad IDs.

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 (get) and resource (invite/share card) scoped to the caller's own squad, plus the backing endpoint. It distinguishes itself from squad_directory/squad_mine by being explicitly about the caller's own squad, though it doesn't name a sibling by contrast.

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 — 'use to get the invite card for the caller own squad' tells the agent the situation, but there is no explicit when-to-use/when-not or named alternative (e.g., vs squad_mine or squad_directory) to route between.

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 declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds a genuine data-quality caveat ('Observations can be stale') that annotations cannot express, which is exactly the kind of context that helps an agent hedge its answer.

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, each earning its place: what it returns, when to use it, the alternative, and the freshness caveat. The scope is front-loaded before the sibling routing 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?

For a zero-param, no-output-schema read tool, this covers endpoint, purpose, routing and data freshness. The only thin spot is the shape of the returned market rows, but with no output schema and read-only semantics this is a minor 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 takes zero parameters, so there is nothing for the description to clarify beyond the schema; the 4 baseline applies. No parameter-related confusion is introduced.

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 a specific verb+resource ('Listed meme coin market rows from GET /api/tokens') and explicitly distinguishes itself from the sibling memeswap_token, which serves single-address lookups. An agent can route correctly 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?

States the trigger condition ('when the user asks for hot / new / trending memes to research before a buy') and the alternative ('Prefer memeswap_token for one address'). Both when-to-use and the disambiguating sibling rule are explicit.

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.