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 already declare readOnlyHint=true and openWorldHint=true, which correctly matches a builder that constructs but does not broadcast a transaction. Beyond that the description adds auth/env requirements per platform (BAGS_API_KEY, ZORA_ENABLED, etc.) and the fee-split economics, which the annotations cannot express.

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

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

Purpose is front-loaded in the first sentence, followed by a dense but information-bearing platform/fee breakdown. Each clause carries distinct facts, though the run-on platform enumeration is heavy and would read better as a short list.

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 builder with no output schema, the description never states what is returned (an unsigned tx payload?) nor directs the agent to the next step (crew_submit_signed). The handoff is central to correct use and is left implicit.

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 params, so the description must carry meaning — and it does for platform (per-venue semantics), crew[] sourcing, optInOnly default, and treasuryBps range. However, the majority of params (name, ticker, launcherPubkey, seats, mode, initialBuySol, imageBase64, etc.) get no explanation in either the schema or the description.

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 ('Create UNSIGNED launch transactions') and immediately names the concrete resources it operates on (pumpfun, bags, zora, etc.). The 'UNSIGNED' qualifier distinguishes it from submission siblings like crew_submit_signed without the agent needing to open 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 sourcing guidance — prefer explicit crew[] from crew_list_kols, with Autohire as fallback — and names the env-var prerequisites per platform. It does not explicitly say how this relates to crew_launch or crew_launch_dry_run, so the agent must infer the build-then-submit flow.

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 declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation that may reach external environments. The description adds useful context: no chain txs are sent, returns dryRunId + approvalUrl, and requires CREW_AGENT_API_KEY. However, it doesn't address whether the dry-run persists state, rate limits, or what happens on failure. It adds some value beyond 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?

Packed into three sentences with no waste, and the core behavior (dry-run variant, no chain txs) is front-loaded. The parenthetical intent=wire-fees and platform notes are terse but informative. Slightly dense for easy parsing, but efficient.

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

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

Given 22 parameters, 0 required, low schema coverage, and no output schema, the description covers the main modes and returns but omits guidance on most parameters and the nested crew structure. It's adequate but leaves gaps that could mislead an agent on required inputs for wire-fees (only mint is hinted via schema description).

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 36%, so the schema leaves many parameters undocumented. The description adds meaning for a few: platform defaults to pumpfun, bags/zora check enablement, intent launch/wire-fees, and implications for crew[] and Autohire. But many parameters (mode, seats, name, ticker, etc.) and the nested crew object fields lack description-level guidance, so it only partially compensates for the low schema coverage.

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 (dry-run) and resource (launch), plus a second mode (wire-fees intent). It distinguishes itself from siblings crew_launch and crew_wire_fees by name, making clear this is the no-chain-tx variant.

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 usage context: default is launch, intent=wire-fees for fee wiring, bags/zora check enablement without sending chain txs, prefer explicit crew[] from crew_list_kols, Autohire is fallback. It names sibling crew_list_kols as the source for crew, but doesn't explicitly say when to use this vs crew_launch (the real version).

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 the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), so the bar is lower; the description adds genuinely useful behavioral context by disclosing the expected transaction ordering per platform ('create then lock', '0xSplits then coin create'). It stops short of stating failure/irreversibility behavior for a destructive on-chain submission.

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 payload formats in dense telegraphic fragments. No wasted sentences, though the abbreviated syntax is slightly harder to parse than a full sentence would be.

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 submission tool with no output schema and 0% schema coverage, the definition covers input provenance and ordering but omits what happens on success/failure and whether any platform values lack supported orderings. Adequate but with real gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it does explain that 'signed' holds platform-specific payloads (Solana base64 vs EIP-1559 hex) and that 'platform' must match the builder. It still leaves array length bounds, per-item constraints, and the remaining enum values (clanker, vibevibe, sui) unexplained.

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

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

States a specific verb and resource ('Submit signed transactions') and explicitly ties the input to the sibling that produces it ('from crew_build_unsigned'). An agent can distinguish this submission step from the builder 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?

Clear context: use this after crew_build_unsigned, and 'Pass platform to match the builder' gives an explicit consistency rule. No explicit when-not or error-path guidance, but the workflow slot 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 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.