Debriefing

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

Annotations already declare readOnly=false, destructive=false, and idempotent=false. Beyond that, the description adds genuine behavioral context: the saved note is treated as framing for the next battlecard rewrite and is explicitly never consumed as a verified fact, which materially affects how an agent should phrase content. It stops short of stating auth requirements or what the note does if a battlecard is regenerated.

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 tightly packed sentences with no filler, and the purpose is front-loaded. The prose leans metaphorical ("no page says") rather than plain, which costs a bit of immediate comprehension but not length.

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 an output schema present and annotations covering the safety profile, the description need not explain return values or side-effect safety, and it usefully covers consumption semantics. However, for a tool with four near-duplicate note-adding siblings, the absence of any routing guidance leaves a real gap for correct tool selection.

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%: body's length bounds and plain-text nature and competitor_id's origin from list_competitors are all documented in the schema. The description adds no format, syntax, or sourcing detail beyond that, 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 conveys a write action tied to competitor battlecards ("Adds what the team knows about a core competitor", "the next rewrite of its battlecard"), but it is phrased metaphorically and never plainly says it attaches a note to a battlecard's record. It also does nothing to separate itself from sibling note-writing tools like add_signal_note and add_digest_note.

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 a faint hint about the kind of content this accepts ("what the team knows... that no page says"), but no explicit when-to-use, no prerequisites, and no mention of the alternatives such as add_signal_note or add_digest_note despite several near-identical siblings.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds real context beyond that: an admin-only authorization requirement, a plan-based quota constraint, and the fact that monitoring begins after adding. It doesn't explain failure modes (e.g., duplicate competitor, non-idempotency consequences), keeping it below 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 core action, then monitoring behavior, then the admin/quota constraints. No wasted words.

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 an output schema present, return values need not be described. The description covers the key operational facts an agent needs: auth level, quota check routing, and post-add monitoring. Minor gap in not clarifying duplicate/idempotency behavior, but overall sufficient.

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

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

Only one parameter with 100% schema description coverage, so the schema fully documents website_url including format. The phrase 'from its website' loosely reinforces the parameter's role but adds no syntax or constraint detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (adds) and resource (competitor) with scope (workspace's core watchlist) and source (from its website). This distinguishes it from siblings like add_monitored_page and research_competitor.

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

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

Explicitly states 'Admin only' and points to get_plan_and_limits for checking free slots, which is actionable prerequisite guidance. It stops short of stating when not to use it (e.g., vs. research_competitor or add_monitored_page), so not a full 5.

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=false, destructiveHint=false and openWorldHint=true. The description adds one genuinely useful behavioral fact beyond them: the note is visible to the team in the workspace. It does not mention that repeated calls duplicate the talking point (non-idempotent) or any permission requirement.

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

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

Two short sentences, purpose stated first and the visibility side-effect second. No filler, nothing that fails to earn its place.

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

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

For a simple two-parameter add operation with an output schema and full annotation coverage, the description covers the essentials but omits the non-idempotent consequence of repeat calls and any note about who may add points to a digest. Adequate but with visible gaps.

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

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

Schema description coverage is 100%, with the schema itself documenting 'the talking point, in plain text' and 'a digest id or slug from list_digests', so the baseline is 3. The description adds no format, length, or sourcing detail beyond what the schema already 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 names a specific verb (adds) and resource (a talking point to a digest), which cleanly separates it from the sibling note tools that target battlecards or signals. It does not, however, explicitly name those siblings as alternatives.

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 guidance on when to use this tool versus add_signal_note or add_battlecard_note, nor any preconditions such as needing a digest id from list_digests. The agent must infer the usage context entirely from the noun 'digest'.

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 this as a non-read-only, idempotent, open-world mutation with no destructive hint. The description adds context the annotations do not: the 10-page cap per competitor, the admin/paid-plan requirement, and the downstream effect that detected changes surface as signals.

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, followed by the constraint and the permission requirement. No sentence 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?

With an output schema present, the description needn't explain return values. It covers scope, limits, and permissions, so an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema itself. The description only lightly reinforces this ('one more page', 'pricing page'), adding no format or sourcing detail beyond what the schema provides — the correct baseline of 3.

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

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

The description states a specific action — having Debriefing watch one additional page of an existing competitor — with a concrete example (pricing page). It clearly reads as adding a monitored page to a competitor that already exists, distinguishing it from add_competitor and remove_monitored_page.

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 the operative constraints (up to 10 pages per competitor, admin only, paid plan) that gate whether this tool can even be used. What it lacks is an explicit alternative route — e.g. directing an agent to add_competitor first if the competitor doesn't exist yet.

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

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

Annotations cover the safety profile (non-readonly, non-destructive, non-idempotent, openWorld), so the bar is lower. The description still adds real behavioral value: the note is visible to the team in the workspace and is hidden from public links unless those links include notes, which is meaningful disclosure for an openWorld write.

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, purpose front-loaded, zero filler. Each sentence carries distinct information (action, team visibility, public-link behavior).

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 tool has an output schema, full parameter documentation, and annotations, so the description needn't cover returns or safety. What it does cover — purpose and visibility semantics — is sufficient for correct invocation, though it omits any guidance on when this note tool is preferred over its siblings.

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 both parameters are already documented in the schema, so the baseline is 3. The description adds no format, length, or sourcing syntax beyond what the schema provides.

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 ('Adds') and resource ('a talking point to a signal'), and the resource noun distinguishes it from siblings like add_battlecard_note and add_digest_note. An agent can route to it 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?

There is no explicit when-to-use or when-not-use guidance, nor any reference to sibling note tools. Usage is implied by the name and the visibility sentence, but the agent gets no rule for choosing this over add_digest_note or add_battlecard_note.

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 destructiveHint=true, openWorldHint=true and idempotentHint=false, but the description earns credit by explaining exactly what the destruction means ('A new link replaces the old one, which stops working') and by disclosing the plan-imposed lifetime cap. It does not cover permissions or who can revoke a link, so it is strong but not exhaustive.

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, zero filler, and the core action is front-loaded ahead of the replacement and plan caveats.

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 the annotations plus description together cover the safety and lifetime profile of a mutation tool. The only real gap is that the description says nothing about whether the caller needs specific permissions or ownership to create the link.

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 signal_id, idempotency_key, include_notes and the expiry enum are already documented. The description's plan-limit sentence largely restates the expiry field description ('any other choice becomes 24h there') without adding new syntax or format detail, 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?

States a specific verb and resource ('Makes a public link to one signal') and clarifies the audience ('anyone with the address can open'). This distinguishes it from the sibling read tools get_public_brief and get_free_brief_link, though it never names those alternatives 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?

There is no when-to-use guidance and no comparison against alternatives such as get_free_brief_link or get_public_brief. The plan-related sentence is a constraint on the link's lifetime, not a routing rule for choosing 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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false; the description adds real context beyond them: it is non-destructive by construction (only empty fields are touched), it is admin-only, and it consumes a per-workspace daily quota. It does not explain the retry/idempotency-key behavior that pairs with idempotentHint=false, leaving a small 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?

Five short sentences, each carrying distinct information: what is drafted, the non-destructive constraint, the read-back tool, the permission requirement, and the quota. Nothing is redundant and the core action is front-loaded.

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 tool is a single-parameter, non-destructive generator with an output schema that covers the return value, so the description need not explain results. Permissions, cost (daily cap), scope of mutation, and the follow-up read tool are all covered, which is everything an agent needs to call it correctly.

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

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

There is only one parameter and the schema documents it at 100% coverage, including what the key is for and how retries behave, so the description adds no parameter-level meaning. With schema doing the work for a single well-documented parameter, the baseline of 3 is appropriate.

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

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

States a specific verb (drafts) plus the exact resource and the three fields it fills (value propositions, differentiators, exclusions), and names the source it reads from (the company's own website). This clearly separates it from siblings like update_company_profile and update_icp, which set fields directly rather than generating 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?

Explains the fill-only condition ('Filled fields stay as they are') and routes the agent to get_company_profile for reading the result, so the use/read split is explicit. It does not state the inverse case (e.g., use update_company_profile when you want to write a field manually), so it falls just short of full when/when-not guidance.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description adds meaningful context beyond that: an estimated duration (~one minute), plan requirements (paid plan or free first week), and a daily quota per workspace. These are operational facts the annotations cannot express.

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

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

Three tight sentences that lead with what the tool does, then the follow-up action, then constraints. No filler and no repetition of 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?

Covers purpose, follow-up read, prerequisite research state, timing, plan gating, and quota. With an output schema present, the description needn't explain return values. It stops just short of noting what gets destroyed on rewrite, though the annotations flag destructiveness.

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

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

Schema coverage is 100% and both parameters are fully documented in the schema, including the idempotency-key retry behavior. The description adds no parameter-level detail, which is appropriate 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?

States a specific verb (writes or rewrites) and resource (the battlecard for one core competitor), and clarifies timing ('now, instead of at the next cycle'). The pairing with get_battlecard for reading distinguishes it from 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?

Explicitly says to read the result afterwards with get_battlecard, and names the precondition ('the competitor needs finished research'). This tells the agent both when to use it and what prerequisite state must exist.

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 destructiveHint=false, so the safety profile is fully covered. The description adds that the card is addressable by two different identifiers, which is useful context, but says nothing about behavior when both or neither id is supplied.

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, zero filler, with the core purpose front-loaded ahead of the usage hint. 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?

With an output schema covering return values and annotations covering safety, the description only needs to convey purpose and selection; it does both. The one gap is the unresolved question of which id to prefer when both or neither are given.

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

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

Schema coverage is 100% and both parameters already document their source list, so the schema does the heavy lifting. The description adds the OR relationship between the two ids, but since neither parameter is required it leaves the precedence/fallback ambiguous.

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 ('Gets one battlecard'), and the singular 'one' implicitly distinguishes it from list_battlecards. It does not, however, explicitly name the sibling it is not, so differentiation is inferred rather than stated.

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 usage scenario ('when the user prepares a sales call against a competitor'), which is clear context but soft and omits the alternative tools (list_battlecards for browsing, generate_battlecard for creation). No when-not or exclusion guidance is provided.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real scope information beyond them: this returns the workspace's own profile specifically (not a competitor's) and what content it holds. It stops short of anything about staleness, permissions, or who can read 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?

Two sentences, front-loaded with the core action and its field inventory. The second sentence is somewhat decorative — it explains how the data is consumed elsewhere rather than how to invoke the tool — but it is short and adds orientation, so it mostly 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 zero parameters, rich read-only annotations, and an output schema that documents return values, the description needs only to state what the tool returns and that it is the workspace's own profile — both of which it does. Complete enough to call correctly, missing only guidance on when to fetch it.

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 and the schema is fully self-describing, so the baseline is 4. The description correctly implies a no-argument call by never introducing filtering or selection inputs, though it adds no parameter meaning because there is none to add.

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 and resource ('Gets the workspace's own company profile') and enumerates what it contains: description, category, target customer, positioning lists, ICP. The phrase 'own company profile' cleanly separates it from get_competitor and the competitor-facing siblings, so an agent can pick it without opening a schema.

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

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

The only usage-flavored sentence, 'Debriefing reads every competitor move against it,' describes downstream system behavior rather than telling the agent when to call this tool. Nothing says when to prefer it over get_workspace or when company profile context is required, and no prerequisites or 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context by naming the content categories returned (positioning, product, pricing, funding, traffic), which helps the agent judge whether the call will answer the user's question.

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, no filler; the payload enumeration leads and the usage cue follows. Nothing could be removed without losing signal.

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 an output schema present, the description need not explain return structure, and the safety profile is carried by annotations. It omits any failure mode (e.g. unknown competitor_id), a minor gap for a read tool whose id must come from list_competitors.

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's description ('An id from list_competitors') already explains provenance. The tool description adds no syntax, format, or validity guidance beyond that, 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 (gets) and resource (the dossier for one tracked competitor), then enumerates the payload: company facts, risk/opportunity, and stored reads. The 'one tracked competitor' scope distinguishes it from list_competitors without ambiguity.

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?

'Use it when the user asks about one competitor in depth' gives a clear selection condition. It does not explicitly name list_competitors as the alternative for bulk browsing, but the depth/singular framing implies the boundary well enough.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds a genuinely new behavioral constraint not present in annotations: 'Admin only', an authorization requirement the agent must satisfy before calling.

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 names the verb and resource first, then enumerates the returned fields, and closes with the admin prerequisite. No filler, no restatement of 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?

With an output schema present, the description need not document return values, yet it usefully previews them; annotations cover the safety profile and the admin requirement is stated. What is missing is any routing hint to set_delivery_channels/set_monitoring_cadence for an agent choosing among the delivery-settings family.

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 the baseline is 4. The description correctly adds nothing about arguments and instead uses its space to describe the returned settings, which is appropriate for a parameterless getter.

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 (gets) and resource (delivery settings), then spells out exactly what is returned: monitoring cycle frequency, plan-allowed cadences, and email/Slack delivery of finished cycles. It is clearly the read counterpart to set_delivery_channels and set_monitoring_cadence, though it never names those siblings, so it falls short of full sibling differentiation.

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 the read-only framing and by the presence of the set_delivery_channels/set_monitoring_cadence siblings, but the description never says when to call this versus those tools or that it should be used to inspect current state before mutating it. The only explicit guidance is the 'Admin only' prerequisite.

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 destructiveHint=false, so safety is covered. The description adds genuine behavioral context the annotations don't: the default resolution to the newest digest when id is omitted. It does not cover error behavior (e.g., unknown id), 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?

Three short sentences, front-loaded with the primary retrieval behavior and followed by the default and usage hint. Every sentence carries information; 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?

An output schema exists, so return values need not be described. The description covers both parameters' effects including the no-arg default, which is the main ambiguity for a two-optional-param getter. Minor gap: no mention of what happens with an invalid id.

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 baseline is 3. The description goes beyond the schema by specifying the semantics of omitting both parameters (falls back to newest digest) and by tying type to a concrete value (daily_digest), adding meaning the schema property descriptions alone do not.

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

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

States a specific verb and resource ('Gets one digest by id or slug') plus the no-argument behavior ('newest digest when no id is given'), which cleanly separates it from list_digests. An agent can tell it retrieves a single record rather than a collection without reading 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?

Gives an explicit trigger ('Use it when the user asks for the latest brief') and a parameter-selection hint ('Pass type daily_digest for the newest daily digest'). It lacks stated when-not-to-use conditions or a named alternative (e.g., list_digests), so it falls short of a 5.

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 only added behavioral context is the return shape (excerpt + URL + date), which the output schema largely carries anyway.

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 zero waste: the purpose and the return content are front-loaded, and the usage trigger follows 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?

For a single-parameter read tool with full annotation coverage and an output schema, nothing essential is missing. Only marginally incomplete in that it never explicitly ties the id back to search_signals in the description text.

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 with 100% schema description coverage; the schema already documents signal_id as 'An id from search_signals'. The description adds no format or validation detail beyond that, 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+resource ('Gets the evidence behind one signal') and describes the return content ('each source excerpt with its URL and date'). An agent can distinguish it from search_signals, which supplies the id, 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?

Explicit trigger: 'Use it when the user asks where a claim comes from.' That is clear when-to-use guidance, but it names no alternative or exclusion (e.g. bulk evidence retrieval), leaving the sibling-routing implicit.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's 'only returns links, sends nothing, creates nothing' adds a small amount of confirmation but is essentially a restatement of the annotations rather than new 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?

Three short sentences with no filler, and the core action is front-loaded. The first sentence is grammatically tangled ('links where a person requests...'), which costs a little clarity but not length.

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 the annotations cover the safety and idempotency profile. The description adequately covers a trivial zero-parameter read tool; only the routing versus sibling link tools is left implicit.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to carry. The schema is a closed empty object, consistent with the description's claim that nothing is supplied and nothing is mutated.

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 ('Gets the debriefing.io links') and clarifies what those links are for (free brief request, workspace signup, plan comparison). This separates it from near-neighbors such as create_share_link and get_public_brief, though the sentence is convoluted enough that the exact artifact returned takes a second read to pin down.

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 explicit when-to-use or when-not-to-use guidance and no sibling is named, even though get_public_brief and create_share_link live in the same space. The closing clause ('It sends nothing and creates nothing') hints at the boundary with link-creating tools but never states the selection rule.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine value beyond those hints by enumerating the categories of limits and noting the included pricing link, telling the agent what business constraints it can learn here.

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

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

Purpose is front-loaded in the first clause and the enumeration items are individually meaningful rather than filler. The single long sentence is slightly run-on, but no sentence is wasted.

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 zero params, full annotation coverage, and an output schema present, the description does not need to explain return format, and it is complete enough for correct invocation. The detailed list of limits is somewhat redundant against the output schema, but that is harmless.

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. Baseline 4 applies for a parameterless tool.

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?

Specific verb+resource ('Gets the workspace plan and every limit') and the enumerated contents (competitor slots, weekly research allowance, daily caps, share link lifetimes, monitoring cadences, paid-plan gating) make the scope unambiguous. It never names a sibling to contrast with, so it stops short of a 5 per the rubric.

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 explicit when-to-use, when-not-to-use, or named alternative. The phrase 'every limit an agent runs into' only implies the use case (check caps before performing rate-limited actions), which is implied usage rather than stated guidance.

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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real context: the tool needs no Debriefing account, and it describes the shape of the returned brief content.

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

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

Three tight sentences with zero filler: purpose and return contents first, then addressing modes, then the fallback rule. Every sentence carries information an agent needs to invoke the tool correctly.

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 an output schema present, return values need not be detailed, and the description still covers addressing modes and the no-account requirement. Minor gaps remain around failure behavior (e.g., unknown slug/company) and whether all three params can be combined, but nothing essential 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 coverage is 100%, so the baseline is 3, but the description adds precedence semantics the schema does not state: url alone, or company_slug + slug together, or company_slug alone resolving to the newest brief. That combination/fallback logic is genuinely beyond the field-level descriptions.

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 ('Gets one competitive brief that Debriefing published on debriefing.io') and enumerates exactly what is returned: summary, findings with category and date, and numbered sources with URLs. This clearly separates it from siblings like search_public_briefs (plural, discovery) and get_free_brief_link.

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

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

Explicitly routes the agent: name the brief by URL, or by company_slug + slug from search_public_briefs, and notes the company_slug-only fallback returns the newest brief. It names the sibling that supplies slugs and states the account-free condition, though it gives no explicit when-not-to-use guidance.

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 covered. The description adds orienting behavior beyond that—telling the agent it reveals held scopes and role, which frames why to invoke it early. It does not describe pagination or limits, but for a zero-arg read that is minor.

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 verb and resource, and the field list is the necessary payload of an orientation call. The trailing usage cue is a single clause that earns its place; 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?

With an output schema present, return values needn't be explained, and annotations already carry the safety profile. For a zero-arg read the description gives the agent everything needed—what it returns and when to reach for it.

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 the parameter-semantics baseline is 4. There is no argument syntax or format an agent could misinterpret, and the enumeration of returned content is not a parameter concern.

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 (Gets) and resource (the Debriefing workspace this connection works on) and enumerates the returned content: name, website, identity/role, scopes, and plan. This clearly differentiates it from near-siblings like get_plan_and_limits and list_members without needing to open 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?

"Call it first when you are not sure what you may do" gives an explicit trigger condition and positions the tool as the orientation step. It stops short of naming when-not-to-call or a specific alternative, so it is clear context rather than full when/when-not/alternative coverage.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the description's job is to add context — and it does: 7-day invitation expiry, re-invite behavior (fresh email), and the admin/paid-plan authorization requirement. It does not describe failure modes or what the email contains, 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?

Four short sentences, each carrying distinct information (action, expiry, repeat behavior, authorization) and front-loaded with the core action. Nothing is redundant with the title or annotations.

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 2-parameter mutation with an output schema and full annotation coverage, the description supplies the non-obvious behavior (expiry window, re-invite semantics, plan/admin gating). Only marginal items such as failure behavior or scope of the target workspace are 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 coverage is 50%: idempotency_key is well documented in the schema, while email relies only on format/maxLength with no description. The tool description adds nothing about either parameter (no email normalization, no retry-key guidance), so it does not compensate for the gap, but the covered half and the self-evident email field keep this at minimum viable.

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: 'Sends an email invitation to join the workspace as a member.' No sibling tool performs invitations, so an agent can distinguish this from list_members, add_competitor, or create_share_link 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?

Gives real usage constraints — 'Admin only, on a paid plan' — which an agent must check before invoking. However, it never states when not to use it or points to an alternative (e.g., a direct-add-member path), so guidance stops short of the when/when-not/alternatives bar.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds useful domain context ('one for each competitor that has one', what a battlecard holds) but says nothing about pagination, ordering, or empty-result behavior.

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

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

Two sentences, both earning their place: the first gives scope and cardinality, the second defines the returned object. Nothing is padded and the key scoping fact is front-loaded.

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 an output schema present, the description needn't explain return values, and with zero params there are no input gaps. It covers scope and cardinality but omits ordering/pagination, a minor gap for a listing 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 zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly spends no text on 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 (Lists) and resource (battlecards) and scopes it to 'Debriefing wrote for this workspace', which clearly separates it from the sibling get_battlecard. It even defines what a battlecard is, so an agent can route to it confidently.

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 implies the read-all use case and notes the one-per-competitor shape, but never states when to prefer this over get_battlecard or other siblings. No exclusions or alternative routing are given, so usage 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description usefully adds the workspace scoping ('this Debriefing workspace tracks') and the returned field set, though it does not discuss pagination or empty-workspace behavior.

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

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

Two tight sentences, front-loaded with the action and scope, followed by the high-value routing hint about competitor_id. 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?

An output schema exists, so return details needn't be spelled out, and annotations cover safety. For a zero-param list tool, the description provides purpose, scope, key return fields, and the canonical for tools like get_competitor.

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 baseline is 4. The description correctly implies no filtering input is required, consistent with an empty schema, and adds value by naming the output fields an agent will rely on.

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 (Lists) and resource (competitors this Debriefing workspace tracks), and enumerates the returned fields (id, name, website, category). It is clearly distinguishable from siblings like get_competitor (single) and add_competitor (mutation).

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

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

Explicitly says to 'Call it first to get the competitor_id that other tools take,' which gives a clear when-to-use context and a downstream dependency on siblings. It does not name specific alternative tools or state when not to use it, keeping it short of a 5.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds useful context that results are scoped to the current workspace and ordered newest first, plus a definition of a digest, though it does not explain pagination or limit behavior beyond what the schema shows.

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 and scope, followed by a useful definition of a digest. The definition earns its place by clarifying the resource, though the sentence could potentially be trimmed.

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 rich annotations and an output schema, the description does not need to explain return values. It gives enough context for a list operation: scope, ordering, and filtering. The main remaining gap is lack of detail on the limit parameter, which the schema partially covers with bounds.

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 50%: the type parameter already has a schema description, while limit has none. The description adds that type acts as a filter and gives an example, but it does not compensate for the undocumented limit 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 states a specific verb and resource: it lists digests for the workspace, newest first, and defines what a digest is. However, it does not explicitly differentiate this list tool from the sibling get_digest, which retrieves a single digest.

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 indicates that results can be filtered by type, such as daily_digest, which implies a browsing use case. It does not say when to use this instead of get_digest or search tools, and it offers 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds a genuine trait beyond them: output varies by caller privilege, since an admin additionally sees pending invitations. That is exactly the kind of context annotations cannot express.

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

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

Two short sentences with zero filler; the core purpose is front-loaded and the permission nuance follows. 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 an output schema present, return values need not be explained, and with zero parameters there is no input surface to document. The one gap is that the description says nothing about ordering or whether the list is bounded, which is minor for this 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 zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter information is missing because none exists.

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 ('Lists the people in the workspace with their roles'), which is immediately distinguishable from invite_member among the siblings. It stops short of explicitly naming an alternative or boundary, but the purpose 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?

Usage is only implied by the verb 'Lists' – there is no statement of when to reach for this versus invite_member or get_workspace. The clause about admins seeing pending invitations hints at context but is a behavior note rather than selection guidance.

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, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the team-wide visibility scope and the unpin semantics, but does not explain what 'destructive' means here or note any permission requirements.

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 covering both the action and the inverse, with no wasted words. The primary behavior comes first and the edge case second.

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 the annotations carry the mutation/idempotency profile. For a two-parameter toggle, both directions of the operation and its team-wide effect are covered.

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

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

Schema coverage is 50%: digest_id is documented in the schema, but the 'pinned' boolean is not. The description fills that gap by explaining that 'pinned false' removes the pin, which gives the undocumented parameter real meaning beyond its default value.

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 (pins/removes pin) and resource (a digest) with the added scope of 'for the whole team.' The resource noun plus the sibling set (pin_signal, list_digests) makes the target unambiguous, though it never explicitly positions itself against pin_signal.

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 explains both modes of the tool ('pinned false' unpins), which tells the agent how to invoke each direction, but gives no guidance on when to pin vs. rate a digest or when to prefer other siblings. Usage is implied by the toggle rather than framed as a decision.

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, destructiveHint=true, idempotentHint=true and openWorldHint=true, so the mutation/repeatability profile is covered. The description adds the genuinely useful fact that the pin is visible to the whole team, but says nothing about required permissions or how unpinning affects existing team state.

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 that front-loads the primary action and appends the toggle behavior. Nothing is wasted and nothing essential 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 not be described, and annotations carry the safety profile. The remaining gap is the absence of any routing against pin_digest, but for a two-parameter toggle the description is otherwise sufficient.

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% — signal_id is documented in the schema but pinned is not. The description compensates by defining pinned=false as the unpin action (default true), giving the otherwise-undocumented parameter concrete meaning.

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 (pins) and resource (a signal), plus the inverse action via pinned=false. It does not differentiate itself from the sibling pin_digest, which shares the same verb, so an agent must infer the target distinction from the name alone.

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 the tool is used (to pin or unpin) and that the effect is team-wide, but it offers no explicit when-not guidance or named alternative despite the near-identical sibling pin_digest. Usage is 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?

'A new rating replaces your old one' indicates upsert semantics, but the description contradicts the destructiveHint=true annotation by not flagging that this is a destructive overwrite of prior rating state. Other behaviors (auth, whether removing a rating is possible) are unstated.

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, front-loaded with the primary action, zero 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?

Output schema exists so return values needn't be described, but for a destructive-rated mutation the description omits any permission or effect context and gives no clarity on whether score and comment can be cleared.

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 67% and covers digest_id and comment; the description adds no meaning about the score/comment combination semantics beyond what's already implied by 'or both'.

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 (scores) and resource (a digest) plus the 1-5 range, distinguishes itself from siblings like rate_signal and add_digest_note by acting on digests with a numeric score.

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?

Implies usage from 'or both' and 'replaces your old one' but doesn't say when to rate vs use add_digest_note or get_digest, nor 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 destructiveHint=true and idempotentHint=true, and the description usefully explains the replacement semantics ('A new rating replaces your old one'), which contextualizes idempotency. However, it does not disclose the write/destructive nature of re-rating or what the old rating's removal implies, so it adds only partial behavioral context on top of the annotations.

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

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

Three short sentences, front-loaded with the purpose and followed by the conditional field guidance and replacement rule. No filler, though the opening phrasing is a touch indirect.

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 needn't be explained, and the description covers the main conditional behavior. Minor gaps remain around whether reasons is mandatory when useful=false and how re-rating interacts with prior data, but overall it is adequate for a 4-param 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 coverage is 50%: signal_id and reasons are documented in the schema itself, while useful and comment are not. The description adds value by tying reasons and comment to the useful=false case, but adds nothing for the required 'useful' boolean, so it only partially compensates.

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

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

The description states a specific action (rate/tell whether a signal was useful) on a specific resource (a signal), which distinguishes it from the sibling rate_digest. It's slightly indirect by framing it as 'Tells Debriefing whether' rather than 'rate the signal', but an agent can identify the operation.

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 conditional guidance for the negative case ('For not useful, add reasons and a comment'), which implies when to supply optional fields, but it never states when to use this tool versus rate_digest or other rating-adjacent siblings, nor any 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?

Adds valuable context beyond annotations: it consumes a limited resource (weekly research allowance) and requires admin privileges, neither of which is captured in the annotations. Annotations declare non-readOnly and non-destructive, consistent with a refresh operation. Missing detail on what 'refresh' entails or failure modes, but the resource and auth disclosures are meaningful.

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, each carrying unique information (action, timing, cost, restriction). Zero filler; front-loaded with the primary action.

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?

Output schema exists, so return values need not be explained. Description covers the key behavioral facts an agent needs (cost, auth, timing) for a single-parameter mutation tool. Could mention idempotency behavior briefly, but annotations plus schema largely cover it.

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

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

Schema coverage is 100%, so the idempotency_key parameter is fully documented in the schema. The description adds no parameter details, which is acceptable given the schema does the heavy lifting. Baseline 3 per rules.

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 ('Refreshes the research on the core watchlist') and clarifies timing ('now, instead of at the next cycle'). Distinguishes from sibling research_competitor by scoping to the watchlist, but doesn't explicitly name the 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?

Explains when to use it ('now, instead of at the next cycle') and states the cost ('one update from the weekly research allowance') and restriction ('Admin only'). No explicit exclusions or named alternatives, but the context is clear enough for routing.

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

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

Annotations cover the safety profile (destructiveHint=true, idempotentHint=true), but the description adds what the annotations cannot: that monitoring stops while history is retained, and that the operation is gated to admins on a paid plan. That is exactly the kind of consequence and authorization context an agent needs before firing a destructive call.

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, zero filler, with the effect and the access constraint front-loaded rather than buried. Every clause carries information the agent needs.

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

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

With an output schema present, return values need no explanation, and the description covers effect, history retention, and authorization. Nothing required to invoke this correctly 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 already carries its own guidance ("An id from list_competitors"). The description adds only the implication that exactly one competitor is targeted, so the schema does the heavy lifting — baseline 3.

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 ("Takes one core competitor off the watchlist") and the word "core" implicitly scopes it against the sibling remove_monitored_page. An agent can distinguish this from add_competitor, rename_competitor, and remove_monitored_page without opening a schema.

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

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

Gives a clear precondition set — "Admin only, on a paid plan" — which tells the agent when this call is even permissible. It does not explicitly name alternatives or spell out a when-not case beyond the plan/permission gate, so it falls short of a full 5.

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, idempotentHint=true, and readOnlyHint=false, so the mutation profile is covered. The description earns credit by adding the authorization and billing constraints (admin-only, paid plan) that the annotations don't express, though it never says what actually happens to collected data or history.

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 with the action first, then the identification mechanism, then the gating constraints. Nothing is padded 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?

With an output schema present, return values need no explanation, and the description covers action, identification, and permissions for a 3-parameter tool. The one residual gap is that it doesn't clarify whether page_id and url are alternatives or both accepted alongside competitor_id.

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 67% (url is undocumented in the schema), and the description compensates by telling the agent the page can be named 'by page_id or url'. That is real added meaning, since the schema never expresses the either/or identification choice.

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 ('Stops watching a page') and scopes it to 'a page that someone added on a core competitor', which subtly separates it from remove_competitor in the sibling list. It stops short of explicitly naming the inverse tool, but the operation 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?

It states the prerequisites plainly ('Admin only, on a paid plan'), which is exactly the kind of gating an agent needs before calling. It doesn't spell out when-not to use it or point to an alternative, so it falls short of a 5.

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 destructiveHint=true and idempotentHint=true, but the description doesn't explain what makes it destructive or how idempotency manifests. 'Admin only' adds a permission requirement not in annotations, which is valuable 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?

Two short sentences that are front-loaded with the core action and constraint. No wasted words.

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

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

Given the mutation tool complexity with annotations, an output schema exists so return values needn't be explained. However, the description lacks details on what 'display name' means, potential side effects, or why it's destructive, leaving some 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 50%, with competitor_id described as 'An id from list_competitors' in the schema but no parameter details in the description. The description doesn't compensate for the undocumented 'name' 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?

States a specific verb ('Changes') and resource ('display name of one tracked competitor'). Distinguishes from sibling remove_competitor and add_competitor by focusing on the rename operation.

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 'Admin only' note provides a usage constraint, but there's no guidance on when to use this vs alternatives like add_competitor or remove_competitor. The condition is implied but not 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds value beyond them: it discloses that external sources are read, that an allowance is consumed, and that admin privilege is required. It stops short of describing latency or what happens when the allowance is exhausted.

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 the precondition, with no filler. The colon construction is slightly dense but 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?

With an output schema present, return values need no explanation, and the description covers the precondition, auth requirement, and quota cost. Only the quota-exhaustion behavior and expected duration are left unstated.

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%, including a full explanation of the idempotency_key retry contract, so the schema already carries parameter meaning. The description adds no syntax or format detail for competitor_id or the key, 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 names a specific verb and resource ('Starts the first research on one core competitor') and immediately narrows the scope with the precondition 'that has none yet'. This distinguishes it from siblings like add_competitor and refresh_watchlist, which an agent could otherwise confuse with it.

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 clear use condition (only for competitors with no existing research) plus an access gate (Admin only) and a cost (one weekly research update). It does not name an explicit alternative for re-researching an already-researched competitor, but the precondition implies this tool is not the one to use there.

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 non-read-only, destructive, idempotent, and closed-world behavior, so the bar is lower. The description adds real value beyond that by disclosing the private visibility scope ("Only you see your saved signals") and by explaining that the destructive-looking operation is actually a reversible toggle via saved=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 sentences, zero filler, with the core action and its inverse front-loaded and the privacy caveat placed last. 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 return values need no explanation, and the description covers both parameters plus the visibility scope. It is close to complete for a simple two-parameter toggle, with only cross-tool routing left implicit.

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

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

Schema coverage is only 50%: signal_id is documented in the schema ("An id from search_signals or what_changed"), but `saved` has no schema description. The description compensates by defining saved=false as the removal switch, covering the undocumented parameter and adding meaning beyond the bare boolean.

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 (save a signal) and additionally discloses the inverse operation (removal via saved=false), which is more than a restatement of the title. It doesn't explicitly name or distinguish itself from signal-adjacent siblings like pin_signal or rate_signal, so an agent must infer the difference from semantics alone.

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 dual direction (save vs. unsave) is stated, which implies when each mode applies, but there is no explicit guidance about when to use this versus pin_signal or rate_signal, nor any prerequisites. Usage is 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: it is a public library search requiring no account, and results are ordered best match first.

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 tightly written sentences with no filler. The purpose, return shape, and account requirement are front-loaded and each sentence contributes useful 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 public search tool with an output schema and rich annotations, the description covers what is searched, what is returned, ordering, and the no-account requirement. It omits any explanation of the limit parameter's default behavior, but otherwise an agent has enough to call it correctly.

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

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

Schema coverage is 67%; query and collection have schema descriptions, and the description's list of content types loosely maps to the collection enum. The limit parameter remains undocumented in both schema and description, and no additional syntax or default behavior is supplied.

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: 'Searches the public competitive intelligence library on debriefing.io' and enumerates the content types covered. It does not explicitly differentiate itself from related sibling tools such as search_public_briefs or search_signals, so it falls short of the sibling-distinguishing clarity required 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?

The description implies use for public-library searches and notes 'Needs no Debriefing account,' which is helpful context. However, it gives no explicit when-to-use guidance against alternatives like search_public_briefs or search_signals, leaving selection largely 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 already establish the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful context beyond that: newest-first ordering, that briefs are dated and cite public sources, and that no Debriefing account is required.

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

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

Four tight sentences, front-loaded with purpose, then filtering, then the no-arg default, then the auth note. No filler.

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

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

With an output schema present and rich annotations, the description only needs to supply intent and usage context, which it does: what is searched, how to filter, default behavior, and the no-account requirement. Nothing an agent needs to invoke it 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 coverage is 67% and the description clarifies that the company parameter accepts a name, slug, or domain, extending the schema's examples. The limit parameter is left to the schema, whose max of 50 is self-explanatory.

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 (Searches) and resource (competitive briefs Debriefing publishes about named companies), plus the source domain and default ordering. This distinguishes it clearly from the singular get_public_brief sibling.

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?

Explains how to filter (by words and by company name/slug/domain) and that no arguments returns the newest briefs, plus that no account is needed. It never explicitly routes to alternatives like get_public_brief or other search_* tools, so it stops short of the 5 bar.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the newest-first ordering and that results carry source evidence, but says nothing about pagination, the 'open' vs other signal states, or the default/max result count.

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, zero filler: purpose and ordering first, then the filter set, then the usage trigger. Every sentence 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 spelled out, and the definition covers the domain concept, filters, ordering, and usage trigger. The remaining gap is that limit (min 1, max 50, no default stated) is unexplained anywhere.

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 60% (limit and severity lack descriptions), so the description does useful compensating work: it names competitor_id, severity with its low/medium/high levels, a text query, and a since time. Only the limit parameter is left entirely undocumented in both places.

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 ('Searches open signals') plus ordering ('newest first'), and defines the domain term 'signal' as a competitor move with source evidence so an agent knows what is being returned. It does not explicitly contrast itself with the nearby sibling what_changed, so sibling differentiation is only partial.

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 trigger ('Use it when the user asks what a competitor changed') and enumerates the filter axes available. There are no stated exclusions or named alternatives among the many sibling search/list tools, which keeps it short of a 5.

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 (destructiveHint=true, idempotentHint=true), it adds genuinely useful context: it is a partial update ('only the channels you send change'), requires admin rights, and depends on a paid plan plus a Slack connection. It does not explain behavior when a parameter is omitted, but the added auth/dependency details are substantial.

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

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

Four short, front-loaded sentences with no filler; the core effect comes first and prerequisites and constraints follow. Every sentence earns its place.

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

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

For a simple two-boolean mutation with annotations covering the safety profile and an output schema covering returns, the description supplies the missing operational context (admin-only, Slack dependency, scope of change). Nothing essential to correct invocation 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 coverage is 0% and the two booleans are otherwise undocumented, so the description carries the load. It maps 'email' and 'Slack' to the two parameters and clarifies the boolean semantics ('on or off'), compensating well for the coverage gap, though omission/default behavior is unstated.

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: it turns delivery of a finished cycle on/off for email and Slack. It is clearly the mutation counterpart to the sibling get_delivery_settings, though it never names that 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?

It states clear prerequisites (admin only; Slack requires a paid plan and an in-app Slack connection) and a scoping rule ('only the channels you send change'). It stops short of explicitly naming when to use this versus get_delivery_settings or any alternative.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=true), so the bar is lower. The description adds genuinely useful context beyond them: admin-only permission requirement and paid-plan gating, plus the plan-driven validation of allowed cadences. It does not explain why the change is flagged destructive or what the cadence change affects operationally.

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, zero filler, and the core action is front-loaded before the gating information. Every sentence carries distinct information.

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

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

An output schema exists, so return values need no explanation, and the description covers purpose, allowed-value discovery, and access prerequisites. The one gap is that destructiveHint=true is unexplained for what looks like a benign settings change, leaving the agent without impact context.

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's schema already documents that the value comes from get_delivery_settings, so baseline is 3. The description echoes the same pointer but adds no new format, default, or validity detail beyond what the schema provides.

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 ('Sets how often Debriefing runs a monitoring cycle') that clearly distinguishes it from the read-only sibling get_delivery_settings and from set_delivery_channels. An agent knows immediately what the tool mutates.

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 real selection context: it names get_delivery_settings as the source of allowed cadence values and states prerequisite conditions (admin only, paid plan). It does not explicitly say when not to use it versus siblings like set_delivery_channels, but the conditions that gate usage are clear.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description meaningfully extends them: 'Only the fields you send change' (partial-update semantics), 'The lists replace the old lists' (replace vs. merge, a critical and non-obvious behavior), plus the admin-only and brief-lock constraints. This is substantive behavioral context beyond the structured fields.

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

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

Five short, front-loaded sentences with zero filler. The most consequential constraint (partial update and list replacement) comes first, followed by access and locking conditions. Every sentence earns its place.

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

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

With an output schema present, return values need no explanation, and the description covers the mutation semantics, auth requirement, and lock condition for a 16-param write tool. The only gap is per-field meaning for the many undocumented parameters.

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

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

Schema description coverage is only 25%, so most of the 16 fields (name, industry, website_url, etc.) are undocumented in the schema. The description compensates with the two most important semantics — partial update and list replacement — but does not clarify any individual field's meaning. Baseline 3 is appropriate.

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

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

The description names a specific verb ('Changes') and resource ('fields of the workspace's company profile'), so an agent can immediately tell it apart from the read-only get_company_profile sibling. It stops short of explicitly naming an alternative, but the mutation verb 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?

It supplies real usage constraints: 'Admin only' states a permission prerequisite and 'Locked while the first brief runs' states a timing restriction, both of which help decide whether the call can succeed. However it never says when to prefer this over a sibling or when not to call it, leaving that 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?

Goes well beyond the annotations: it discloses partial-update semantics ('Only the dimensions you send change; an empty list clears one'), which explains why destructiveHint=true matters, plus authorization requirements, a per-workspace rate cap, and a state-based lock. This is the kind of context an agent cannot infer from readOnlyHint/destructiveHint alone.

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?

Five tight clauses, front-loaded with the action and side effect, then constraints in descending importance. Every sentence carries information; nothing is filler.

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

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

With an output schema present, return values need not be explained, and the description covers the mutation, auth, rate cap, and lock. The only soft spot is 'Locked while the first brief runs', which is slightly cryptic about when the lock releases.

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 each dimension has a label, so the schema does the naming. The description adds the critical merge semantics ('empty list clears one') not present in the schema, but it does not clarify the format of the list values (e.g. free strings vs controlled vocabulary) for the eight dimension arrays.

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 ('Sets the ideal customer profile') and adds the downstream side effect ('re-reads how much each tracked competitor overlaps it'), which no sibling does. An agent can distinguish this from update_company_profile or add_competitor from the text alone.

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 real preconditions: 'Admin only', 'Counts toward a daily cap per workspace', and 'Locked while the first brief runs'. These tell the agent when the call will be rejected, though no alternative sibling (e.g. update_company_profile) is named for the non-admin or locked 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: that results span three entity types and are scoped by the 'since' time, which is what makes this tool distinct from a plain list.

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 what it returns and followed by the use case; nothing wasted. The trailing 'such as since the user's last visit' is mildly redundant with 'since a time', keeping 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?

With an output schema present and annotations covering the safety profile, the description only needs to convey scope, content, and intent, all of which it does. Nothing an agent needs to call this correctly 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 (since, limit) are already documented, including that limit caps rows per kind. The description only echoes 'since a time' and adds no format or semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb (Lists) and resource (everything new in the workspace) and enumerates the three record kinds returned: signals, digests, and battlecards. This distinguishes it from the per-type siblings (list_digests, search_signals, list_battlecards) as a cross-entity activity feed.

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?

"Use it to catch up, such as since the user's last visit" gives a clear usage context, and the aggregate scope implicitly frames it against the per-entity list tools. No explicit when-not or named alternative, so it stops short of a 5.

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