NAVIG

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds return-payload context by listing items/specs with slugs, ids, risk, and install state. It does not mention pagination, rate limits, or auth, but the annotation coverage lowers the burden.

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 front-load purpose, safety, alternative routing, and return shape. Every sentence contributes useful information with no filler.

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

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

For a 3-action, 4-parameter read-only catalogue tool with full schema coverage and annotations covering safety, the description supplies scope, alternative routing, and return contents. Even without an output schema, it tells the agent what to expect back.

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

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

Schema description coverage is 100%, and the schema itself documents each action's required parameters and behavior. The description adds no parameter syntax or mapping beyond what the schema provides, so 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 (Browse) and resources (NAVIG Harbor Bay catalogue and installed Blocks), then details the content available including typed inputs, ordered steps, and verify criterion. It distinguishes itself from the sibling tool navig_automation_apply by naming it for acquire/run use cases.

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 declares the tool is read-only and tells the agent to use navig_automation_apply instead when acquiring an item or running a block. This provides clear when-to-use and alternative guidance without exclusions.

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

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

Annotations already declare destructive=true, non-idempotent, open-world, so the safety profile is covered; the description adds real value beyond that by disclosing that it may install content or run steps, that step approvals are required for destructive steps, and that secrets resolve only from env/vault. It stops short of describing rollback or what a failed partial apply leaves behind.

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 what the tool does and the state-changing warning before the prerequisite and return-value notes. Every clause carries information; no filler or 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?

For a dual-action, destructive, 7-parameter tool with no output schema, the description covers the mutation risk, approval prerequisite, secret sourcing, and what is returned (execution receipt or acquisition action). The dry_run behavior and error/partial-failure semantics are left to the schema and annotations.

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

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

Schema coverage is 100% with per-action parameter mapping already documented in the schema, so the baseline is 3. The description adds modest meaning ('step approvals' relate to the approvals array, 'secrets only from env/vault' implies non-secret inputs) but never mentions dry_run, workdir, or the action enum's two modes.

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 two concrete verb+resource pairs (acquire a Bay item, apply an installed Block) end-to-end, and explicitly distinguishes itself from the read-side sibling navig_automation. The '"Harbor Bay item' / 'Block' vocabulary is domain-specific but consistent with sibling tool names, so an agent can still route correctly.

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 when-to-use rule ('Use navig_automation to inspect first') and states the precondition that a Block must be installed with step approvals. It does not spell out when NOT to apply a block (e.g. against an unapproved or uninstalled target), so it stops short of full alternative/exclusion 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered and the description's 'Read-only' is largely redundant. What the description adds beyond structured data is the output contract (returns ports/tabs/tree entries) and the ref handoff to the act router, which is genuinely useful behavioral context for a debug-inspection tool.

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

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

Front-loaded with purpose, followed by the read-only flag, the sibling routing, and the return/ref note. No wasted sentences, though the clauses are dense and a few fragment-style enumerations make it slightly longer than strictly necessary.

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

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

No output schema exists, and the description compensates by naming the return shape (ports/tabs/tree entries) and the ref-to-act pipeline. Combined with the complete per-action enum documentation, an agent has enough to call and chain the tool correctly; only minor gaps remain around pagination or error behavior.

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

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

Schema description coverage is 100% and the enum fully documents each action's required parameters, so the schema does the heavy lifting. The description only alludes to passing a ref to the act router and adds no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb (inspect) and scoped resource (NAVIG-launched Chrome/Edge/Brave/Electron debug browser), then enumerates what can be inspected: live targets, open tabs, accessibility snapshots with refs, and running browsers. It explicitly distinguishes itself from two sibling tools by name, so an agent can route without opening either schema.

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

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

Names both alternatives with the conditions that select them: navig_browser_debug_act for interacting with the debug browser, navig_browser_user for the operator's own browser. The schema's enum further specifies per-action semantics, so the when-to-use decision is fully covered.

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 destructive=true and readOnly=false, but the description adds concrete context they don't carry: injected scripts persist until explicitly removed, and login consumes a real vaulted credential that is never returned. It also flags the whole tool as state-changing/high-risk and notes that the result is a dispatch result requiring re-snapshot to confirm. Missing only deeper detail like failure modes or per-action side effects.

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

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

Front-loaded with the action list, then the risk disclosure, then the sibling routing and return/verify note; every sentence carries information. The action enumeration slightly duplicates the schema enum, but it functions as a useful triage summary rather than padding.

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

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

With no output schema, the description usefully states what comes back ('the dispatch result') and how to confirm it ('re-snapshot to verify'). Combined with the risk disclosures for inject/login, an agent has enough to call it correctly, though per-action failure behavior and the destructive implications of stop/force_restart are left to the schema.

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

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

Schema description coverage is 100% and the action enum embeds the required-parameter mapping and per-action semantics, so the schema does the heavy lifting. The description only restates the action groupings at a high level, adding no syntax or format detail beyond what structured data provides. 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?

States a specific verb (act) and resource (NAVIG-launched debug browser), then enumerates the action families so an agent knows the full surface covered. It explicitly distinguishes itself from the sibling navig_browser_debug, which is the inspection/refs tool, so the two can be told apart without opening schemas.

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?

Offers a clear routing rule: 'Use navig_browser_debug to inspect and get refs first,' plus a post-action rule to 're-snapshot to verify.' That is real when-to-use guidance with a named alternative. It does not, however, contrast against the other browser sibling (navig_browser_user) or say when NOT to use this high-risk path.

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 destructive/openWorld/non-idempotent, and the description adds genuine context beyond them: the first console/network call starts capture, screenshots write a file to disk, and act runs under a visible overlay. The schema further discloses that dialog handling, password/card typing and uploads require user confirmation. It stops short of describing rate limits, session lifetime, or failure modes.

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

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

Three sentences, front-loaded with the capability list, then routing guidance, then the return shape. Every clause carries information; it is dense but not padded, and sized appropriately for a ten-action tool.

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

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

No output schema exists, so the description must cover returns, and it does at a useful level ('tab ids, page text/tree, capture entries, or per-step results'). Combined with a fully documented schema for a 21-parameter multi-action tool, the main residual gap is lifetime/session-management guidance around release.

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 action enum carries exhaustive per-action required-parameter and behavioral documentation, so the schema does the heavy lifting for all 21 parameters. The description only paraphrases the action families it already lists; baseline 3 is correct when structured fields are this complete.

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 set and resource ('the operator's own browser through Dock') and enumerates the capability families (tabs, snapshot/text, console/network, screenshot, act). It explicitly distinguishes itself from the sibling navig_browser_debug and states it never silently falls back to it, so an agent can route without opening either schema.

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

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

It names the alternative tool explicitly ('Use navig_browser_debug for a NAVIG-launched debug browser') with the condition that selects it, and reinforces the exclusion with 'this never silently falls back to one'. It does not, however, mention navig_browser_debug_act or any guidance on choosing among the ten internal actions from the description itself.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is settled. The description adds genuinely useful behavior beyond that: capabilities vary per installed connector, unsupported providers are refused, and the return format is either provider status or items with native ids reusable by fetch/act.

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 dense sentences that front-load the core purpose, then the write alternative, then the return contract. No filler or restated annotation boilerplate.

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

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

With no output schema, the description compensates by describing what comes back (provider status or matching items with native ids). The only minor gap is that it doesn't mention limits/pagination, which the schema constrains but doesn't explain behaviorally.

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 action/provider semantics (including per-action required params and supported providers) are fully documented in the schema itself. The description adds no parameter-level 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?

States a specific verb (read) and resource (connected provider accounts) and enumerates representative providers so the agent knows the surface area. It explicitly differentiates itself from the sibling navig_connectors_act, which handles writes.

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

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

Clear on the read use case and names the alternative ('Use navig_connectors_act to change provider data'), which routes the agent correctly on the read/write boundary. It stops short of explaining which of the four actions to pick in which situation, leaving that to the schema.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context: approval is required, unsupported actions are refused rather than silently applied, and the shape of the result (success + affected resource, or success:false with reason).

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

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

Three compact sentences, front-loaded with purpose, then safety guidance, then the routing hint, and finally the return contract — no filler or repetition beyond the necessary action enumeration.

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

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

For a destructive, open-world mutation tool with no output schema, the description covers everything an agent needs: scope, approval requirement, prerequisite lookup step, failure semantics, and return shape. The per-action payload details are fully delegated to a high-coverage schema.

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

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

Schema description coverage is 100% and the enum/description fields already explain action_type support rules, the provider enum, and resource_id omission for create/send. The description mirrors but does not extend that documentation, 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?

Opens with a specific verb+resource ("Change data in a connected provider account") and enumerates the exact write operations (reply/create/update/delete/archive/label/send/move). It also distinguishes itself from its sibling navig_connectors by positioning that tool as the read/discovery step.

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

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

Gives explicit usage context (state-changing, dangerous, approval required) and routes the agent to the alternative when the resource id is unknown: "Use navig_connectors to find the resource id first." The condition that selects the sibling is stated, not 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description's 'Read-only' restates it. It does add value beyond annotations by describing the shape of the response (names, addresses, paths, status) and the catalogue-availability caveat, which 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 with zero filler, and the core resource scope is front-loaded before the routing and return-shape notes. Every clause 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?

With no output schema, the description compensates by naming the returned entity fields. Combined with the read-only annotation and the full action documentation in the schema, an agent has everything needed to select and invoke this tool 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 description coverage is 100%, and the action enum already documents the required parameter per action in full detail. The description's 'pass a name to host_info/app_info' merely repeats what the schema states, adding no new syntax or constraint, so baseline 3 applies.

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

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

States a specific verb (inspect) and enumerates the exact resources covered: SSH hosts, apps, recent errors/context, and database connections. This makes it trivially distinguishable from navig_knowledge, navig_runtime, and the other catalogue siblings, which have wholly different resources.

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: use navig_knowledge for documentation and navig_runtime for missions, and flags that navig_run_command only exists in the full catalogue. That is explicit when-to-use and when-to-use-something-else guidance naming concrete alternatives.

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 closed-world, so the safety profile is covered; 'Read-only' is largely redundant. The description does add value beyond annotations by disclosing the return shape ('matching passages/pages with their source path') and the Space access guard, which is not in 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 sentences, front-loaded with the capability before the routing and return details; little waste. The 'Read-only' sentence duplicates an annotation and is the one element that does not earn its place, keeping it below a 5.

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

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

For a complex eight-action tool with no output schema, the description gives the return format and the action-selection cues, while the action enum carries the per-operation detail (including the guard on space_read). An agent has enough to select and call correctly, though a brief note on pagination/limit behavior would close the remaining gap.

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

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

Schema coverage is 100%, and each parameter's schema entry already documents which actions consume it via 'Used by:'. The description's hint ('pass a path to read_wiki_page, or a Space id to the space_* actions') only restates that mapping at a coarser granularity, so 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 states a specific verb pair and resource ('Search and read NAVIG's local knowledge') and enumerates the three content types: product documentation, wiki pages, and Space-linked files. It also names the sibling tools it is not (navig_recall, navig_fleet), so an agent can distinguish 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?

Explicit routing is given for two alternatives: navig_recall 'for what was said or decided earlier' and navig_fleet 'for infrastructure inventory'. That is clear when-to-use/when-not guidance. It stops short of covering the remaining siblings (navig_web, navig_memory), so it is not fully exhaustive.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so 'Read-only' is partly redundant, but the description adds real value with no output schema present by describing the return shapes (facts with ids and scores, or the four count fields). It doesn't mention rate limits, pagination, or scoring semantics, keeping it short of 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 tight sentences, front-loaded with what the tool does and its return shapes, then the sibling routing. Nothing is wasted and no sentence merely restates 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 no output schema, the description correctly fills the gap by stating return shapes for both actions, and annotations cover the safety profile. Minor gaps remain: the limit default of 10 and any behavior when no facts match are left to the schema and inference.

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 enum already documents that retrieve requires 'query' and stats requires none, so the schema carries the parameter burden. The description's mention of counts versus matching facts implicitly maps to the two actions but adds no syntax or format detail for query/limit, so the baseline 3 holds.

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 (read) and resource (durable key-fact memory) and describes the two result shapes: matching facts with ids/scores, or counts. It cleanly separates itself from navig_memory_update (writes) and navig_recall (conversation history) without the agent needing to open 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?

Explicitly routes the agent to alternatives: navig_memory_update for create/change/retire, navig_recall for conversation history. That covers the main when-to-use decision, though it doesn't spell out conditions for choosing 'stats' vs 'retrieve' beyond the action enum.

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=false and readOnlyHint=false, but the description adds material context beyond them: the operation is 'audited', the return carries a fact id and status, and 'forgetting is a soft delete' — a semantic nuance an agent would otherwise have to infer from the schema. It is strong value-add without contradicting the destructive annotation.

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 mutation scope, then the read-first routing, then the return/soft-delete caveat. Every clause carries information and nothing is repeated from structured fields.

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

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

There is no output schema, so the description carries the burden of describing returns — and it does ('Returns the stored fact id and status'). Combined with annotations covering the safety profile and the schema covering per-action parameters, an agent has everything needed to call this 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% and the action enum plus per-action required-parameter documentation is already exhaustive in the schema, so the baseline is 3. The description restates the write/soft-delete framing but adds no syntax or format detail the schema does not already carry.

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 specific verbs (create, update, soft-delete) and the precise resource (a durable key fact in NAVIG memory). It explicitly distinguishes itself from the sibling navig_memory by directing reads there, so an agent can separate the write tool from the read tool 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?

It states a concrete usage rule — 'Use navig_memory to read facts first' — which routes the agent correctly against the closest sibling. It lacks explicit when-not-to-use guidance or mention of alternative paths for each of the three actions, so it stops short of full routing 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 already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description only needs to add context. It does: results are always citation-backed, records are returned with ids, and those ids/citations chain into get/related/timeline/source_excerpt. It does not mention rate limits, project-scoping effects, or result caps beyond what the schema states.

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

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

Three sentences with no filler: purpose first, safety and routing next, return-and-chain behavior last. Every sentence carries information the agent needs, and the verb leads the description.

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

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

For a 15-parameter, 10-action tool with no output schema, the description is nearly sufficient: it states the result shape (records with ids and citations) and the follow-up path. Deeper per-action detail lives in the enum, which is acceptable, though a note on search-vs-raw fallback behavior would close the remaining gap.

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

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

Schema description coverage is 100% and the schema even maps required params per action, so the description cannot add much. Its one contribution ('pass an id to get/related/timeline or a citation to source_excerpt') restates the schema's own 'Used by' annotations rather than adding new meaning, which is the baseline 3 case.

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?

Front-loads a specific verb (Search) and resource (the owner's recorded past), then enumerates the content classes it covers (conversations, decisions, tables, open questions, forgotten ideas, source excerpts). It explicitly differentiates from sibling tools by naming navig_knowledge and navig_memory, so an agent can select it 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?

Names two alternatives and the conditions that select them ('navig_knowledge for docs/wiki and navig_memory for durable facts'), which is strong alternative routing. It stops short of a full when-not statement (e.g., no guidance on when to fall back to raw browsing), so it is clear context rather than complete exclusions.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description redundantly confirms 'Read-only' but adds genuinely useful context by describing the return shape (ids and state) in the absence of an output schema. It does not mention pagination or the limit default (schema says 20 vs 50, an inconsistency left unexplained).

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 dense sentences, front-loaded with the resource and its scope, then the sibling routing, then return shape. The final clause ('pass a node_id to trust_score or a mission id to receipt listing') is slightly garbled in mapping parameters to actions, costing it a point, but nothing is padded.

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

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

For a 5-parameter, 4-action tool with no output schema, the description covers what it reads, the write alternative, and the general return format. It omits the limit/pagination behavior, which the schema documents inconsistently (default 20 vs 'default 50'), leaving a small gap.

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

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

Schema description coverage is 100%, so the enum's per-action required-parameter notes already document node_id/mission_id/status/limit usage. The description's 'pass a node_id to trust_score or a mission id to receipt listing' largely restates the schema's 'Used by:' annotations rather than adding new semantics, so the 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?

States a specific verb and resource ('Read NAVIG runtime state') and enumerates the exact entities covered: Nodes, Missions, ExecutionReceipts, TrustScore. This cleanly separates it from navig_runtime_action, which is its write counterpart.

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

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

Explicitly names the alternative and the condition that selects it: 'Use navig_runtime_action to create or advance a Mission.' Combined with the 'Read-only' framing, an agent knows this is the query path and the sibling is the mutation path without further 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 declare destructive/state-changing behavior and non-idempotency, so the bar is lower. The description adds genuinely new context: the approval requirement for mission_action and the fact that it returns the Mission with its new state, which the agent cannot infer from annotations 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?

Three dense sentences, front-loaded with the core action, followed by the routing/approval caveat and return shape. Every clause carries load with no filler.

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

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

For a mutation tool with a fully documented 8-param schema and no output schema, the description supplies the missing pieces: read-before-write routing, approval requirement, and the return shape. Nothing needed to invoke it correctly is absent.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters and the action enum. The description repeats the transition vocabulary but adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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 specific verbs and resource: create a Mission or advance its state, and enumerates the exact transitions (start/succeed/fail/cancel/timeout). It distinguishes itself from the read-only sibling by pointing to navig_runtime for reads, so an agent can route without opening schemas.

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 directs the agent to 'use navig_runtime to read missions and receipts first' and flags that mission_action requires approval. This gives clear context and a prerequisite, though it stops short of full when-not-to-use exclusion criteria.

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 openWorldHint=true, readOnlyHint=false, and destructiveHint=true, but the description adds meaningful context beyond them: outbound network access, Firecrawl billing, and short-lived crawl jobs. It also states the return types, which helps set expectations for a potentially costly or state-changing operation.

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

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

Three compact sentences front-load the primary actions and follow with operational constraints and alternatives. Every clause contributes relevant information without redundancy or 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?

Despite 9 parameters and 5 actions, the description covers the essential selection context: public web vs authenticated/local alternatives, network access, billing, crawl job behavior, and return types. The schema handles parameter details, and no output schema exists, so the description is complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the action enum description documents required parameters per action. The description adds no additional parameter-level syntax or mapping beyond what the schema already provides. Baseline 3 is appropriate when structured fields fully carry parameter semantics.

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

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

The description names the core actions (search, fetch, Firecrawl search/scrape/crawl) and the resource (public web, Firecrawl). It explicitly distinguishes from sibling tools by naming navig_connectors and navig_knowledge as alternatives for authenticated and local data. An agent can identify exactly what this tool does without opening the schema.

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

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

It provides explicit alternatives for different data sources: 'Use navig_connectors for authenticated provider data and navig_knowledge for local docs.' This tells the agent when to choose those siblings instead, and the opening line implies the public-web use case for this tool. The billing and job notes add operational context that shapes invocation decisions.

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