qrvote

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

Annotations already declare destructiveHint=false, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the auth requirement (organizer key), which is genuinely beyond the annotations, but omits what happens on duplicate entries or to existing ones.

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, front-loaded statements with essentially zero waste. It is slightly run-on (no punctuation between the two clauses), but 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 simple two-parameter mutation with no output schema, the description covers the key precondition (organizer key) and is backed by annotations for safety flags. It still leaves entrants/duplicate behavior and result format unexplained, so it is adequate but not complete.

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

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

Schema coverage is only 50%, and the description adds no parameter meaning at all – it never mentions slug or the entrants array. The schema itself documents slug well and partially documents entrant fields, but the description does not compensate for the coverage gap.

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

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

The description names a specific verb and resource ('Add entries ... or checkpoints') and clarifies that the same tool targets two campaign types. It does not distinguish itself from siblings like add_judge, 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?

'Needs the organizer key' states a real precondition for invoking the tool, which is useful. However, there is no guidance on when to use this versus other add_* siblings or any exclusions, leaving usage largely implied.

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

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

Annotations declare the safety profile (readOnly=false, destructive=false, idempotent=false), but the description adds meaningful extras: the organizer-key auth requirement, the side effect that the judge will appear at getDashboard → judging.judges, and the private scorecard link format that must be shared only with that judge. It does not address re-adding an existing judge or failure modes, keeping it below a 5.

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

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

The sentence opens by restating the title verbatim ('Contests: add a judge (judging must be on)') before delivering new content, then crams preconditions, auth, return behavior and a URL template into one run-on sentence. The actionable information is present but not well front-loaded or organized.

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

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

With no output schema, the description usefully explains what the agent gets back (the judge listed on the dashboard with a private scorecard link) and what auth is needed. Only the undocumented 'name' parameter leaves a small gap for a two-parameter mutation tool.

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 50%: the slug property carries its own pattern description, while 'name' is undocumented. The description surfaces the slug's role through the example link but adds no constraints on the judge name (e.g., the 60-char limit), so it only partially compensates for the coverage gap.

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

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

The description gives a specific verb+resource ('add a judge') and states the precondition ('judging must be on'), which clearly separates it from siblings like remove_judge and add_entries. It never explicitly names an alternative, so it stops short of the sibling-differentiation bar for 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?

'Judging must be on' and 'Needs the organizer key' give a clear precondition and authorization requirement, and 'Give it to that judge only' prescribes a follow-up action. It provides solid context but no explicit instruction on when to choose this over other judge-related tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and non-openWorld, so the safety profile is covered. The description adds a genuine behavioral fact the annotations do not carry: an organizer key is required for authorization.

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

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

A single front-loaded sentence with the resource list first. It is efficient, though the missing punctuation between 'CSV' and 'Needs' makes the two ideas run together.

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

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

For a one-parameter exporter this is largely adequate: destination format (CSV) and auth requirement are stated. However, with no output schema, it gives no hint about what columns or scope the export contains, leaving 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?

There is only one parameter (slug) and schema description coverage is 100%, with the schema even providing a concrete URL example. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

Names a specific verb (Download) and the exact resources available (votes, survey responses, hunt players) in CSV form. It is clear enough to separate from generic readers, but it never explicitly distinguishes itself from close siblings like get_results or list_responses, which cover overlapping data.

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

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

The phrase 'Needs the organizer key' signals a prerequisite but says nothing about when to choose this over get_results or list_responses. Usage is only implied by the CSV output format.

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 idempotentHint=true, so the safety profile is covered. The description adds one concrete behavioral detail: entry QR codes are never included when scanning is required. That's useful but thin; there's no note on what gets returned or pagination. Not contradictory, but the added value over annotations is modest.

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

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

The opening clause duplicates the title verbatim, and the sentence lists data types without a clear action verb. It is short but not front-loaded with what the tool does, making it hard to scan.

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

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

With one required parameter, no output schema, and full annotation coverage, the description is mostly adequate on structured fields but fails to state the tool's core action. It leaves ambiguity about whether this retrieves, searches, or modifies a campaign.

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

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

Schema coverage is 100% and the slug parameter already has a detailed description with pattern and example. The description adds no parameter-level detail (e.g., error behavior on unknown slug). Baseline 3 applies when the schema fully documents the parameter.

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

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

The description restates the title/name rather than stating what the tool does. It is a noun phrase ('A contest, survey or hunt as the public sees it') with no verb indicating retrieval, and no differentiation from siblings like get_results or get_dashboard. The added sentence about entries/questions/checkpoints describes data fields, not the tool's action.

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

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

The phrase 'Public: no key needed' implies a read access context, which suggests when it can be used (unauthenticated public view). However, it offers no explicit when-to-use vs when-not-to-use guidance and names no alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing the organizer-key authorization requirement and that fairness signals are returned grouped and hashed, but says nothing about payload size, pagination, or what happens without the key.

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 content inventory front-loaded and the auth caveat last. The first sentence is a fragment-style list, which is terse but slightly awkward as prose.

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 aggregate tool with no output schema, enumerating the returned sections plausibly substitutes for a return-value description, and the auth requirement is stated. Missing only edge behavior (empty/unauthorized cases) and overlap with sibling endpoints.

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

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

Schema coverage is 100% and the single slug parameter is fully documented with a pattern and URL example, so the schema carries the parameter burden. The description adds no formatting or fallback detail for slug, only the separate credential note; 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?

The description names a specific aggregate resource and enumerates its contents (settings, entries with vote counts, ballot tickets, fairness signals, survey/hunt data), so an agent knows this is a one-stop read of organizer state. It does not explicitly differentiate from siblings like get_results, get_campaign, or list_responses, which likely overlap on some of the same data.

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 states a prerequisite ('Needs the organizer key') but gives no when-to-use guidance and never names an alternative among the many overlapping read tools (get_campaign, get_results, list_responses). The agent must guess whether this is a superset replacement or a separate view.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds real behavioral context beyond them: visibility gating, what contests return (categoryResults, judgeResults), and explicit exclusions (written answers and individual judge scores are never included). That privacy boundary is valuable disclosure.

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?

Content is front-loaded and dense with useful facts, but the opening clause simply restates the tool title before getting to the visibility rule. Minor redundancy, otherwise no wasted sentences.

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

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

There is no output schema, so the description correctly compensates by describing the returned result shapes and the privacy exclusions. It covers enough for an agent to call and interpret the tool, though the public/private visibility semantics could be spelled out slightly more.

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 there is a single slug parameter whose format and example origin are fully documented in the schema. The description adds nothing about the parameter, 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?

The description names a specific verb+resource (retrieving results) and enumerates the three shapes it can return (vote tallies, survey totals, hunt leaderboard), which is concrete. It does not explicitly distinguish itself from siblings like list_responses or export_csv, 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?

It gives one conditional: 'Public when the organizer made results visible; otherwise send the organizer key,' which is useful auth guidance. However, it never says when to choose get_results over export_csv or list_responses, so alternative-selection guidance is only implied.

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

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

Adds substantial behavior beyond the annotations: the legal state machine, the 409 failure mode, the auto-advance clock (hostSecs per question, 8 s per answer reveal), and how pause/resume and manual steps interact with that clock. It also discloses the organizer-key auth requirement, which the annotations (only readOnly/destructive/idempotent/openWorld) do not cover.

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 action list, then tight sentences on ordering, timing, and auth — every clause carries information. The only waste is the opening clause duplicating the title almost verbatim.

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

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

For a non-idempotent mutation tool with no output schema, the description covers auth, legal ordering, failure codes, and timing side effects, which is nearly everything an agent needs. It omits any indication of what a successful call returns, a minor gap given no output schema exists.

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

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

Schema coverage is 50% — slug is documented in the schema but the action enum is not. The description compensates by spelling out the body shape and describing what pause/resume actually do to the clock, giving real meaning to two enum values the schema leaves bare.

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 ('Run a live quiz') and enumerates the exact state transitions it performs (start, reveal, next, finish, pause/resume). No sibling tool in the list does this, so an agent can distinguish it immediately from get_dashboard, get_results, or update_settings.

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 applicability conditions: only for quizzes with host = true, and it requires the organizer key. It also specifies the legal call ordering (lobby → question → reveal → … → done) and that anything else returns 409. It does not name an alternative tool for the non-host case, but the gating condition is explicit.

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

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

Annotations already declare read-only, idempotent, closed-world, non-destructive. The description adds genuinely new behavioral context: results are truncated at 500 rows and ordered newest-first, quiz responses carry scores, and an organizer key is required. It stops short of saying what happens past 500 (silent truncation vs. pagination).

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

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

Two short sentences with zero filler; the scope constraints (ordering, cap, quiz scores) are front-loaded and the precondition is last. Every clause earns its place.

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

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

With no output schema, the description does the work of describing the return payload (ordered responses, up to 500, with quiz scores) and the auth requirement. It is complete enough to call correctly, though it omits overflow behavior beyond the 500 cap.

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

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

Schema coverage is 100% and the single 'slug' parameter is documented in the schema with both pattern and a worked example URL. The description adds no meaning beyond the schema, so 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+resource ('Survey responses') with concrete scope modifiers: newest-first ordering and a 500-row cap, plus conditional content for quizzes (scores included). It does not, however, differentiate itself from close siblings like get_results or export_csv, so the agent must infer the boundary.

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

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

The only guidance is a prerequisite ('Needs the organizer key'), which is a prerequisite rather than a when-to-use rule. Nothing says when to choose this over get_results (aggregate results) or export_csv (file export), and no exclusions are 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 idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond them: the cascade (link and scores are also removed) and the authorization requirement (organizer key), both of which affect how an agent should invoke it.

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?

Very short and the purpose is front-loaded, which is good, but it is a run-on sentence with a missing break before 'Needs', making it feel like a tidied title rather than a crafted description.

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

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

For a destructive cascade-removal tool, the description does disclose the auth requirement and what else gets deleted, and annotations carry the destructive/idempotent hints. However, it never explains the 'id' parameter, and with no output schema the agent gets no sense of the response beyond 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?

Schema coverage is only 50% – 'slug' is documented with a pattern and example, but 'id' has no description anywhere. The description adds no parameter meaning at all, so it fails to compensate for the undocumented half of the inputs.

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 ('remove') and resource ('a judge') plus the scope of the removal ('their link and their scores'), which distinguishes it cleanly from the sibling add_judge. An agent can identify this as the inverse of judge creation 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 a prerequisite ('Needs the organizer key') but no when-to-use or when-not-to-use guidance against alternatives. Usage is implied by the verb rather than stated, so it clears the minimum bar but leaves routing to inference.

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

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

Annotations declare this is a non-readOnly, idempotent, non-destructive mutation; the description goes well beyond that by disclosing the downstream side effect (all scores recompute), the timing allowance (after people have answered), the auth need (organizer key), and a hard constraint on nulling questions. It does this without contradicting the hints.

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

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

Front-loads purpose, then body format, then semantics and guards in a tight sequence with no filler. The only waste is restating the title verbatim in the first clause, which duplicates structured data.

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 no-output-schema mutation with a nested free-form parameter, the description covers format, side effects, guards, and auth. It stops short of saying whether an update merges with or replaces the existing key, and how invalid or unscored keys are reported back.

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

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

Schema coverage is only 50% and the answers object is a free-form map with no schema description at all, so the description carries the full burden — and does: answer-key format per question type (index, index list, accepted-text list), yes/no encoding (1=yes, 0=no), matching normalization (case/accents/punctuation ignored), and the meaning of null. That is everything an agent needs to construct the nested 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 ('Fix a quiz's answer key') and immediately names the consequence ('every score updates'), so the agent knows this rewrites scoring configuration rather than responses or settings. This is clearly distinguishable from siblings like update_settings, add_entries, and add_judge.

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 real usage precondition — 'allowed after people have answered' — which is exactly the fact an agent needs to know it can be called late in a campaign's life. It also states the guard ('At least one question must stay scored') and the auth requirement, but never names an alternative tool or an explicit when-not-to-use case.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, and the description adds one genuinely useful non-annotation fact: the organizer key is required. However, for a 13-parameter mutation it never says whether omitted fields are left intact or cleared, nor that closing voting is reversible via closed=false.

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

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

Two short fragments with no padding, which is good for front-loading, but the run-on 'voting Needs the organizer key' with missing punctuation makes it read as a sloppy concatenation of title and note rather than crafted prose.

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?

A 13-parameter, non-idempotent-by-default settings mutation with no output schema deserves more than one clause of prose. Critical context such as partial-update semantics, permission failure behavior, and interaction between closed/opensAt/closesAt is absent.

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 38% and the description supplies no parameter meaning at all, leaving title, ipLimit, opensAt, closesAt, results, allowChange, description and requireBallot undocumented in effect. The only loose tie is the mention of voting, which the schema already covers via the 'closed' 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?

Names a concrete verb and resource (change settings) and adds the second capability of ending/reopening voting, so the agent knows what the tool does without opening the schema. It does not distinguish behavior from the closest siblings (host_step, get_campaign), but the purpose itself 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?

'Needs the organizer key' gives a usable precondition for calling it, but there is no when/when-not guidance, no mention of what happens if settings are omitted, and no routing toward or away from siblings such as get_campaign or host_step.

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