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

With no annotations at all, the description does carry useful behavioral detail: files are written to CTFD_FILES_DIR/<slug>/ and the response includes dir, saved files and connection_info. However it omits key side-effect semantics an agent needs for a write-to-disk operation, such as overwrite behavior, auth requirements, or what happens when a challenge has no hosted files.

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, front-loaded with the action and destination, then the return payload. No filler or 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 low-complexity, single-parameter tool with an output schema covering the return shape, the description supplies purpose, destination and accepted identifier forms. Remaining gaps (overwrite/no-files behavior, permissions) are minor given the tool's simplicity and the presence of an output schema.

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

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

Schema coverage is 0% and the single 'challenge' parameter is undocumented, but the description compensates partially by stating it accepts an id or a name. It does not clarify whether the name is the display name or slug, nor how collisions are resolved.

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 (Download) plus the exact resource (a challenge's CTFd-hosted files) and the destination path, which distinguishes it from siblings like ctf_show and ctf_list that read metadata rather than persist files.

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

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

The description never states when to use this versus ctf_show or fetch_url, nor any prerequisite (e.g. being registered for the challenge, challenge having files). Usage is only inferable from the purpose sentence.

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

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

With no annotations, the description carries the full burden, and it does disclose the key side effect: unlock=True spends points, while the default is read-only listing. It stops short of stating whether the spend is irreversible, whether already-unlocked hints are re-charged, or what authorization the caller needs.

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 clauses, front-loaded with the primary action and the identifier format, then the mode flag and its cost. No filler; every phrase carries information.

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

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

An output schema exists, so return values need not be explained, and both parameters are covered. What remains thin is operational context around the point-spending mutation (reversibility, re-charge behavior, permission requirements), which a mutating tool with no annotations ideally would state.

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 it does: 'challenge' is documented as accepting an id or name, and 'unlock' is given both its boolean meaning and its cost consequence plus default behavior. That is meaningful semantics beyond the bare schema titles.

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 ('List hints for a challenge') and clarifies the accepted identifier forms (id or name). It is clearly distinct from the ctf_* siblings (list, show, submit, scoreboard), though it does not explicitly contrast itself with them.

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

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

The description does distinguish two operating modes: the default (list titles/costs) versus unlock=True (reveal content at a point cost), which is useful decision context. However, it never says when to reach for this tool versus ctf_show/ctf_list, nor any prerequisites (e.g., must the challenge be solved or the team have enough points).

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the sort order ('easy-first (most solves)') and the meaning of the unsolved flag, but says nothing about pagination, what limit=0 means, or whether any auth/session is required for the CTF API.

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?

Extremely compact and front-loaded: the core purpose leads, followed by filter and ordering semantics. The semicolon style borders on telegraphic, but every clause conveys 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?

An output schema exists, so enumerating return fields (id, name, category, value, solves, solved) is redundant. For a 4-param tool with zero schema documentation, the description should at minimum define limit's behavior, which it omits.

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 for all 4 params. It explains category/name filtering and the unsolved flag, but leaves limit (default 0) completely undefined and never clarifies the interaction between filters.

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?

Starts with a specific verb+resource ('List challenges'), which clearly separates it from siblings like ctf_show (single challenge) and ctf_solved. It does not explicitly name which sibling to use instead, so it stops short of a 5.

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

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

The filtering hints ('unsolved=True hides solved; filter by category/name') imply when the flags are useful, but there is no explicit guidance on when to use ctf_list versus ctf_solved or ctf_show, and no stated exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the CTFd mode is auto-detected (so no mode parameter is needed), but says nothing about authentication requirements, whether the call is read-only, or failure behavior when unauthenticated.

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

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

A single front-loaded sentence with no filler; the resource and the mode behavior both land immediately.

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

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

An output schema exists, so return-value documentation is unnecessary, and with zero parameters the call surface is trivial. The only shortfall is the absence of any note about authentication or error conditions, which matters slightly given no annotations.

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

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

Zero parameters, so the schema baseline is 4. The description adds real value by explaining that mode is auto-detected rather than supplied, which preempts an agent trying to pass a mode argument that does not exist.

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

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

The description names a specific resource (your own team in team mode or user in user mode) and enumerates the returned fields (name, score, place). 'Your own' implicitly separates it from ctf_scoreboard, which covers the whole field, so an agent can route 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?

Usage is implied rather than stated: the mention of team mode vs user mode and auto-detection tells the agent it need not pass a mode argument. However, there is no explicit when-to-use framing or pointer to alternatives such as ctf_scoreboard for other players' standings.

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

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

With no annotations, the description carries the full behavioral burden. 'Live' hints at real-time data, but nothing is said about auth requirements, whether a CTF must be active, sorting direction ties, or refresh semantics for a mutation-free read.

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

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

A single compact sentence with zero filler, front-loading the resource and the key constraint (top N, by score).

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?

An output schema exists, so return-value detail is unnecessary, and the one-liner covers the core operation. However, for a tool with zero annotation coverage it omits auth/active-event context and any note on how results are ordered or limited.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: 'top N teams/users by score' explains that the 'top' parameter is a count of entries and that results are ordered by score. It does not state the default of 10 or valid ranges, so it falls short of a 5.

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

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

States a specific resource (scoreboard) and scope (top N teams/users by score), which clearly separates it from siblings like ctf_solved, ctf_show, or ctf_list. It lacks an explicit 'not for X' clause, but the verb+resource is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives among the many ctf_* siblings. The use case (checking standings) is only implied by the name and description.

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?

No annotations are provided, so the description carries the burden. Listing the returned fields (connection_info, files, hints, solves) gives useful behavioral insight, but it says nothing about error handling for an unknown challenge/name or any access constraints. Adequate but not rich.

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

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

One tight sentence, front-loaded with purpose followed by the returned fields. No filler, no repetition of the name or title.

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

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

For a single-parameter read tool with an output schema present, the description is nearly complete; field explanations are somewhat redundant given the output schema. Only the missing error/edge-case behavior leaves a small 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 0% and the single required parameter 'challenge' is undocumented in the schema. The description compensates by clarifying that either an id or a name is accepted, which is meaningful beyond the bare string type.

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

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

States a clear verb (show/retrieve) and resource (one challenge), scoped to a single entity which distinguishes it from ctf_list. It also enumerates the returned fields, but never names the sibling tools it should be contrasted 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?

Usage is implied by 'one challenge' versus the list-oriented siblings, but there is no explicit when-to-use, when-not-to-use, or alternative recommendation. An agent must infer that ctf_list should be used first to find identifiers.

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

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

With no annotations, the description carries the full burden, but it does convey that this is a non-mutating, user-scoped read ('already solved by you / your team'). It says nothing about authentication requirements, pagination, or whether results are ordered, which for a zero-parameter list tool is a minor but real gap.

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

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

A single sentence with no filler, front-loaded with the action and resource. Every word earns its place and nothing is 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?

An output schema exists, so return values need no explanation, and with zero parameters the surface is small. The description is essentially complete, though it could have named the sibling to resolve the ctf_list vs ctf_solved ambiguity.

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 are no parameter semantics to explain; the baseline of 4 applies. Nothing in the description conflicts with the empty 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 (list) and resource (challenge names already solved), with a scope qualifier ('by you / your team') that separates it from the sibling ctf_list, which presumably enumerates all challenges. It never names that sibling explicitly, so an agent must infer the boundary.

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

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

Usage is only implied: the phrasing suggests checking progress or avoiding re-solving, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as ctf_list or ctf_me. For a trivial read tool this is adequate but leaves routing to inference.

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

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

With no annotations, the description carries the full burden, and it usefully discloses the operational outcome states — ratelimited, paused, already_solved — which tell the agent how to react. It omits auth requirements and re-submission semantics, keeping it from a 5.

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

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

Two tight, front-loaded sentences with no waste; the purpose leads and the return contract follows.

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-param submit tool it is largely adequate, and an output schema exists to carry return details (making the inline return note partly redundant). It lacks any guidance on failure recovery or auth, leaving minor gaps.

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

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

Schema coverage is 0% with 2 required params, so the description must compensate. It clarifies that 'challenge' accepts an id or name, which is genuinely useful, but says nothing about the 'flag' parameter's expected format.

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

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

States a specific verb+resource ('Submit a flag for a challenge'), which is unambiguous and clearly distinct from siblings like ctf_solved or ctf_list. It does not explicitly name alternatives, so it falls short of a 5.

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

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

The description says what the tool does but never states when to use it versus siblings (e.g., use ctf_solved to check progress first), nor any prerequisites or exclusions. Usage is only implied by the verb.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the write side effect and its destination path (CTFD_FILES_DIR/_fetched/), but says nothing about network reach, size/time limits, authentication, or failure behavior for an arbitrary-URL fetcher.

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

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

Three short sentences, front-loaded with the verb and resource, and each sentence adds a distinct fact (action, return payload, intended scope). 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 single-parameter fetch tool, the description covers purpose, destination, and scope, and an output schema exists so return values need no restating. Nothing essential for a correct invocation is missing.

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

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

One parameter at 0% schema description coverage, so the schema documents only the type. The description partially compensates by giving a concrete URL example format, but adds no constraints on scheme, allowed hosts, or encoding.

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

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

States a specific verb (GET) and resource (any URL), plus the concrete side effect of saving to CTFD_FILES_DIR/_fetched/. The phrase 'For services that serve files off-CTFd' implicitly carves it away from ctf_download, but it never names that sibling, so differentiation is inferred rather than explicit.

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 a clear context for use ('services that serve files off-CTFd') and an example of the kind of URL it targets. It stops short of naming the alternative (ctf_download) or stating when NOT to use this tool, so it lands at clear-context-without-exclusions.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the error behavior ('Returns {error} if the CTF has no ctfd-whale plugin') and the team-scoped, live-only nature of the listing, but says nothing about permissions, auth requirements, or how the live/remaining-seconds state is computed.

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, front-loaded with the purpose and scope, followed by the failure condition. Every clause carries information and nothing is padded.

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

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

For a single zero-arg listing tool with an output schema present, the description covers scope, the fields returned, and the plugin-absent error case. Auth/permission prerequisites are the only notable omission, which is minor at this complexity.

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 no parameter semantics for the description to clarify. The baseline of 4 applies given an empty argument object.

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

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

States a specific verb and resource ('List your team's LIVE dynamic instances') and enumerates what it returns (challenge, category, access host, remaining seconds). It is clearly distinguishable from the whale_start/whale_stop siblings, which create and destroy rather than list.

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

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

The 'LIVE dynamic instances' framing gives clear context for when this tool applies, and the plugin-prefix tag ties it to the ctfd-whale workflow. It stops short of explicitly naming whale_start/whale_stop as the alternatives for creating or tearing down instances, so no explicit exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses the two possible response shapes ({host, access, remaining_s} vs {slots_full, detail}), which hints at success and capacity-failure paths, but says nothing about auth requirements, what happens to an already-running instance, or instance lifetime.

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

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

One front-loaded sentence with a bracketed input clarification and a compact return summary. No filler; every clause carries information.

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

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

An output schema exists, so the return-shape restatement is not strictly required. For a state-changing 'start' operation with no annotations, the description omits prerequisites, idempotency/lifetime behavior, and slot-limit semantics, leaving 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?

With 0% schema description coverage, the description must compensate. The '(id or name)' clause usefully tells the agent the challenge parameter accepts either an identifier or a name, which the bare string schema does not convey.

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 ('Start') and resource ('dynamic instance for a challenge') with a clear parenthetical on the input form. It is easily distinguished from whale_list and whale_stop by name and action, though it doesn't explicitly name those siblings.

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

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

No guidance on when to use this versus whale_list or whale_stop, no prerequisites (e.g. challenge must exist, must be dynamic, slot availability), and no exclusions. The agent must infer the workflow.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the destructive nature ('stop/destroy') and the ownership requirement, but says nothing about idempotency, whether it errors when no instance is running, or whether instance state is lost.

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

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

One efficient, front-loaded sentence with the destructive verb and scope before the parameter note. The '[ctfd-whale]' namespace tag is minor overhead but not wasteful.

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?

An output schema exists, so return values need not be described, and with a single documented parameter the definition is close to sufficient. The remaining gap is failure behavior — what happens if no instance exists — which an agent would need.

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

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

Schema coverage is 0%, so the description must compensate for the single 'challenge' string parameter. It does: the parameter accepts either an id or a name, and must reference a challenge the caller owns — real meaning beyond the bare schema.

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

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

States a specific verb pair (stop/destroy) and resource (dynamic instance) with the scoping constraint 'for a challenge you own'. It is clearly distinct from whale_start and whale_list by implication, though it never names a sibling 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?

Usage is implied: call this when you want to tear down an instance you own. The ownership prerequisite is stated, but there is no explicit when/when-not guidance or mention of an alternative path.

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