CREW / CrewPay

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context by calling this a 'preview' and noting it 'works keyless,' implying no auth requirement. However, it says nothing about what the preview actually returns (candidate pack shape), whether the match is deterministic, or how the preview relates to an eventual hire/launch.

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 the purpose, then the routing rule, then the auth note. No filler; every sentence carries distinct 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 preview tool with no output schema, the description should convey what the agent gets back and what to do next, but it stops at 'candidate KOL pack.' With 4 optional params and no required fields, an agent knows how to call it but not how to interpret or act on the result.

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% with clear constraints (name 2–32, ticker 2–13, seats 1–8 default 5, description ≤204), so the schema does the heavy lifting. The description only echoes the same three inputs as 'name/ticker/vibe' and adds no format, synergy, or prioritization semantics 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 and resource ('match a token name/ticker/vibe to a candidate KOL pack') and scopes it as a preview. It also names the sibling it is not, so an agent can distinguish it from crew_list_kols 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: 'Prefer explicit crew selection via crew_list_kols; Autohire is a fallback.' This gives both the preferred alternative and the condition under which this tool is chosen, which is exactly the when/when-not guidance an agent needs.

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 declare readOnlyHint/openWorldHint, so the description carries most of the behavioral load and does so well: it discloses chain/encoding per platform (Solana v0 messages, Base EIP-1559), required environment secrets, the fee split (60/15/25, 5% referrer) and the treasuryBps 2000–3000 constraint. It does not say what the returned unsigned transaction looks like or that it must be signed and submitted via a sibling, which is the main remaining behavioral 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?

Front-loaded with the verb and the word that matters most (UNSIGNED), then telegraphed platform facts, crew guidance, and the fee map — dense but every clause carries information. No filler or restatement of the title. Slightly list-like, which is appropriate for a 19-parameter 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 high-complexity, multi-chain, 19-parameter mutating-shape tool with no output schema and 21% schema coverage, the description covers the highest-risk areas (venue requirements, crew sourcing, fee economics) but leaves many parameters and the transaction-consumption workflow unexplained. It is adequate to attempt a call, not complete enough to prevent parameter misuse.

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 21% across 19 parameters, so the description must compensate, and it only partially does: it explains platform defaults, optInOnly's default, treasuryBps's effective range, and the crew[] source preference. Roughly a dozen parameters (mode, seats, initialBuySol, mintPubkey, description, imageBase64, social fields) get no semantic clarification beyond their names and constraints.

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 first sentence gives a specific verb+resource ('Create UNSIGNED launch transactions'), and 'UNSIGNED' cleanly separates it from the signed/submitting siblings (crew_submit_signed, crew_launch). It also names siblings it interacts with (crew_list_kols, Autohire) rather than leaving the crew-selection path implicit. It stops short of explicitly stating the build-then-sign-then-submit workflow, so a 5 isn't earned.

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 conditional guidance: platform-specific prerequisites (BAGS_API_KEY for bags, ZORA_ENABLED for zora), default venue (pumpfun), and an explicit preference order ('Prefer explicit crew[] from crew_list_kols; Autohire is fallback'). What is missing is any guidance on when to call this instead of the sibling crew_launch or crew_launch_dry_run. Nothing is misleading, but the when-not case is absent.

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 (readOnlyHint=false, openWorldHint=true) by disclosing rate limits (5/hour/IP), the default 5 launches/hour quota, that the secret is returned only once, how to persist it, and the permanent referral binding with its fee map. These are exactly the operational traits an agent cannot infer from 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?

Front-loaded with the core action and endpoint, then constraint details. It is dense and clause-heavy, but nearly every clause carries distinct information; only minor tightening is possible.

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, yet the description covers the return value (secret returned once) and how to use it, along with quota and rate-limit behavior. An agent has everything needed 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 100%, so the parameter mechanics are already documented (baseline 3). The description adds real meaning on top: the referral_code's env fallback and the fee-map consequence of binding a referrer, which the schema only hints at.

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 ("Mint") and resource ("crew_ak_… agent API key") with the concrete endpoint. It also carves out its niche by telling the agent to use it before autohire/launch, distinguishing it from 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?

Explicit when-to-use: "Use before autohire/launch when you have no key." This names the alternative tools and the condition (no existing key) that selects this one, 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 declare destructiveHint=true and openWorldHint=true, so the mutation risk is known. The description adds valuable context beyond annotations: key selection behavior (CREW_LAUNCHER_KEY if set, else server CREW_OPS_KEY), the permissionless nature, the CreatorFeesNotSwept failure mode and mitigation via OnlinePumpSdk builder. This is rich behavioral context not present in 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?

Three compact sentences with zero waste. Purpose is front-loaded, followed by runtime behavior, then a specific failure-mode mitigation. Every sentence 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 mutation tool with no output schema, the description covers purpose, key selection, permissionless execution, and a key failure mode. What's missing is return-value/pagination behavior and any idempotency or rate-limit considerations, but the core is well covered.

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 75%, so the schema already documents most parameters including the FORBIDDEN constraints on secretKey/privateKey/launcherKey. The description doesn't add parameter-level syntax or format details beyond what the schema provides. Baseline 3 is appropriate 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+resource: 'Distribute accrued creator fees', with underlying operations (sweep + distributeCreatorFeesV2) named. It distinguishes the resource from siblings like crew_wire_fees or crew_launch, though it doesn't explicitly name an 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?

Says 'Permissionless on-chain' which implies it can be called freely, but provides no explicit when-to-use vs when-not-to-use guidance, no prerequisites, and no routing to an alternative tool. Usage context is implied but 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and remote-access profile is covered. The description is consistent with them ('Load ... discovery ... OpenAPI links' implies an outbound fetch) but adds no new behavioral detail such as caching, rate limits, or whether it returns live data versus static pointers.

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: content scope first, then the when-to-use trigger. No filler, though 'for crypto agents' is mildly redundant framing that doesn't add routing value.

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

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

With no output schema, the description must carry return-value semantics, and it only gestures at content ('OpenAPI links') without saying what the agent actually receives or how to proceed to the sibling tools. Adequate as a signpost, thin as a specification.

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; per the baseline for 0-param tools this sits at 4. The description correctly implies a no-argument call.

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 (load discovery) plus the domain it covers (Autohire KOLs, Pump.fun launches, fee-shares, OpenAPI links), which is more concrete than the title's restatement. It reads clearly as an entry-point/index tool distinct from the operational siblings, though it never says what form the 'discovery' takes.

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 an explicit trigger: 'Use this first when working on Solana meme coins, KOLs, or CrewPay.' The ordering instruction is meaningful with 15 siblings, but no sibling is named as an alternative and no when-not condition is given.

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 openWorldHint=true, so the description's job is to add specifics — and it does: MAINNET, the 60/15/25 default split vs. 60/15/5/20 with referral, required env keys, optional approval, and the 'Check feeShareLocked' caveat. It stops short of stating that a launch is irreversible or what happens on partial failure, but the added context is well 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?

Six short clauses, zero filler, and the MAINNET warning plus crew[] preference are front-loaded ahead of the key/approval details. The telegraphic semicolon-heavy style is efficient, though slightly compressed for a 20-parameter mainnet mutation.

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 mainnet launch with 20 params and no output schema, the description covers the critical operational facts: network, fee-share defaults, key requirements, approval path, and the feeShareLocked follow-up. Return values are not described, but the absence of an output schema means the agent can't rely on a structured contract for them, leaving 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?

With 20 parameters at 65% schema coverage, the schema carries most of the load and the description only supplements it, notably explaining crew[] as the preferred source and the fee-share arithmetic. It adds nothing about initialBuySol, mode, seats, idempotencyKey, or the forbidden-secret parameters that the schema already flags. Adequate but not compensating 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 ('Creates a Pump.fun coin with on-chain fee-shares') and immediately flags MAINNET, so the agent knows this is a real-value launch rather than a dry run. It also routes between the two crew-sourcing paths (explicit crew[] vs. Autohire), which cleanly separates it from crew_autohire and crew_launch_dry_run.

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 preference guidance: 'Prefer explicit crew[] (from crew_list_kols). Autohire is a fallback convenience,' which names the source tool and the alternative path. It also states prerequisites (CREW_AGENT_API_KEY + CREW_LAUNCHER_KEY) and that approval is optional, though it never tells the agent to run crew_launch_dry_run first or when to prefer crew_build_unsigned/crew_submit_signed.

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 readOnlyHint/openWorldHint, but the description adds substantial context beyond them: it confirms no chain txs are sent, that bags/zora gate on BAGS_API_KEY/ZORA_ENABLED, that CREW_AGENT_API_KEY is required, and that it returns dryRunId + approvalUrl. This is exactly the side-effect and auth detail an agent needs and does not contradict 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?

Four tight sentences, front-loaded with the core purpose and mode split, then platform behavior, crew guidance, and return/auth facts. Each sentence carries distinct 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 22-param tool with no output schema, the description supplies the essential behavioral envelope: side-effect scope, auth, platform enablement, and return values. The main residual gap is the semantics of the many loosely-documented launch/content parameters, which the description does not reach.

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 22 parameters at only 36% schema description coverage, the description must carry weight, and it does explain intent (launch/wire-fees), the platform default (pumpfun) and crew[] sourcing. However, the large majority of params (mode, seats, ticker, name, socials, image fields, agentModel, etc.) get no semantic explanation in either place, so it only partially compensates.

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 (dry-run a CREW launch) and immediately distinguishes its two modes (launch vs wire-fees). It also differentiates from siblings by naming crew_list_kols as the preferred crew source and Autohire as a fallback, so an agent can tell it apart from crew_launch and crew_autohire 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 guidance: 'Prefer explicit crew[] from crew_list_kols; Autohire is a fallback,' which names the alternative and the condition that selects it. It also flags the auth prerequisite (CREW_AGENT_API_KEY). It stops short of stating when to prefer this dry-run over the real crew_launch, so it is strong but not exhaustive.

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 and openWorldHint=true, so safety is covered. The description adds domain-specific behavior: it should be used to select explicit crew wallets, with a Zora preference for registered evm_wallet / Base addresses, though it does not describe return format or 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 sentences, front-loaded with the core purpose, followed by usage guidance and a special case. Every sentence earns its place with no redundancy.

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 directory listing with three optional parameters and no output schema, the description covers purpose, usage workflow, and a Zora-specific address preference. It is incomplete mainly in not differentiating from crew_search_kols and not noting pagination or result shape, though the schema covers the pagination parameters.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only echoes the q filter ('optionally filtered by q') and adds no new syntax or meaning beyond what the schema provides, making the baseline 3 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 verb and resource: 'List/browse CREW KOL profiles (optionally filtered by q).' It also clarifies the selection goal ('select explicit crew wallets before launching') and distinguishes from the Autohire fallback, so an agent can identify the tool's scope 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?

It gives clear context for when to use: before launching on pumpfun, bags, or zora, with manual pick first and Autohire as a fallback. However, it does not explicitly compare with the sibling crew_search_kols, so sibling differentiation for search versus listing is left to the name.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds real behavior beyond them: the returned payload depends on the calling key type (crew_ak_ vs operator env keys seeing recent board launches). It does not disclose default result count or ordering, which is the remaining 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?

Three tight sentences, each earning its place: what is returned, how scope varies by key, and when to call it. The verb and resource are front-loaded 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 output schema, the inline enumeration of returned fields is genuinely useful, and the key-type scope distinction fills an important gap. Only the limit parameter's behavior is left unexplained, which keeps it below a 5.

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

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

There is one parameter (limit, bounded 1-100) with 0% schema description coverage, and the description never mentions it, so default value and ordering semantics are undocumented in both places. With a low coverage single param, the description was expected to compensate and 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+resource ('Return launches attributed to your crew_ak_… key') and names the returned fields (mint, ticker, feeShareLocked, pumpUrl). It also distinguishes two returned scopes (crew key vs operator env keys), so an agent can tell how it differs from crew_launch and from other crew_* reads.

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

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

Explicitly gives the trigger: 'Use after crew_launch or to recover mint state across retries.' This tells the agent when to reach for it rather than crew_status. It stops short of any when-not or naming an alternative read tool.

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 openWorldHint=true; the description goes beyond them by spelling out that the lock is permanent and one-shot, and that CREW_LAUNCHER_KEY must live in the MCP env. It does not disclose failure behavior or what happens to holders not in the KOL directory.

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 ordered by what it does, when to use it, then the auth precondition. No filler and nothing buried.

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

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

The high-risk facts (destructive, permanent, one-shot, env-sourced key) are covered and there is no output schema to explain. However, with 7 parameters and no param guidance, an agent still cannot tell what mode/name/ticker do or what a failed lock returns.

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?

Only 43% of the 7 parameters have schema descriptions, and the description adds no parameter meaning at all — mode's enum values (agent/split/buyback/raid), name, and ticker are undefined anywhere. The schema's mint pattern and FORBIDDEN-field notes do the remaining 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: 'Scan top holders ∩ CREW KOL directory and permanently lock fee-shares.' The intersection scope and the one-shot permanence distinguish it from siblings like crew_wire_fees, though no sibling is named explicitly.

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 activation condition, 'Use when launch used holderKol=true,' which is more than most siblings offer. It stops short of stating when NOT to use it or naming an alternative tool for other launch configurations.

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 declare readOnlyHint=false and openWorldHint=true; the description adds genuinely useful context on top of that — the delivery channel, the mandatory opt-in gate, and the negative constraint about channel member counts. It still omits behavior when a target is not opted in (silent skip vs. error) and any rate or volume 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?

Three tight sentences with the core action front-loaded and no wasted phrasing. The closing constraint sentence is short and load-bearing rather than 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 side-effecting outbound-notification tool with no output schema, the description leaves return behavior and partial-failure handling unexplained (e.g., what the agent gets back per recipient, whether delivery is batched). The opt-in and channel constraints give it a workable floor, but the mutation outcome is under-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?

Schema description coverage is 100% and all three parameters carry their own descriptions, including the mint-vs-handles alternative and the 500-char message limit. The description adds nothing about parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ("DM hired KOLs via @CrewPay_Bot"), so an agent immediately knows this sends outbound messages rather than managing launches or hires. It also draws a boundary by excluding channel-member-count logic, though it never names a sibling tool the agent might confuse it with.

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?

Clear preconditions are stated: recipients must have linked Telegram, sent /start, and enabled alerts, which tells the agent this cannot be used for arbitrary outreach. It does not say when in a workflow to call it (e.g., after crew_autohire or crew_launch) or what to do if no one is opted in.

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 and openWorldHint=true, so safety is covered; the description goes further with domain behavior: 25% fee-share lock (20% when the launching agent is referred) and the explicit warning that the buyback cron is not live, so empty buyback rows should not be read as failed fee-shares. That interpretation guidance is genuinely additive; only pagination behavior for the limit is unaddressed.

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, front-loaded with what is loaded, followed by the caveats. Dense but every clause carries real meaning; no filler or repetition of 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, the description does explain the return shape (launches, remit totals, buyback runs) and adds a key interpretation caveat, which is good. However, it omits any treatment of the limit parameter and any scoping/pagination context, leaving a gap for an agent that needs to page 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 single parameter (limit, 1-100) has 0% schema description coverage, so the description carries the full burden, yet it never mentions the parameter or its effect on result size. With coverage below 50% the description should 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 (Load) and resource (public proof tape) and enumerates the content: launches, remit totals, buyback runs. An agent knows what it retrieves, though it never distinguishes itself explicitly from close siblings like crew_list_launches or crew_status.

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 only implied: a read-only 'proof tape' for accountability data. There is no statement of when to prefer this over crew_list_launches, crew_status, or crew_discover, and no prerequisites are given, so the agent must infer the 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 readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, externally-scoped read. The description adds little beyond that — no note on result shape, pagination, or whether matching is substring vs exact. With the safety profile pre-covered, this is adequate but thin.

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 core action front-loaded and the selection guidance second. No filler, though the second sentence assumes the reader already knows what Autohire is.

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 two-parameter read-only search this covers the essentials, but with no output schema the description never hints at what a match looks like (profile handle, wallet, ids), which an agent needs to chain into crew_lock_holder_kol or crew_notify_hired_crew.

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 both parameters are documented in-schema, so the baseline is 3. The description's 'by handle or wallet' slightly enriches the q parameter's meaning, but adds no format, substring, or case-sensitivity detail 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 (Search) and resource (CREW KOL / Pump profile directory), plus the matching key (handle or wallet). It is clearer than most siblings, though it does not explicitly distinguish itself from crew_discover or crew_list_kols, which sound like adjacent directory operations.

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 an alternative and the condition that favors it: 'Prefer manual crew selection from this directory; Autohire is a fallback/convenience.' This routes the agent away from crew_autohire when deliberate selection is wanted, but gives no guidance on when this tool is inappropriate or how it relates to the other search/list siblings.

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 and openWorldHint=true, so safety is covered. The description adds genuine behavioral content beyond them: the three state dimensions the check reports and the precondition that a launch returns HTTP 202 before this is meaningful. It does not describe the response shape or failure modes, which keeps it out of 5 territory.

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 front-loaded before the usage note, with no filler or restatement of the title. Every clause carries information the agent needs.

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

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

For a single-parameter read-only probe with no output schema, the description covers what the agent needs to decide when to call it. A brief indication of what the status response returns (or how a not-yet-launched mint is reported) would close 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 description coverage is 100% and the single parameter (mint, with a base58 pattern and length bounds) is fully documented in the schema. The description only implies the mint is the subject of the check, adding nothing about format or provenance, 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 (Check) and resource (CREW mint) and enumerates exactly what is inspected: fee-shares locked, Holder KOL open, board presence. That is far more precise than a tautology, but it never names a sibling tool, so separation from the rest of the crew_* family relies on the usage sentence rather than the purpose 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?

Gives concrete lifecycle positioning: "Use after launch (HTTP 202) or before wire/lock/crank," which maps onto siblings crew_wire_fees, crew_lock_holder_kol and crew_crank_remits. There is no explicit when-not condition, but the sequencing guidance is clear enough for an agent to place the call correctly.

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 openWorldHint=true, so the irreversible on-chain broadcast profile is partly conveyed structurally. The description adds real value by disclosing per-platform encoding formats and required transaction ordering (create then lock, 0xSplits then coin create), but says nothing about idempotency, failure/partial-submission behavior, or confirmation semantics.

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 dense sentences with no filler; the provenance constraint is front-loaded before the platform-specific encoding and ordering details.

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

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

There is no output schema, yet the description never indicates what a successful submission returns (signatures, tx hashes, per-item status) or how partial failures surface. For a destructive, open-world tool with 0% schema description coverage, the flow and format guidance is solid but the response contract 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 0%, so the description must compensate and largely does: it explains that 'signed' originates from crew_build_unsigned and that entries are platform-encoded (base64 vs 0x hex), and that 'platform' must match the builder used. It only implies rather than states the significance of array ordering and the 1-8 item bound.

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

Clearly positions the tool as the second half of a two-step flow originating in crew_build_unsigned, and adds the operative condition 'Pass platform to match the builder.' It stops short of stating when not to use it or what happens on mismatch/failure.

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 and destructiveHint=true, so the safety profile is carried structurally. The description adds genuinely useful non-annotation context (requires CREW_LAUNCHER_KEY in MCP env, optional per-key approval, dryRunId requirement). It does not, however, disclose what 'repair' actually overwrites, which is the key behavioral question for a destructive tool.

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

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

Three short sentences front-load the core action, with approval details following. Dense jargon ('intent=wire-fees', 'approvalUrl') but no wasted filler, so 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?

For a destructive, open-world mutation with no output schema and only 56% parameter coverage, the description covers the auth and approval mechanics well but leaves the overlap/replacement semantics and unexplained params (mode, name, ticker) unaddressed.

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 56%, so several parameters (crew, mode, name, ticker) are only partially documented. The description echoes dryRunId usage and ties it to the approval workflow, but adds little meaning for the remaining params beyond what the schema already states.

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 gives a specific verb-plus-resource action ('Create + lock fee-sharing') and scopes it to 'an existing mint', which usefully separates it from launch-time siblings like crew_launch. However, it never names an alternative tool, so an agent still has to infer the boundary against crew_repair-style or launch workflows on its own.

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 supplies real workflow context — 'Approval is optional' and the per-key human-approval path with dryRunId from intent=wire-fees — which implies when the approval branch applies. But there is no explicit when-to-use-this-vs-siblings guidance and no exclusions, leaving the routing decision mostly to inference.

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