CREW / CrewPay

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds real context beyond them — that this is a 'Preview convenience' operation and 'Works keyless for previews' — clarifying that no key/commitment is needed, though the fee sentences are promotional rather than behavioral.

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 two opening sentences about creator fees and the 15% cut do not describe how to invoke the tool and consume space before the actual purpose. The remaining sentences are tight and front-load the sibling routing, but roughly 40% of the text is promotional 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 4-optional-param, no-output-schema, read-only tool, the description covers purpose, the fallback relationship to crew_list_kols, and keyless operation. The only gap is a clearer statement of what a 'candidate KOL pack' returns, but annotations cover the safety/mutation profile so 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?

Schema description coverage is 100%, so the schema already documents name, ticker, description, and seats, giving a baseline of 3. The description's 'name/ticker/vibe' phrasing loosely maps to those fields but adds no formats, defaults, or constraints beyond what the schema supplies.

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: 'match a token name/ticker/vibe to a candidate KOL pack,' which clearly distinguishes this from siblings like crew_list_kols and crew_search_kols. The opening sentences about creator fees and the 15% cut are tangential value-prop framing rather than tool purpose, which slightly dilutes an otherwise clear statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the preferred alternative ('Prefer explicit crew selection via crew_list_kols') and the condition that selects this tool instead ('Autohire is a fallback'). This is a direct when-to-use / when-not-to-use rule with the sibling named, leaving little 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?

Goes well past the annotations (readOnly/idempotent/non-destructive/openWorld) by disclosing that no server-side mint secret exists, that a mint keypair must be generated client-side, that Pump.fun fee-share may be one v0 tx or an ordered pair, that all steps must be signed in one signAllTransactions or Jito bundle, and which env keys each platform requires. The fee map and treasuryBps range further clarify behavior an agent could not infer.

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?

Almost every clause carries real information, but it is delivered as one dense run-on paragraph with the purpose buried after two sentences of fee economics. Reordering purpose first and grouping platform/param rules would improve scanability without losing content.

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 19-parameter, no-output-schema tool, the workflow (build unsigned -> sign all steps -> submit) and per-platform auth requirements are covered, which is the critical path. Gaps remain around several parameters (mode, seats, initialBuySol) and the shape/ordering of the returned transaction steps, which matters given the 'ordered pair' fallback.

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 26%, and the description compensates for the highest-value params: platform (all six enum members with venue/chain and env requirements), mintPubkey, crew[] sourcing, treasuryBps range, and optInOnly default. However mode, seats, initialBuySol, name, ticker, twitter, website, imageUrl, imageBase64, description, and launcherPubkey remain unexplained 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?

The description states a specific verb and resource ('Create UNSIGNED launch transactions'), and the 'UNSIGNED' qualifier implicitly separates it from signing/submitting siblings like crew_submit_signed and crew_launch. It never names those alternatives outright, and the economic preamble ('earns 15% of creator fees') delays the actual purpose to the third sentence.

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?

Strong contextual rules: mintPubkey is required for Pump.fun, every returned step must be signed together, the lock step must not be skipped, crew_wire_fees is repair-only, explicit crew[] from crew_list_kols is preferred over Autohire, and optInOnly defaults off. It stops short of explicitly stating when to choose this over crew_launch or crew_submit_signed, so the core routing decision is inferred 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?

Goes well beyond the annotations: discloses that the secret is returned once and must be stored as CREW_AGENT_API_KEY or sent as x-crew-api-key, that rate limits are 5/hour/IP, and that referral binding is permanent. Annotations only cover the generic safety profile (not idempotent, open-world, non-destructive).

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?

Front-loads the core action, then layers endpoint, referral, return-value, rate-limit and ordering details in dense clauses. Information-dense and mostly waste-free, though the em-dash-clause stacking is heavy for a short 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 tool with no output schema, zero required params, and annotations already covering safety, the description fully compensates by explaining the return value, secret storage, rate limits, and prerequisite ordering. Nothing needed to call it correctly 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?

Schema coverage is 100%, so baseline is 3; the description nonetheless adds the fee map (60/15/5/20) for referred launches and the CREWPAY_REFERRAL_CODE env fallback, which give referral_code meaning beyond its schema text. Label/model/agentName carry no extra semantic context.

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

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

States a specific verb and resource ('Mint a crew_ak_… agent API key'), names the endpoint, and describes the no-signup scope. No sibling tool does key provisioning, so the agent can distinguish it instantly.

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 routes usage: 'Use before autohire/launch when you have no key' names the sibling tools and the selecting condition (absence of a key). This is a prerequisite tool and the ordering guidance is unambiguous.

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 destructive/non-idempotent/open-world profile, so the description is not carrying that burden alone. It adds real value beyond them: the CREW_LAUNCHER_KEY-then-CREW_OPS_KEY credential fallback and the OnlinePumpSdk builder preference that avoids the CreatorFeesNotSwept failure. What it omits is any statement about irreversibility of the fee transfer, which matters given destructiveHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the action, then credentials, then the failure mode being avoided. Dense and free of filler, though parenthetical program names and SDK jargon slightly interrupt the flow.

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 destructive, non-idempotent write with no output schema, the description covers mechanism, credential resolution and a known on-chain failure mode. Remaining gaps (return shape, retry/irreversibility semantics) are modest against annotations that already flag destructiveness and non-idempotency.

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%, including the mint pattern/example and the FORBIDDEN markers on secretKey/privateKey/launcherKey, so the schema does the heavy lifting. The description only indirectly reinforces the key handling ("uses CREW_LAUNCHER_KEY if set") without adding format or syntax detail, matching the baseline 3.

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 ("Distribute accrued creator fees") and names the underlying instructions (sweep + distributeCreatorFeesV2), so an agent knows exactly what on-chain action occurs. However, it never contrasts itself with the neighbouring crew_wire_fees tool, which is the closest potential alternative for fee movement.

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?

"Permissionless on-chain" tells the agent anyone may call it, and the key-selection sentence gives invocation context. But there is no explicit when-to-use vs when-not guidance, and the sibling crew_wire_fees (also fee-related) is not mentioned as an alternative.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: this is a discovery endpoint yielding OpenAPI/doc links rather than performing an action, which is a useful behavioral distinction from its siblings.

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?

Compact two-sentence form with the discovery purpose front-loaded and the usage cue trailing. The domain list is keyword-dense but each item maps to a real area of the API, so little 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 zero-param, no-output-schema discovery tool, the description conveys both what it does and when to call it, hinting at the return content via 'OpenAPI links.' It could state more explicitly that the response is a discovery/API-map payload, but it is largely sufficient.

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 per the rubric; there is no parameter syntax or meaning for the description to clarify.

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 clear verb+resource ('Load CREW / CrewPay discovery') and enumerates the API surface it exposes (Autohire KOLs, coin launches, fee-shares, OpenAPI links), which distinguishes it from the action-oriented siblings like crew_launch or crew_autohire. The framing as a discovery/index endpoint is understandable, though 'load discovery' is slightly meta and doesn't fully pin down the response.

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 instructs 'Use this first when working on Solana meme coins, KOLs, or CrewPay,' which routes the agent ahead of the 15 sibling tools. It gives clear positive context but no exclusions or named alternatives for edge cases.

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 destructive/openWorld/non-idempotent, and the description adds real context on top: 15% agent fee, creator fees can be zero, default fee splits (60/15/25, or 60/15/5/20 with referral), Jito [create,lock] then v0+ALT construction, and required CREW_AGENT_API_KEY + CREW_LAUNCHER_KEY. The Jito/v0+ALT phrasing is terse jargon, keeping it just 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?

The content is dense and largely earns its place, but it reads as a stream of telegraphic fragments rather than a front-loaded summary, opening on the 15% fee rather than the core action. Structure could be tighter.

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 20-parameter MAINNET launch with no output schema, the description covers fees, auth keys, approval/optional dry-run, and non-custodial alternatives fairly completely. Minor gaps remain around the repair path and dry-run flow, but nothing an agent needs to invoke it 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?

Schema coverage is 65%, so most parameters are self-documented in the schema. The description only touches crew[] vs Autohire and mintPubkey at a high level, adding little syntax or constraint detail beyond what the schema already provides; a 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?

States a specific verb+resource ("Creates a Pump.fun coin and locks fee-shares at launch") and explicitly separates itself from siblings: crew_build_unsigned is non-custodial, crew_wire_fees is repair-only. An agent can distinguish this custodial MAINNET launch from the unsigned alternatives without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: prefer explicit crew[] sourced from crew_list_kols, Autohire is a fallback, and prefer non-custodial crew_build_unsigned + signAllTransactions + crew_submit_signed. It also flags crew_wire_fees as repair-only, covering when-not-to-use.

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), and the description adds real value beyond them: the required credential (CREW_AGENT_API_KEY), the return payload (dryRunId + approvalUrl), the enablement preconditions (BAGS_API_KEY / ZORA_ENABLED), and the caveat that creator fees can be zero. It does not describe what the dry run validates or the approval flow's next step, so not 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?

The content is dense and largely earns its place, but it is not front-loaded: the opening sentence is an economics aside ('launching agent earns 15% of creator fees... can be zero') while the actual purpose ('Dry-run a launch') appears only in the third sentence. An agent scanning the first line does not learn what the tool does.

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, and the description does cover the return identifiers and the auth requirement, which is good. But for a 22-parameter tool with 36% schema coverage and no required fields, large parts of the input surface remain unexplained, so the definition is adequate rather than 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 only 36% across 22 parameters, so the description must carry weight, and it does explain the highest-value ones (intent semantics, platform default and enablement, crew[] sourcing). However, most parameters (mode, seats, name, ticker, initialBuySol, the forbidden secret fields, etc.) receive no description-level explanation, leaving the coverage gap only partially closed.

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 action and scope: 'Dry-run a launch (default) or wire-fees (intent=wire-fees)' and clarifies it works 'without sending chain txs.' This distinguishes it from the actual-mutation siblings crew_launch and crew_wire_fees, though it never names those siblings explicitly, so the differentiation is implied 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?

It gives concrete routing guidance: 'Prefer explicit crew[] from crew_list_kols; Autohire is a fallback,' and states platform defaults and intent defaults. What is missing is any explicit when-to-use-this-vs-crew_launch framing (e.g., 'call this first to preview before the real launch'), so it stops short of full alternative routing.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely non-derivable behavioral context: manual selection is preferred over Autohire, and for Zora the agent should prefer registered evm_wallet / pass Base addresses. It omits return format and pagination behavior.

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: purpose first, then usage, then a domain-specific selection hint. Front-loaded and largely waste-free, though the Zora address hint could be more clearly separated from the launch-routing guidance.

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 list tool with full schema coverage and annotations carrying the safety profile, the description supplies sufficient selection and routing context. Since there is no output schema, it arguably should say more about what a profile record returns, which is the one remaining 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?

Schema description coverage is 100%, so q, limit, and offset are already documented in the schema. The description only echoes that q is an optional filter and adds no format or syntax detail beyond what the schema provides, matching the baseline 3 when the schema does the heavy lifting.

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/browse CREW KOL profiles') and adds scope ('optionally filtered by q'). An agent can distinguish it as the directory-browse tool, though it never explicitly names the closest sibling crew_search_kols, leaving a small ambiguity about list vs. search.

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 when-to-use context ('to select explicit crew wallets before launching on pumpfun, bags, or zora') and names an alternative with a condition ('Manual pick first; Autohire is a fallback'). It doesn't address when to prefer crew_search_kols over this list endpoint, so it stops one step 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context about return fields and differing behavior for operator env keys, but no pagination or rate-limit detail. With annotations carrying the heavy burden, a 3 is appropriate.

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 sentences with no filler; the core return semantics are front-loaded ahead of the usage guidance. Slightly dense but 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?

No output schema exists, so the description compensates by listing returned fields (mint, ticker, feeShareLocked, pumpUrl). For a simple one-param read tool whose safety profile is in annotations, this is largely complete, though it omits ordering/pagination behavior.

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%, so the single 'limit' parameter (1–100, example 20, default noted) is fully documented in the schema. The description adds no parameter-level detail. Baseline 3 applies 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 and resource ("Return launches") and names the key type and returned fields (mint, ticker, feeShareLocked, pumpUrl). It also distinguishes operator env keys from crew_ak_ keys. Sibling differentiation is present via the reference to crew_launch but not exhaustively against all 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?

"Use after crew_launch or to recover mint state across retries" gives clear context for when to invoke it. It does not state when-not to use it or name alternative listing tools, but the trigger conditions 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 destructiveHint=true and idempotentHint=false, so 'permanently lock' and 'one-shot' are consistent reinforcement rather than new information. The description does add meaningful context beyond the annotations, though: the CREW_LAUNCHER_KEY env-var prerequisite for auth. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the trigger condition, then the prerequisite. Every sentence 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?

For a destructive one-shot mutation with no output schema, the description covers the trigger and the auth prerequisite, and annotations cover the safety profile. It could say more about what the scan selects or what happens on repeated invocation, but nothing essential to calling it 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?

Schema coverage is only 57%, and the description explains none of the parameters (mint, mode, name, ticker). It does add one relevant fact by pointing at CREW_LAUNCHER_KEY in the env, which clarifies why the launcherKey/secretKey/privateKey fields are forbidden, but it does not compensate for the undocumented mode enum and name/ticker 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?

States a specific verb and resource: 'Scan top holders ∩ CREW KOL directory and permanently lock fee-shares'. Clear and concrete, and the '(one-shot)' qualifier further pins it down. It does not contrast itself against siblings like crew_launch or crew_wire_fees, 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 an explicit triggering condition: 'Use when launch used holderKol=true.' That is real routing guidance, not implied usage. It stops at 4 because it names no alternatives or when-not-to-use condition (e.g., what to do if holderKol was false).

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, openWorldHint=true, idempotentHint=false, so the safety profile is covered. The description adds real delivery semantics beyond that: opt-in gating, the @CrewPay_Bot channel, and the negative scoping note 'Never uses channel member counts.' It does not mention rate limits or delivery failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the action front-loaded and the constraints following immediately. Every clause earns its place, and the non-obvious negative constraint is included without padding.

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 three-parameter, all-optional notification tool with no output schema, the description covers what the agent must know: who gets messaged, through which bot, and the opt-in requirement. Only the success/failure semantics of a send remain unstated, which 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?

Schema description coverage is 100%, so the schema already explains mint, handles, and message, including the 'if mint is omitted' fallback. The description adds no parameter-level detail beyond that, which is the expected baseline when the schema carries the burden.

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: 'DM hired KOLs via @CrewPay_Bot.' An agent can tell this is an outbound notification to already-hired crew rather than a discovery or listing tool like crew_list_kols. It stops short of naming a sibling tool it should be preferred over, so it does not reach 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?

The description gives a concrete precondition ('Opt-in only: they must have linked Telegram, sent /start, and enabled alerts'), which tells the agent when the call will actually deliver. It never contrasts this tool against alternatives such as crew_list_kols or crew_autohire, so the when-not guidance is implicit rather than 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?

Beyond the readOnly/openWorld/idempotent annotations it adds high-value context: no API key required, no side effects on chain/board/keys, and interpretive guidance that empty buyback rows and empty arrays are expected rather than failures. The fee-map breakdown (60/15/25, referred 60/15/5/20) further clarifies what the tape reports.

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?

Front-loaded with the verb+resource, then cleanly sectioned into when-to-use, when-not-to-use, expected anomalies, fee map, return shape, and side effects. Dense but every clause (empty-array semantics, fee split, no-API-key) earns its place; only slightly verbose.

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 fully specifies the return object (ok, generatedAt, platform, stats, coins[], remits[], buybacks[]) and flags the non-error empty cases. Together with the usage and behavioral detail, nothing an agent needs to call and interpret this tool correctly 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?

Schema description coverage is 100% — the single `limit` parameter is fully documented with bounds, default, and example. The description never mentions `limit`, but the schema carries that burden, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Read the public CrewPay proof tape (GET /api/proof)') and enumerates the data it covers (fee-share-locked launches, creator-fee remits, buyback runs). It explicitly names the siblings it is not (crew_status, crew_list_launches, crew_crank_remits), so an agent can distinguish it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('after a launch or crew_crank_remits, to show public proof that remits posted, or to inspect tape totals') and when-not-to-use with reasons tied to specific sibling tools. Nothing 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety and side-effect behavior need no restating. The description adds the useful note that results come from an external profile directory (open-world), but says nothing about result ordering, matching semantics (substring vs exact), or truncation beyond what the schema's limit field implies.

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; the what-it-searches clause comes first and the routing preference second. 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 two-parameter read-only search with no output schema, the description plus annotations plus full schema coverage give an agent everything needed to invoke it correctly. It would be stronger if it hinted at the shape of returned profiles (since there is no output schema), but the gap is minor.

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% – both q ("Handle, pump username, or wallet substring") and limit ("Max results (default 20)") are fully documented in the schema. The description only echoes "handle or wallet" and even omits the pump-username form of q, so it adds no meaning beyond the schema. 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 ("Search") and resource ("CREW KOL / Pump profile directory") plus the lookup keys (handle or wallet), which separates it from the sibling crew_list_kols. It does not explicitly differentiate from crew_list_kols or crew_discover, 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 an explicit preference: manual selection from this directory is preferred and Autohire is only a fallback/convenience. That is real routing guidance, but it never says when to prefer the sibling crew_list_kols or crew_discover over this search, so it falls short of naming all alternatives.

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, destructiveHint=false and openWorldHint, covering the safety profile fully. The description adds domain behavior ('New launches lock fees at launch') that helps interpret the result, but says nothing about return contents or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero filler; the checked conditions come first and the workflow guidance follows. Every clause carries information an agent can act on.

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, idempotent check with no output schema, the description gives the agent enough to call it correctly and interpret the purpose. Only the shape of the returned status is left unstated, which is a minor gap given the simple contract.

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 'mint' parameter is thoroughly documented in the schema, including format and where to obtain it. The description adds no parameter detail beyond the schema, which is the expected baseline 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?

States a specific verb ('check') and resource ('CREW mint') and enumerates exactly what is being checked: fee-shares locked, Holder KOL open, board presence. This is well beyond a restatement of the name, though it does not by itself differentiate from every sibling in a 16-tool set.

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 positions the tool in a workflow: 'Use after submit, or before repair (crew_wire_fees) / lock / crank.' It names the sibling tools that precede or follow it, giving the agent a clear sequencing signal. It stops short of stating exclusions or when this check 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds genuinely new behavioral context: the atomicity requirement (sign create + fee-share lock together) and that fees lock at launch, which is exactly the irreversibility the destructiveHint implies. It stops short of describing failure/retry behavior or what a rejected submission returns.

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?

Front-loaded with the core action, then platform-specific clauses in parallel structure; nearly every clause carries operational weight. Density is high but the per-platform ordering details justify the length.

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 destructive, non-idempotent submission tool with no output schema, the description covers the critical operational prerequisites and sequencing an agent needs to avoid a bad launch. It omits return/error semantics and retry guidance, which is the remaining 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?

Schema coverage is 0%, so the description carries the burden. It compensates well by explaining the per-platform encoding of the signed array (Solana base64 for Bags, EIP-1559 hex for Zora) and the meaning of platform ('match the builder'). It does not explain the batch constraint (minItems 1 / maxItems 8) or the minLength 64 string format.

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 (submit) and resource (signed transactions) and explicitly names the sibling that produces its input, crew_build_unsigned. An agent can distinguish it from crew_build_unsigned and crew_launch 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?

Explicitly routes the agent: call after crew_build_unsigned, pass platform to match the builder, and the pump.fun case gives a clear prohibition ('do not submit create alone'). Per-platform ordering (fee-share then create) is spelled out, leaving nothing 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 flag destructive/non-idempotent/open-world, and the description adds substantial context beyond them: what on-chain state is written (fee-sharing PDA, shareholder addresses + bps split, admin revocation), that it is non-custodial, that the signer must be CREW_LAUNCHER_KEY locally, that secrets must never be passed as arguments, and that it errors if already locked or the key mismatches. This aligns with, rather than contradicts, idempotentHint=false.

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?

Long, but front-loaded with the verb+scope then organized into When-to-use / When-not-to-use / side-effects / returns / auth blocks so an agent can scan it. Dense yet largely every sentence carries a distinct constraint, with only minor redundancy in the secret-handling warnings.

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 destructive, multi-parameter, non-custodial transaction builder with no output schema, the description covers prerequisites, gating flow, side effects, return shape, and error conditions. Nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value: it explains that the crew array may be omitted to reuse the board crew, that shares follow fixed splits (60/15/25 or 60/15/5/20), and that dryRunId comes from crew_launch_dry_run after the human opens approvalUrl. It does not restate mint/ticker/name semantics 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 verb+resource ('Create and permanently lock Pump.fun fee-sharing shareholders on an existing mint') and immediately delimits scope ('on an existing mint'), which separates it from crew_launch/crew_build_unsigned that create new launches.

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?

Explicit 'When to use' (repair-only for older launches or crew_status showing no fee-sharing config), explicit 'When not to use' (new launch, Holder-KOL opens, fee distribution), and names the alternatives (crew_lock_holder_kol, crew_crank_remits, crew_launch_dry_run). It even flags the hosted-MCP limitation that makes the tool unusable there.

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