Blackbook Protocol Advisor

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

Annotations already flag destructive/non-read-only behavior, and the description adds the concrete external consequence ('can file on a government portal') plus the one-time token requirement. This meaningfully supplements the annotations without contradicting them.

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 written sentences, with the critical precondition front-loaded before the consequence. No filler or redundant restatement of the schema.

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 high-stakes submit action, the description covers the required precondition, the human approval mechanism, and the potential legal filing impact. With an output schema present and full parameter documentation, 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?

Input schema covers both parameters with descriptions and examples at 100% coverage. The description adds little beyond restating that confirmationToken is one-time and originates from prepare_submit_confirmation, which the schema already conveys.

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 action ('Submit the current portal form') and a mandatory precondition (a valid confirmationToken from prepare_submit_confirmation). The warning that it 'can file on a government portal' distinguishes it as a high-stakes finalization tool versus drafting/filling 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 specifies when this tool may be invoked: only after the human provides a valid one-time token from prepare_submit_confirmation. This gives clear sequencing and a human-in-the-loop gate, though it does not name alternative tools to avoid.

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

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

No meaningful behavioral hints are provided by the annotations (all false), so the description must carry the burden. It does disclose that the output is 'preparation notes' labeled as a 'Protocol guide', which clarifies the artifact produced. However, it does not disclose whether anything is persisted, submitted, or whether the tool merely returns draft text, leaving some behavioral ambiguity.

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

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

The description is a single efficient sentence with no filler. It front-loads the core purpose, names the relevant form families, states the input precondition, and gives the output framing—all in one concise statement.

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 a nested intake object and an output schema, so the description does not need to restate return values or full field semantics. The main gap is that 'Protocol guide' and 'professional-review questions' are somewhat specialized jargon that is not expanded, but the core selection context is clear enough for an agent to decide when to invoke 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?

Schema description coverage is 100%, and each intake property has an example, so the schema already explains the parameters well. The tool description adds the connection between the form family list and the drafting scope, but it does not add deeper meaning about how to populate intake or interpret formFamily. 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 uses a specific verb and resource: 'Draft preparation notes' for TRS, IHT100, IHT400, and related professional-review questions. It also specifies the input context ('from a completed intake') and output framing ('Protocol guide for solicitor execution'). However, it does not explicitly differentiate itself from siblings like generate_review_bundle or prepare_portal_fill, so it stops short of a 5.

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

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

The phrase 'from a completed intake' implies that this tool should be used after intake has been completed, but it provides no explicit guidance on when to choose this over alternatives such as generate_review_bundle or prepare_portal_fill. No exclusions or alternative names are given, so the usage guidance is implied rather than stated.

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

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

Annotations already include destructiveHint and idempotentHint, but the description adds valuable specifics: credentials are not persisted and repeated calls after expiry are safe. This enriches the annotation data without contradicting 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?

Three short sentences deliver the core action, a credential-safety detail, and idempotency guidance without any filler. The most important information 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?

For a single-parameter teardown tool with rich annotations, a full schema, and an output schema, the description covers all essential behavior. Nothing missing would prevent an agent from calling 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 the schema already fully documents sessionId and provides an example and provenance. The description adds no additional parameter-level meaning beyond referencing 'same id', which matches the schema.

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

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

The description uses a specific verb ('Tear down') and resource ('assisted browser session'), making the action unmistakable. It clearly differentiates from sibling start_browser_session by describing the teardown 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?

The description implies when to use it—after an assisted browser session—and adds useful guidance about calling it again after expiry. It does not explicitly name start_browser_session as the alternative or state the exact workflow position, but the pairing is evident from context.

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 readOnly and idempotent annotations, the description discloses that the tool inspects the current page without navigating and reports an inferred, non-definitive signedInLikely signal. This adds useful behavioral context about the summary's nature and limitations.

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

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

The entire description is one efficient sentence that front-loads the action and scope, then lists the returned dimensions with no filler or unnecessary repetition.

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

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

With one well-documented sessionId parameter, an output schema present, and strong readOnly/idempotent annotations, the description provides everything needed for correct invocation. Session dependency is implied by 'current portal page' and the required sessionId.

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 only parameter, sessionId, is already fully described in the schema with an example. The tool description adds no parameter detail, so the baseline 3 applies.

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

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

The description begins with a specific verb ('Summarise') tied to a concrete resource ('current portal page') and enumerates the exact contents of the summary: URL, text excerpt, fillable fields, Protocol hint, and signedInLikely. This clearly separates it from siblings like open_portal or list_fillable_fields.

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 indirectly implies usage on the current portal page, but it does not explicitly say when to prefer this summary over sibling tools such as list_fillable_fields or prepare_portal_fill. No exclusions or alternative routing 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 indicate the tool is not read-only and not destructive; the description adds meaningful behavioral scope by stating that only non-secret fields are filled and explicitly prohibing secret-type values. This goes beyond what the annotations alone communicate and helps set accurate expectations for a mutating form-fill 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?

The description is two tight sentences with no filler. The core action is front-loaded, and the exclusion list is compact yet comprehensive. Every word 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?

Given the small parameter count, full schema coverage, and existing output schema, the description plus schema are sufficient for correct invocation. It lacks some context about when to prefer this tool over siblings, but that gap is captured in usage_guidelines rather than making the tool description incomplete.

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 input schema already fully documents sessionId and the fields map. The description largely repeats the schema's wording ('label/placeholder/name', 'non-secret value') without adding new parameter-level meaning, keeping this at the baseline.

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

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

The description clearly states a specific action ('Fill') and resource ('non-secret form fields') and further specifies how fields are identified ('label/placeholder/name'). It also draws a clear boundary by excluding passwords, OTPs, and Companies House auth codes, which helps distinguish it from related sibling tools even though no sibling is explicitly named.

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 usage on a live browser session to fill visible form fields, and the 'Never passwords, OTPs, or Companies House auth codes' statement provides a clear negative constraint. However, it does not explicitly compare with alternatives such as draft_form_answers, prepare_portal_fill, or list_fillable_fields, leaving some routing ambiguity.

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?

All annotations are false, so they provide no safety or side-effect signals, and the description does not compensate. It does not disclose whether the bundle is persisted, whether it involves external requests, how citations are sourced, or what happens if the intake is incomplete. 'Generate' suggests output creation but not the behavioral consequences.

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 core action, names the artifact, states the source state, and identifies the audience. No unnecessary words or repetition of the schema.

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 description is complete enough for a basic call, and the rich nested schema and output schema cover inputs and returns. However, it leaves the notion of 'completed intake' undefined and does not clarify how the bundle relates to the surrounding workflow, which matters given the number of sibling tools.

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 input schema provides detailed per-field descriptions with examples, so the tool description itself does not need to add parameter detail. The description adds no parameter-specific semantics beyond the schema, which is acceptable at the high-coverage baseline.

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

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

The description clearly states a generating action and a distinct resource ('cited professional-review bundle'), with source ('completed intake') and intended audience ('Owner to take to a solicitor or CTA'). It does not explicitly differentiate from sibling tools, but the deliverable is unique enough that an agent can tell it apart from intake, form-filling, and portal tools.

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

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

The phrase 'from a completed intake' implies the tool should only be used after intake is done, but this is not stated explicitly. It gives no direct when-not-to-use guidance or named alternatives, leaving the agent to infer sequencing from the sibling list.

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 read-only, idempotent, and non-destructive behavior, so the safety profile is clear. The second sentence adds a useful domain rule about PSC filings naming individuals rather than the Trust, but no additional operational behavior (e.g., output size, versioning, prerequisites) is disclosed.

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

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

The description is compact and front-loads the core purpose in the first sentence. The second sentence is somewhat tangential but provides useful domain context that helps an agent avoid a likely mistake, so it 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 single-parameter, read-only tool with an output schema, the description supplies the necessary guidance scope and topic examples. It lacks explicit sibling routing, but the first sentence's explicit domain coverage makes the tool reasonably self-contained.

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 schema already describes the single topic parameter with an example, giving 100% coverage. The tool description restates that guidance covers PSC and WebFiling, which aligns with the schema but does not add format detail, allowed values, or behavior beyond it. Baseline 3 applies.

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

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

The description opens with a specific verb and resource in 'Retrieve approved Companies House / PSC / WebFiling guidance.' The scope clearly distinguishes this from sibling tools like get_hmrc_guidance, and the PSC/WebFiling topics further narrow the definition.

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 context is implied by the tool's scope: use when retrieving Companies House, PSC, or WebFiling guidance. However, the description does not explicitly mention when to prefer this over get_hmrc_guidance or other sibling guidance tools, nor does it state 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond the annotations: results are approved rather than live-scraped, and each result includes a title, official URL, and short summary.

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 no filler. The action and scope are front-loaded, and the live-scrape caveat is a single useful clause that 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 one required parameter, one optional parameter, 100% schema coverage, an output schema, and read-only annotations, nothing essential is missing. The description also explains the return shape and data-source caveat clearly.

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 parameters are already documented. The phrase 'trust and inheritance-tax guidance' modestly reinforces the expected topic values, but the description does not add meaning for the optional jurisdiction filter 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?

The description opens with a specific verb and resource: 'Retrieve approved GOV.UK/HMRC trust and inheritance-tax guidance by topic.' It clearly distinguishes the tool from siblings like get_companies_house_guidance, and the caveat 'Not a live scrape of GOV.UK' further differentiates its role.

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 gives clear context: use this for approved/cached HMRC guidance on trust and inheritance tax, and explicitly rules out live scraping. However, it does not explicitly name an alternative tool or provide a when-not-to-use condition beyond the live-scrape exclusion.

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, so the safe read-only behavior is covered. The description adds the 'mandatory' and 'educational / non-advice' framing but does not disclose additional behavioral details such as output structure or side effects, which are partially covered by the output schema.

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

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

Two sentences with no wasted words. The tool's action is front-loaded, and the usage trigger is stated immediately afterward. 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, idempotent, read-only tool with one optional parameter and an output schema, the description fully covers what an agent needs: what it returns and when to call it. No additional context is required.

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%: the only parameter, 'audience', is already described as 'Who will read the boundary line. Example: owner.' The description does not need to add parameter meaning, and it does not attempt to, 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?

The description uses a specific verb ('Return') and a specific resource ('the mandatory educational / non-advice boundary statement'), which clearly distinguishes it from all sibling tools. Even without naming an alternative, an agent can identify exactly what this tool offers.

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 gives an explicit trigger: 'Call when the Owner asks if this is legal advice.' This is clear contextual guidance, though it does not mention exclusions or alternatives. The absence of an alternative is acceptable given the tool's unique purpose.

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, and destructiveHint=false, so the agent knows this is a safe, idempotent read. The description adds the context that this is a 'Protocol checklist' and the 'ordered' nature, which is not in the annotations. It doesn't describe what happens if an invalid module is passed, but the enum schema prevents that. The description aligns perfectly with annotations, so no contradiction.

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

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

The description is three sentences: the first states purpose and when to use, the second clarifies a specific module case, and the third lists modules. The module list is redundant with the schema enum, but the rest is tight and front-loaded. The redundancy is minor and could be trimmed, but it doesn't hurt.

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 tool has only one parameter, an output schema, and rich annotations (readOnly, idempotent, non-destructive), the description fully covers what an agent needs: when to use it, what it returns, and how to select the right module. There's no ambiguity about side effects or safety. The module list is even included redundantly, so completeness is high.

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 schema already documents the 'module' parameter with an enum and an example ('equity_95_5'). The description provides additional semantics by explaining that 'equity_95_5' is for the 95/5 share transfer and should not be a freestyle solicitor checklist, adding meaning beyond the schema's bare validation. This enriches the parameter understanding.

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 ('get') and resource ('module playbook') and clarifies it returns an ordered Protocol checklist. It also contrasts with a freestyle solicitor checklist, making the distinction clear. This neatly separates it from siblings like list_modules or get_skill.

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 opens with 'REQUIRED when coaching setup' and specifies the exact use case (95/5 / share transfer into the Trust), naming a specific module value that should be used. It also lists all valid modules, which is redundant with the schema enum but reinforces correct usage. This is explicit and actionable.

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

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

Annotations already establish read-only, idempotent, open-world behavior. The description adds valuable operational context by noting that MCP cannot launch local browsers and that Browserbase should not be started, which are not visible in 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?

Two sentences front-load the core purpose and then provide actionable presentation and prohibition guidance. Every sentence earns its place with no redundancy.

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

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

For a single-parameter read-only tool with an output schema and rich annotations, the description covers the key operational choices: use the self-serve path, present the URL as markdown, and do not invoke browser automation. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% and the portalId parameter already has an enum and description. The description adds no additional parameter-level meaning, so it meets the baseline but does not exceed it.

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 action ('return the official portal URL plus Protocol checklist'), a resource ('self-serve portal'), and an audience ('the Owner's own browser'). It also distinguishes itself from browser-automation siblings via 'Do not start Browserbase.'

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 clearly establishes the self-serve context and instructs not to start Browserbase, which tells the agent when not to use browser automation alternatives. It does not explicitly name the alternative tools like open_portal or start_browser_session, but the context makes the intended use obvious.

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, and destructiveHint=false, so the safety profile is well covered. The description adds the useful detail that output is markdown, but it does not discuss error behavior or what happens if an invalid name is supplied. This is adequate but not rich.

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

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

The description is a single front-loaded sentence stating the action and output format, followed by a scannable list of names. The list duplicates the schema enum, but the description remains compact and free of 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?

This is a simple one-parameter lookup tool with full schema coverage, safety annotations, an output schema, and a description that states the return format. An agent has all the information needed to select a valid skill and understand what the tool returns.

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 parameter already has an enum, required status, description, and example. The tool description only repeats the list of valid names, adding no semantic meaning beyond what the schema 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?

The description states a specific verb and resource: 'Load a Protocol workflow skill as markdown.' It also enumerates every valid skill name, making the tool's scope unambiguous and clearly distinct from list_skills, which lists skills rather than loads one.

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 usage by naming concrete skills and the schema notes that the name comes from list_skills, but the description itself gives no explicit when-to-use or when-not-to-use guidance. It does not distinguish when get_skill should be preferred over sibling lookup tools like get_module_playbook.

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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful scope detail: it inventories only visible and non-secret controls, implying hidden or secret fields are excluded. No contradiction exists.

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

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

Two sentences deliver the main action, scope, and use case with no filler. The most important constraints ('visible', 'non-secret') are 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?

For a single-parameter read-only tool with an output schema and rich annotations, the description gives all necessary context: what is inventoried, its scope, and how it relates to prepare_portal_fill. Nothing critical is missing.

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

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

The schema covers the only parameter, sessionId, with a full description and example. The tool description does not need to add parameter-level detail, 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?

Description uses a specific verb ('inventory') and names the exact resource scope ('visible non-secret form controls (label/name/type) on the current portal page'). It also points to its downstream consumer (prepare_portal_fill), which clearly distinguishes it from sibling tools like fill_fields.

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 to align prepare_portal_fill keys' provides an explicit intended use case and links to the companion tool. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it for the pre-fill inventory step.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds context by defining what self_serve and assisted mean and by giving the 'ask before starting co-pilot' directive, but it does not disclose return format or side effects. That is acceptable given the read-only annotation, but the additional behavioral context is modest.

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

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

The entire description is one sentence that lists both choices, defines them, and gives a usage hint. It is front-loaded and every word contributes meaning, with no redundancy or fluff.

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, read-only listing tool with an output schema and safe annotations, the description is sufficiently complete. It covers purpose, the meaning of the modes, and a directive on when to use it. The only minor gap is that it doesn't mention how the optional 'preferred' parameter affects the output, but the schema already documents that.

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 a clear description and example for 'preferred'. The main description adds value beyond that by explaining what each enum value (self_serve vs assisted) entails, which helps the agent understand the parameter's meaning more fully.

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 exact resource ('implementation modes') and the verb 'List', and it distinguishes the two modes with brief definitions. This makes it clearly different from sibling listing tools like list_fillable_fields or list_modules.

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

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

The phrase 'Ask before starting co-pilot' provides clear context for when this tool should be used, implying it should present options to the owner prior to co-pilot. However, it does not explicitly name alternatives or state when not to use it, though no direct sibling equivalent exists.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the behavioral detail that modules are returned 'in coaching order', which is useful context beyond the annotations. No contradictions.

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

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

The description is a single sentence with no filler. It front-loads the action and resource, and efficiently conveys the key ordering behavior. Every word 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?

Given the tool's simplicity (one optional parameter, output schema provided, and annotations covering safety), the description covers the essential purpose and ordering. However, it lacks any guidance on when to use this tool relative to sibling list tools, which is a minor gap for full completeness.

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% for the single optional parameter 'query', including an example ('vault'). The tool description does not add any additional parameter information, so it does not go beyond the schema, which fully documents the parameter.

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

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

The description clearly states the verb 'List' and the resource 'Protocol advisor modules', and adds the specific ordering 'in coaching order' which distinguishes it from other list_* siblings. It is specific and 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?

The description provides no guidance on when to use this tool versus alternatives such as list_implementation_modes or list_skills. It does not mention any conditions, exclusions, or related tools, leaving the agent to infer usage context.

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 that this is a safe, read-only, idempotent operation. The description adds useful behavioral context by naming the analytical categories (legal, tax, practical) and example fact patterns (settlor-as-beneficiary, lender consent, offshore, time pressure), which helps the agent anticipate what the call will compute. No contradiction with 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?

One sentence front-loads the core action and output scope, then adds a compact parenthetical of examples. There is no redundancy and every phrase contributes to understanding the 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?

Given a rich nested input schema, an output schema, and strong read-only annotations, the description is enough for an agent to select and invoke the tool correctly. It does not cover workflow sequencing or alternatives, but those are not critical for this isolated retrieval-style 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 input schema has 100% description coverage, with detailed per-field explanations and examples for every intake property. The description only adds the general notion of 'customer facts', which is already reflected in the schema's description. The schema carries the parameter-meaning burden, so the description adds marginal semantic 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?

The description states a specific verb and resource: 'Return legal, tax, and practical red flags'. It also specifies the input source ('detected from customer facts') and gives representative flag types, making the tool's purpose distinct from sibling list/retrieval tools.

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 makes the trigger condition clear: use this tool when customer facts are available and risk flags need to be surfaced. It does not explicitly name alternatives or exclusion criteria, but no sibling tool overlaps with the red-flag function, so the context is sufficient.

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 clear. The description adds the skill categories but not deeper behavioral details like pagination or output shape; with an output schema present, this is adequate but not rich.

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

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

Two short sentences with no filler. Purpose is front-loaded, followed immediately by usage guidance, making it easy for an agent to parse and act on.

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 tool with zero required parameters, an output schema, and strong annotations, the description fully covers what the tool lists, when to use it, and what to do next. No critical context 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%, and the query parameter is already documented as optional text to filter skill names or descriptions with an example. The description adds useful examples of filterable skills, but the schema carries the main semantic weight.

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

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

States a specific verb and resource: 'List Protocol Architect workflow skills', and enumerates the skill categories (Vault, TRS, 95/5, PSC, portal co-pilot). It also differentiates from get_skill by framing list_skills as the initial lookup 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?

Explicitly says to call when the Owner asks how to set something up, and routes the agent to get_skill for the matching workflow. This names both the trigger condition and the successor tool, leaving little 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 indicate the operation is not read-only, not idempotent, and not destructive. The description adds the 'allowlisted' and 'assisted session' context, but it does not disclose what navigation entails, such as whether the current page is replaced, whether portal state is reset, or whether an active session is required. With annotations present the bar is lower, but the description still contributes little behavioral detail beyond what is already stated.

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

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

The description is a single, compact sentence that front-loads the action and embeds the portal list efficiently. There is no filler or redundant 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 simple two-parameter tool with an output schema, an enum constraint, and annotations, the description is mostly adequate. The main gaps are the lack of explicit session prerequisite and sequencing context relative to sibling tools like start_browser_session and prepare_portal_fill. It is functional but not fully self-contained.

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 sessionId and portalId already have clear descriptions, including examples and an enum for portalId. The description essentially repeats the portal enum values rather than adding new semantic meaning, 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 uses a specific verb ('Navigate'), names the resource ('the assisted session'), and enumerates all allowlisted portal IDs. It clearly distinguishes this from session lifecycle siblings like start_browser_session and end_browser_session by targeting an existing session.

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 usage context: it navigates an already-started assisted session to an official portal, and the sessionId requirement reinforces this. However, it does not explicitly state when to use this tool versus alternatives such as prepare_portal_fill or get_self_serve_portal, nor does it name any exclusions.

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

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

The description discloses important behavioral nuances beyond the annotations: secrets are listed but never filled, and the Trust should never be mapped as a PSC organisation. This adds meaningful safety and scope 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 sentences, front-loaded with the main purpose and followed by high-value caveats. Every sentence earns its place without 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?

Given the output schema exists and the input schema is fully documented, the description covers the essential operational context: target forms, timing, label alignment, secret handling, and a critical exclusion. It is complete enough for an agent to invoke 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?

The input schema provides 100% coverage with descriptions for all parameters, including the formFamily enum and intake object fields. The description does not add much parameter-level detail beyond naming the two target families, which is sufficient given schema coverage.

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 the specific operation: mapping intake facts to a fill_fields payload, and explicitly names the two target portal families (TRS and Companies House PSC). This clearly distinguishes it from siblings like fill_fields and list_fillable_fields.

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 clear contextual guidance: call after Owner login and align labels with list_fillable_fields. It also warns about a key edge case (never map the Trust as a PSC organisation), though it does not explicitly discuss when to choose this over related tools.

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

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

Annotations already signal that this is a mutating, non-idempotent operation. The description adds valuable context: the token is one-time, it must be shown to the human Owner, and submission should wait. Details like token expiration or invalidation of prior tokens are not covered, but the description goes beyond the annotation data.

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 purpose, no filler. The first sentence says what the tool does and why it matters; the second adds the necessary human-owner step. Every part 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, annotations, and a single well-documented parameter, the description covers the essential workflow constraints: token creation, mandatory display to the Owner, and dependency on confirm_and_submit. Nothing critical is missing for correct invocation.

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

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

The input schema fully describes sessionId with an explanation and example, and the description adds no new parameter-level information. With 100% schema description coverage, the baseline score 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?

The description states a specific verb and resource: 'Create a one-time confirmation token required before confirm_and_submit.' This clearly distinguishes it from the sibling confirm_and_submit: this tool prepares the token, that tool performs the submission.

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 explicitly identifies when the tool should be used (before confirm_and_submit) and gives a clear workflow constraint ('do not submit without it'). It does not enumerate alternative tools or when-not-to-use scenarios, but enough contextual guidance is provided for a single-purpose 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 already indicate non-read-only and non-idempotent behavior, but the description adds that the tool blocks/wait for the owner and references the live view mechanism. The security warning about passwords is a behavioral boundary not captured in annotations. This goes beyond the structured data and clarifies how the tool affects the flow.

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

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

Two sentences with zero redundancy. The core function is front-loaded, and the warning is placed second. Every phrase earns its place, and the structure is immediately scannable.

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 description, combined with the enum and annotations, covers the essential aspects for calling the tool correctly. It lacks details about what happens after the pause (e.g., how the user signals completion), but the output schema exists and the tool's simplicity reduces the need for more. The warning about passwords is an important addition.

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 and the enum values are fully described in the schema. The description only repeats the enum values ('login, CAPTCHA, 2FA, or review') without adding extra meaning. With high schema coverage, the baseline 3 suffices; no additional clarification is needed.

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 ('Pause for') and the resource ('Owner login, CAPTCHA, 2FA, or review') with a clear location ('Browserbase live view'). It also adds a crucial negative instruction ('Never ask the Owner to paste passwords into chat'), which distinguishes it from other owner-interaction tools. This clearly differentiates from siblings like confirm_and_submit or wait_for_user_ready.

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 lists exact scenarios (login, CAPTCHA, 2FA, review) that trigger the pause, making the 'when' explicit. However, it does not contrast with alternative tools (e.g., wait_for_user_ready) or state when not to use it. Despite that, the enum in the schema reinforces these use cases, so the guidance is strong.

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 description adds useful behavioral context by stating that the tool returns validation results and should precede drafting/portal work. However, all annotations are false, so the agent gets no safety profile; the description does not clarify whether running this validation has side effects, persists anything, or is safe to rerun.

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

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

The description is a single, tightly worded sentence that front-loads the main action and outputs, then gives the critical usage timing. Every phrase contributes useful information with no 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?

The description covers what the tool does, what it returns, and when to call it, while the output schema handles return-value structure and the input schema covers parameters. The phrase 'Protocol warnings' is domain-specific but not prohibitive given the surrounding tool ecosystem.

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 input schema has 100% description coverage across all 12 parameters, so the schema carries the parameter documentation burden. The description adds no field-level meaning and only refers generically to a 'structured trust setup intake', matching the baseline of 3 for high schema coverage.

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

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

The description uses a specific verb ('Validate'), names a clear resource ('structured trust setup intake'), and lists concrete outputs ('missing facts, Protocol warnings, and next modules'). It distinguishes itself from downstream drafting/portal tools by being the pre-draft validation 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?

The description explicitly says 'Call before drafting forms or opening portals,' which gives clear usage timing and context. It does not name an alternative tool or explicitly state when not to use it, but the sequencing guidance effectively separates it from siblings like draft_form_answers and open_portal.

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 safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds useful behavioral context: results are ranked, include cited excerpts, and carry an 'educational boundary.' This extends beyond the annotation safety profile, though it does not detail boundaries, pagination, or any 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 tight sentences: priority, core action, and output characteristics. Each sentence contributes unique information with no redundancy or filler. The most important usage directive 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?

Given the low complexity (2 params, 1 required, no enums), existing output schema, and annotations covering safety, the description provides everything an agent needs to decide when and how to call it. It names its source domain, return shape, and the precedence rule over generic legal guidance.

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 documented in the schema. The description adds no specific parameter semantics beyond implying queries should use Protocol vocabulary, which is already reflected in the query's schema description ('Search text using Protocol terms'). 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 ('Search approved Blackbook Protocol passages') and describes the output ('return cited excerpts'). It distinguishes itself from generic UK legal advice, which maps to sibling tools like get_hmrc_guidance or get_companies_house_guidance, by positioning it as the Protocol-specific search tool.

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 it is 'REQUIRED before substantive Protocol answers,' giving a clear condition for use. It also advises preferring Protocol vocabulary from hits over generic advice, but does not name explicit sibling alternatives or state when not to use it, so it stops short of full 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?

The description adds meaningful behavior beyond the annotations: the session is fresh and ephemeral, it may use Browserbase or a mock, and it returns liveViewUrl rather than purchaser email. Since annotations already signal non-readonly, non-idempotent, non-destructive behavior, the description covers the remaining important traits well, though it does not mention how sessions relate to an existing live session.

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

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

The description is two sentences with no wasted words. The most important constraint ('ASSISTED mode only') is front-loaded, followed by the core behavior and the key alternative routing.

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

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

For a low-complexity, single-parameter tool with an output schema and full parameter documentation, the description is complete. It covers mode restriction, session type, return value, and the relevant sibling alternative, so an agent has what it 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?

Schema coverage is 100% and the single optional 'reason' parameter already has a clear description and example in the schema. The tool description adds no additional parameter-level meaning, so the schema carries the burden and the baseline score 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 uses a specific verb ('Start') and resource ('fresh ephemeral Browserbase (or mock) co-pilot session'), and clearly states that it returns liveViewUrl with no purchaser email. It also distinguishes itself from get_self_serve_portal, so an agent can differentiate without inspecting sibling tools.

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?

'ASSISTED mode only' is an explicit precondition, and the description names the alternative ('get_self_serve_portal') for when the Owner prefers their own browser. This leaves no ambiguity about when this tool is appropriate.

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 indicate this is not a read-only operation (readOnlyHint: false) and uses an open world (openWorldHint: true). The description adds that it polls until the page leaves the sign-in surface or times out, which is useful behavioral context beyond the annotations. It doesn't mention error handling or side effects beyond 'continue fill', but the polling condition and timeout are disclosed. Given annotations carry some weight, this is solid 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?

The description is a single, front-loaded sentence that states the trigger condition first, then the action, then the continuation. Every word earns its place; there is no fluff or repetition of schema details. It is concise and readable.

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, so return values are handled separately. The description covers the why, when, and what of the tool sufficiently. It could mention error behavior or default timeout values, but those are in the schema (defaults for pollMs and timeoutMs) and likely in the output schema. For a polling tool, this is reasonably complete.

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

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

The schema covers 100% of the parameters, so the description doesn't need to compensate. The description mentions 'poll' and 'timeout', which map naturally to pollMs and timeoutMs, but adds no new meaning beyond what the schema provides. This is the baseline 3 for fully covered parameters.

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 exactly what the tool does: it polls until the page leaves the sign-in surface after a login/2FA request, then continues filling. It references the sibling 'request_user_action' directly, which distinguishes it from other tools like 'fill_fields' or 'confirm_and_submit'. The verb (poll) and resource (sign-in surface) are specific, and the temporal relationship to request_user_action is clear.

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 explicitly tells the agent when to use this tool: after request_user_action(login|2fa). It also hints at the continuation step ('Then continue fill'), implying the tool is a bridge between user authentication and form filling. It doesn't explicitly list alternatives or when not to use it, but the contextual trigger is strong enough to route an agent correctly.

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