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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds useful context by enumerating the information the tool provides, such as edition details, label counts, and dimension summaries.

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 description is two sentences with no wasted filler, and the usage instruction is clearly separated. The first sentence is a somewhat clunky comma-separated list, but it remains readable and front-loads the tool's scope.

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

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

For a zero-parameter, read-only introductory tool with no output schema, the description is complete. It tells the agent what information will be returned and when to invoke it, and the annotations cover the safety behavior.

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

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

There are zero parameters, so there is no parameter syntax or meaning to explain beyond the schema. The baseline for a parameterless tool is 4.

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 lists the topics covered (what the Radar is, edition details, label counts, nine dimensions, server usage) but does not use a clear verb such as 'returns' or 'explains'. It conveys an informational overview tool, yet it does not explicitly distinguish itself from siblings like how_to_contribute, list_dimensions, or show_radar.

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 condition for use: 'Call it first if you have not used the Radar before.' This is clear onboarding guidance, though it does not name alternatives for users who are already familiar with the Radar.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, and the description is consistent with them: the tool produces a link rather than filing anything, so the actual GitHub issue creation happens downstream. The description adds genuinely useful context beyond annotations — that the resulting application is a PUBLIC GitHub issue reviewed by an editor — which is exactly the kind of disclosure an agent needs before collecting personal details.

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 what the tool returns, then the public-issue context, then the fill-in constraint. Nothing is redundant, though the phrase 'joining the list of people of The Intelligence Radar' is slightly awkward and could be tighter.

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

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

With no output schema, the description carries the burden of explaining the return value and does so by calling it a 'pre-filled link'. It also covers the public-visibility implication of submitting. Minor gaps remain: whether the link is a URL string, whether a GitHub account is required, and how this differs from the sibling how_to_contribute.

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 80% and three of the five fields carry their own descriptions, so the schema already does most of the work. The description adds one non-trivial cue — that every field is effectively optional and only supplied values should be filled — but it does not clarify the format expected for 'links' or what 'None' means for disclosure beyond what the schema says.

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 uses a concrete outcome — a pre-filled link to the application form for becoming a contributor or specialist reviewer — which is more specific than the name alone. It implicitly distinguishes itself from submit_contribution (this is the application step, not a contribution submission), but it never names or rules out the nearby how_to_contribute or submit_contribution tools, so the differentiation is left partly to inference.

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?

'Fill in only what the person gives' is a real usage constraint (do not fabricate missing fields), and the phrase 'or specialist reviewer' indicates the audience. However, there is no explicit statement of when to call this versus how_to_contribute or submit_contribution, and no prerequisites such as whether a GitHub sign-in is expected.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds real behavioral context: entries at Wait or Prepare are flagged because the plan may assume unsupported readiness, and untouched dimensions are listed, which tells the agent how to read the result rather than just what it contains.

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

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

Two sentences with no filler. The action and target come first, the return shape and the Wait/Prepare flagging follow, and every clause carries operational information rather than restating the 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?

The output schema exists, so the description did not need to spell out return values at all, yet it usefully characterizes the most decision-relevant part (flagged Wait/Prepare entries and untouched dimensions). Combined with 100% schema coverage and full annotation coverage, nothing essential is missing; only explicit alternative-selection guidance 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 100%, so text, limit and sector are already documented in the schema; the baseline of 3 applies. The description adds nothing about the sector lens or the limit cap, and its only parameter-adjacent signal is that the input is plan or document text.

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 (match) and a specific resource (a plan, roadmap, architecture, policy, business case or initiative list) checked against The Intelligence Radar. It also enumerates the returned content, which distinguishes it from read-oriented siblings such as search_radar, get_entry and get_dimension.

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 input side is clear enough to imply when the tool applies (any substantial document to be assessed against the Radar), but there is no explicit routing guidance. It never says when to prefer search_radar, get_dimension or show_radar instead, and names no prerequisites or 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that—no auth requirements, no not-found/error behavior, no indication of payload size or cost. It stays at the minimum viable level for an annotated read 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?

A single dense sentence with no filler and the resource front-loaded. It loses a point because terms like "placements" and "intelligence label" are undefined jargon that may not be self-evident to an agent unfamiliar with the domain.

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 enumerates the returned sections, which is the main gap it needed to fill for a one-parameter read tool. It remains incomplete on error cases and on how to obtain valid dimension names, both of which an agent would need in practice.

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 already documents both accepted forms (integer 1-9 or a name such as "Agents and workflow"). The description contributes nothing further 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 the resource (a single dimension) and enumerates what the payload contains: coverage, why entries sit together, placement implications, and entries by intelligence label. That is specific enough to distinguish it from a flat listing, but the verb is elided ("One dimension:") and it never names the sibling list_dimensions that an 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?

There is no when-to-use guidance at all: nothing says to call this after list_dimensions, nothing distinguishes a shallow fetch from search_radar or get_entry, and nothing covers what happens when the dimension identifier is unknown. The agent must infer the call context entirely from the tool 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 already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description's added value is the return-content inventory, which is genuinely useful given there is no output schema, but it says nothing about behavior on a missing entry or about lookup resolution.

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, front-loaded with the key framing 'The full entry', with no filler. The comma-separated inventory is dense but each item earns its place by telling the agent what comes back.

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, describing the returned fields is exactly the right compensation, and the annotations cover the safety profile. The only gap is that it doesn't tell the agent how to obtain a valid entry reference (e.g. via search_radar) or what happens when the entry is not found.

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 schema already documents that the entry parameter accepts an ID (IR-028), a number (28) or a title. The description adds no further meaning 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?

The description opens with 'The full entry' and enumerates the components returned (judgement, conditions, test, failure mode, examples, owner, related judgements, sources), which clearly marks this as a full-detail fetch rather than a search. It never states an explicit verb like 'retrieve', relying on the title for the action, but the resource and scope are 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?

There is no when-to-use guidance and no mention of alternatives such as search_radar (to find an entry) or list_judgements. The phrase 'the full entry' hints at a detail-vs-list distinction, but the agent must infer that on its own.

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 establish this as a safe, idempotent, non-open-world read, so the description's job is to add context — and it does by outlining the substantive sections of the response (rules and their dates, starting entries, sector-specific placements with reasons, hold-backs, priorities). That is genuine behavioral value in the absence of an output schema, though it stays conceptual and never mentions length limits, formatting, or what happens with an unknown sector value.

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, the first front-loading the payload and the second delivering the no-argument fallback mode; nothing is redundant. The parallel clause list is dense but scannable, with only mild loss from abstract nouns like "what binds there" that could have been stated as "binding rules".

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 optional-string read tool with no output schema, the description covers purpose, the return content categories, and the no-argument mode — enough for an agent to call it correctly. The remaining gap is error and edge-case behavior for invalid sector values, which is a minor omission given full schema coverage.

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 schema already lists the six supported sector values, so the baseline is 3. The description does add one meaningful behavioral detail the schema lacks — that omitting the parameter switches the tool into a sector-listing mode — but it does not clarify matching behavior (exact string, case sensitivity) or what an unrecognized sector returns.

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 (the sector lens) and enumerates what it returns: binding rules with dates, starter entries, entries placed differently and why, hold-backs, and top entries. The verb is implicit ("How the Radar reads for one sector" rather than "Get the sector lens"), and the metaphorical phrasing ("what binds there", "what to hold back") makes the payload slightly harder to grasp, but the tool is still clearly distinguishable from siblings like get_entry or search_radar.

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 useful usage rule: omit the sector to list the sectors the lens covers, which explains the optional parameter. However, it never says when to use this versus get_entry, get_dimension, or search_radar, nor does it state prerequisites or suggest a workflow (list sectors first, then query one).

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description needn't argue that. It adds useful content about the shape of returned records, but says nothing about what happens with out-of-range or nonexistent numbers, or whether results are ordered as requested.

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 compact sentence with no filler, and the identifying content (numbered sources, cited as [n]) is front-loaded. Minor cost: the trailing clause 'how that kind of source is read' is vague and slightly hard to parse.

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 carries the burden of describing returns and does list the record fields, which is the right instinct. It leaves gaps for an agent with one required parameter: no error behavior for invalid numbers and no hint about result ordering or the 60-item 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 parameter is documented with an example ([164, 170]), so the baseline is 3. The description's '[n]' phrasing reinforces what the numbers mean but adds no format or bounds guidance 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?

Identifies a specific resource (numbered citation sources) and enumerates what each record contains (title, links, kind, reading guidance), which sets it apart from generic siblings like get_entry or search_radar. It is phrased as a noun fragment rather than a verb+resource statement, so the 'look up' action comes mainly from the title.

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 '[n]' notation implicitly tells the agent these are the reference markers appearing in Radar text, so the usage context is inferable. It never states when to prefer this over get_entry or search_radar, nor what to do if a cited number is unknown.

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, closed-world, and non-destructive, so the safety profile is covered. The description adds genuinely new context: the tool reports conversation-specific state (whether this assistant is connected to a GitHub account), signaling the answer can vary per session rather than being static documentation.

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 a colon list of covered topics, followed by a short imperative call-to-action. No filler or repetition; 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?

For a zero-parameter, read-only knowledge tool with no output schema, the description gives everything an agent needs: what it returns (four named topic areas) and when to invoke it before contributing or reviewing. Nothing material 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. The enumerated topic list is the only meaningful content the description could add here, and it does so.

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 resource (contribution guidance for The Intelligence Radar) and enumerates the exact topics it covers: what can be contributed, reviewer requirements, review/publication flow, and GitHub account connectivity. The scope qualifier 'from this conversation' is useful, though it never names a sibling such as about_radar or prepare_contribution to sharpen 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?

'Call it before helping someone contribute or review' gives a clear trigger condition and an implied ordering relative to the contribution workflow tools. It does not state when this tool is unnecessary (e.g., once the user has already read the guidance) or name alternatives for adjacent questions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value by disclosing the return structure (nine items, three lens groupings, per-dimension question and entries tagged by intelligence label) which matters because no output schema exists. It does not cover ordering, size, or whether entries are truncated, 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?

A single sentence with no filler, and the headline fact (nine dimensions across three lenses) is front-loaded. The trailing clause 'each with its question and its entries by intelligence label' is dense but still earns its place by describing the payload.

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

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

For a zero-parameter read-only listing with no output schema, the description covers what is returned and how it is grouped, which is the main thing an agent needs. What is missing is scale and format expectations (roughly how large the response is, how entries are labelled) plus any routing to get_dimension for follow-up.

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 disambiguate; the baseline for a no-parameter tool applies. The description correctly implies a full, unfiltered catalogue rather than a filtered subset, which is the only relevant semantic here.

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

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

The description names the resource concretely (the nine dimensions, grouped into three lenses: capability, context, control) and says each carries its question and its entries by intelligence label, so an agent knows exactly what the call yields. It falls short of a 5 because it is a noun-phrase content summary rather than an explicit verb+resource statement, and it never distinguishes itself from the sibling get_dimension.

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?

There is no when-to-use guidance at all: no statement that this is the entry point for browsing the whole catalogue, and no pointer to get_dimension for fetching a single dimension or to search_radar for filtering. The agent must infer the relationship to the many sibling tools from their names alone.

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, non-destructive, and closed-world behavior. The description adds useful behavioral context by scoping results to 'this edition' and describing the per-judgement record structure, though it omits ordering, pagination, or completeness details.

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 definition is a single efficient sentence with the scope front-loaded and the field list earning its space. The colon-list style is slightly cramped, but there is no redundant wording.

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 appropriately enumerates the returned fields and states the edition scope. Annotations cover safety behavior, and the remaining gaps around ordering or result size are minor for a zero-parameter list 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?

The tool takes no parameters, so the baseline is 4. There are no parameter semantics for the description to clarify, and the schema is empty as expected.

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 the specific scope ('This edition's enterprise judgements') and enumerates the fields each judgement contains. It does not explicitly name sibling alternatives, but the resource is distinct enough from contribution and radar tools to support correct selection.

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: use this to retrieve this edition's enterprise judgements. However, there is no explicit when-to-use guidance versus siblings such as get_entry or search_radar, nor any statement of when not to use it.

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 open-world, so safety is covered. The description adds genuine context beyond that: the data originates from GitHub, and the single-item mode returns reviewers' decisions and reasons, which tells the agent the payload shape differs by mode even though no output schema exists.

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 sentence, front-loaded with the core resource, and the branching scope is stated compactly. The colon-and-clause construction ('from GitHub: all of them, or one in full with...') is slightly awkward to parse, but nothing is redundant.

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 optional-parameter read tool with full annotation coverage, the description supplies what matters: the two modes, output-source, and the richer content of single-item responses. The only gap is any hint about volume or ordering when fetching all contributions, which is a minor omission.

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 id parameter already documents the accepted formats (C-0007, #7) plus the leave-it-out behavior, so the schema does the heavy lifting. The description reinforces the all-vs-one distinction and adds that the single mode yields full detail with reviewer decisions, but contributes no format or constraint detail the schema lacks.

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 pairing: retrieving the status of 'your contributions' to The Intelligence Radar, with an explicit two-mode scope ('all of them, or one in full'). An agent can distinguish this from submit_contribution, revise_contribution, and withdraw_contribution purely from the wording, since those are mutations while this is a status read.

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 conveys when each mode applies (omit the id for all, supply it for one in full) but gives no explicit when-to-use guidance against a sibling, and list_judgements/get_entry could plausibly surface overlapping reviewer-related data. Usage is strongly implied rather than routed.

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?

The annotations declare readOnlyHint, idempotentHint and destructiveHint=false, and the description reinforces this in plain language ('It sends nothing'), which is corroboration rather than mere repetition. Beyond that it discloses the return contents (exact preview, problems to fix, payload, draft_id) even though no output schema exists, and adds a behavioural constraint on corrections (each find must occur exactly once in its section). That is material context an agent would otherwise have to discover by failure.

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 scope and the key 'sends nothing' property are front-loaded, and nearly every clause carries operational weight. It is a dense single block, though; the correction-specific and ask-the-person instructions could be separated into their own lines to be scannable, which keeps it from a 5.

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 14-parameter, heavily nested tool with no output schema, the description covers the workflow (prepare, show, confirm, then submit), the safety profile, and the returns. Some per-kind field requirements are left to the schema, which is acceptable given 93% coverage, but an agent still has to consult the schema for which fields pair with each kind.

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 93% schema description coverage the schema already explains most parameters, so the baseline is a 3. The description adds genuine meaning on top: the exact-match-once invariant for the correction `find` edit, the requirement to source those words from get_entry, per-kind requirements (label change needs conditions and evidence), and the instruction to solicit credit and declared interests from the person. These are non-obvious semantics not present in the schema text.

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 ('Check a contribution ... and prepare it for submission') and enumerates the five contribution kinds a caller can prepare. It also distinguishes itself from the submit sibling with 'It sends nothing', so an agent can tell the two apart without opening any schema.

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

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

It states the ordering rule explicitly ('get their explicit agreement before calling submit_contribution'), names a prerequisite for corrections ('copy the exact current words from get_entry into find'), and gives an exclusion ('It sends nothing'). It also instructs the agent to ask the person for missing data rather than invent it, which is direct when-to-do-this guidance rather than 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 only declare the generic write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds two non-obvious consequences: the GitHub issue is updated, and approvals of earlier versions no longer count — a state effect an agent could not infer from structured fields. It also imposes a human-in-the-loop confirmation requirement before invocation.

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 state condition, then the prerequisite workflow, then the side effect. No filler, and every clause carries operational meaning for the caller.

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

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

For a two-parameter mutation with no output schema, the definition covers the trigger state, the mandatory preparation path, the argument sourcing, and a consequential side effect. Nothing an agent needs in order to call it safely is missing.

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

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

Schema description coverage is 100%, so both parameters already document their expected values, including that draft_id comes from prepare_contribution in this conversation. The description restates this pairing but adds no format or edge-case detail beyond the schema, 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?

Uses a specific verb and resource ('Send a revised version of your contribution') and scopes it to a precise state ('while it is in review or after the reviewers asked for changes'). The reader can distinguish it from submit_contribution (new work) and prepare_contribution (preparation step) without opening any schema.

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

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

States the trigger conditions explicitly and spells out the prerequisite sequence: prepare with prepare_contribution, show the preview, get explicit agreement, then call this. The alternative (prepare_contribution) is named along with the condition that selects it.

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 behavior, so the bar is lower; the description adds the useful filter-without-query listing mode and the shape of returned fields. It omits ordering semantics ('in order' is unexplained) and any paging behavior beyond the limit parameter.

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, zero waste, capabilities front-loaded before the return/behavior note. Nothing repeats the tool name or title 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?

Covers query, dimension, intelligence and enterprise filters but silently omits the sector parameter, one of six. Since an output schema exists, describing return fields is optional padding rather than a completeness gain; ordering and routing to sibling retrieval tools remain 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 coverage is 100%, so every parameter already carries its own description, examples and enums. The description only restates that filters are optional and that a queryless filter call lists results, adding no format or combination semantics beyond the schema.

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

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

States a specific verb ('Find entries') and the match surface (topic, technology, practice, keyword), plus the optional filter axes. An agent can distinguish this from get_entry (single entry) without opening the schema, 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?

Usage is implied rather than stated: query to search, filters alone to list. It never says when to prefer show_radar, list_judgements, get_dimension or get_entry instead, and gives no 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?

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the lower bar applies. The description still adds real value beyond them by disclosing host-dependent output: interactive hosts get a selectable view, non-interactive hosts get the same selection as text, and the view invites follow-up questions about a chosen entry.

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

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

Three tight sentences, front-loaded with the action and deliverable, then the filtering/highlighting options, then the degradation behavior. No sentence is filler; the host-fallback line in particular 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?

There is no output schema, and the description compensates by explaining both what the user sees (interactive radar) and what the agent gets on non-interactive hosts (text selection). Minor gaps remain — nothing about behavior when highlight IDs are unknown, or how the view is scoped within a conversation — but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including the sector, dimension, and highlight semantics. The description only restates the dimension/label filtering and highlighting at a high level, adding no format or interaction detail 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?

"Show the interactive radar in the conversation" gives a specific verb (show/render) plus resource, and the modifiers (filter by dimension or label, highlight entries) tell an agent exactly what the tool produces. The mention of "entries a search or plan check returned" implicitly ties it to search_radar and check_plan, though no sibling is named explicitly as an alternative.

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 supplies a concrete usage pattern: render the radar, optionally scoped to a dimension/label, or highlight a result set from a search or plan check. That is enough for an agent to decide between rendering and the retrieval siblings (get_entry, search_radar). It stops short of explicit exclusions, e.g. when a plain list of entries is preferable to a visualization.

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

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

Beyond the annotations, the description discloses the two-step authentication flow, the first-call return of a short code and address, the need for the person to act, and that the sign-in persists locally on the computer. It also explains that sign_out removes the local sign-in, which is important behavioral context.

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 description is front-loaded with the purpose, then explains the two-step flow and sign_out behavior without unnecessary wording. Every sentence contributes useful operational context.

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 authentication tool with no output schema, the description covers the essential call flow, local persistence, and sign-out behavior. It could be slightly more complete by stating what the second call returns or how already-signed-in or failure cases behave.

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

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

Schema description coverage is 100%, so the single sign_out parameter is already documented in the schema. The description confirms that setting sign_out to true removes the sign-in, but adds little beyond the schema baseline.

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: connecting the assistant to the person's GitHub account, and explains the outcome of contributions and reviews being attributed to that account. It is clear, but it does not explicitly distinguish itself from sibling tools such as apply_to_contribute or submit_contribution.

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 two-step sign-in flow is clearly explained: first call returns a code and address, the person opens the address and enters the code, then the tool is called again. It also explains the sign_out option, but does not state explicit alternatives or when not to use this 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 only declare that this is an externally visible, non-destructive write; the description adds the substantive behavior: with GitHub connected it opens an issue from the person's own account and returns the review desk's answer, otherwise it returns a pre-filled issue link for the person to open and submit themselves. That is real side-effect disclosure beyond what the annotations carry.

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 the action, then the consent gate, then the two execution branches. No filler and every clause carries information an 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?

There is no output schema, and the description covers both return paths (review desk's answer vs. pre-filled issue link), so an agent knows what to expect in either mode. For a single-parameter submission tool, nothing material is missing.

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

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

Schema description coverage is 100% and the single parameter is already documented as the draft_id returned by prepare_contribution. The description reinforces that it must come from this conversation, but adds no syntax or format detail beyond the schema, 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 and resource (submit a contribution) plus the exact handle it consumes (draft_id from prepare_contribution in this conversation). This clearly separates it from sibling prepare_contribution (which creates the draft), revise_contribution and withdraw_contribution.

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, checkable precondition: call only after showing the person the preview and obtaining explicit agreement. That is strong when-to-use guidance, but it does not name the alternatives when the person wants changes instead (revise_contribution) or changes their mind (withdraw_contribution).

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

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

Annotations already flag destructive, non-idempotent and open-world, so the important addition is the mechanism: it comments '/withdraw' on the GitHub issue, which closes it. That tells the agent the effect is public and visible on GitHub and that closure follows, which is real value beyond the structured hints. It doesn't say whether the person can reverse it, what happens on failure, or which auth is needed, so it isn't 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?

Three short sentences, front-loaded with the action and its precondition, then the consequence. Nothing is redundant and every sentence 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 two-parameter destructive action with no output schema, the description supplies the essential picture: consent requirement, timing window and the concrete side effect of closing the GitHub issue. It lacks failure behaviour, reversibility and auth notes, so it is strong but not exhaustive.

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 both 'id' (with its C-0007 / #7 pattern) and 'reason' are already documented in the schema. The description mentions neither the id nor the reason field, and only weakly hints at reason through 'the person's words'. Baseline 3 applies when the schema does the work.

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

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

The description uses a specific verb and resource ('Withdraw your contribution') and adds the precondition 'before a final decision', which separates it from revise_contribution or submit_contribution in practice. It never names a sibling explicitly or contrasts with one, so it stops short of the top mark.

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?

'Call it only when the person has said so' is an explicit consent gate, and 'before a final decision' sets a clear timing window that implies a when-not (after a final decision). It stops short of 5 because it never points the agent at the alternative action to take when withdrawal is inappropriate.

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