Offline Protocol (hosted)

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine context beyond that: output is text, and failure mode is an explicit error on unsupported frameworks rather than a fabricated answer.

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 dense sentences, front-loaded with what the tool produces, followed by the error behavior. No filler or redundancy.

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

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

With no output schema, the description correctly states the return is text and describes the failure mode. Both parameters are documented at 100% coverage, so nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning to platform beyond the schema by explaining that supplying it overrides inference and lifts the unsupported-framework error, which is behavioral semantics the schema does not state.

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 (generate) and resource (architecture plan) and enumerates the concrete outputs: workflow, platform, packages, starter template, architecture documents. This clearly distinguishes it from the retrieval-oriented siblings (get_workflow, get_package, preview_scaffold), which fetch rather than compose a plan.

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

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

It gives a concrete usage condition: it returns an error rather than a guess when the idea needs an unsupported framework unless a platform is supplied. That tells the agent when the tool will fail and how to unblock it, though it never explicitly contrasts itself with siblings like preview_scaffold or resolve_packages.

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 a closed world, so the safety profile is fully covered. The description adds useful scope about what the entry contains (capabilities, peer dependencies, platform requirements, integration notes, examples) but says nothing about auth, rate limits, or behavior on a missing package.

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

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

One sentence, front-loaded with the verb and resource, with the enumerated return contents as the only elaboration. Nothing is wasted and nothing important is buried.

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

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

With no output schema, the description carries the burden of describing the return shape, and it does so by listing the entry's fields. An agent can call this correctly with the annotations plus the single documented parameter, though error behavior for an unknown package name is unaddressed.

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

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

Schema coverage is 100%: the single 'name' parameter is typed, length-bounded, and documented with a concrete example. The description adds no naming convention or format guidance beyond what the schema already supplies, 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 (Get) and resource (one package's registry entry) and enumerates the payload an agent can expect, which cleanly separates it from list_packages and search_packages. It never names a sibling explicitly, so it stops short of full differentiation.

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

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

The word 'one' implies fetching a single known package by name, which hints at when to use it over the list/search siblings, but there is no explicit when-to-use statement, prerequisite, or named alternative. Usage is inferred 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 declare readOnlyHint=true, idempotentHint=true, and safe behavior, so safety is clear. The description adds useful context about what the skill contains (API usage, code samples, practices), but does not mention output format, size, or any limitations beyond that.

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?

Single sentence, front-loaded with the action and resource, followed by content details. Efficient with no obvious waste, though the parenthetical '(skill)' is slightly redundant with the tool name.

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

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

For a read-only retrieval tool with a single fully-documented parameter and no output schema, the description covers what the tool returns at a high level (API usage, code samples, practices). It is complete enough for an agent to call 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%, so the parameter is fully documented in the schema (name, maxLength, examples). The description does not add syntax or format details beyond what the schema provides. Baseline 3 is appropriate given full 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 a specific verb ('Read one') and resource ('Offline Protocol integration guide (skill)'), and gives examples of the content areas (mesh networking, identity, groups). It doesn't explicitly contrast with siblings like list_skills or search_skills, but the singular 'one' implies retrieval of a full skill by name rather than enumeration.

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?

Implicit guidance from 'one skill' and the required name parameter suggests this is for retrieving a specific skill by name, contrasted with list_skills/search_skills siblings. However, no explicit when-to-use or when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and 'Creates no files' restates that safety profile. However, since there is no output schema, the enumeration of returned metadata (variables, post-generation steps, notes, file list) adds genuine behavioral value that structured fields do not carry.

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

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

One sentence, front-loaded with the action, that lists the return contents compactly and closes with the reassuring 'Creates no files'. No sentence is wasted and nothing is buried.

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

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

For a one-parameter read tool with full annotation coverage, the description supplies the return-shape information that a missing output schema would otherwise leave unknown. It stops short of noting failure behavior (e.g. what happens for an unknown template name), which is the only 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?

There is a single parameter with 100% schema description coverage, including a concrete example ('react-native-mesh-app'), so the schema fully documents it. The description adds no additional meaning about the name parameter, making the baseline 3 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 (get a template's metadata) and enumerates the returned fields (variables, post-generation steps, notes, file list), so an agent knows exactly what it retrieves. It is distinguishable from siblings like get_package or get_workflow by the resource itself, but it never explicitly contrasts with them.

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

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

Usage is only implied: the phrase 'Creates no files' hints this is the inspection counterpart to scaffolding tools such as generate_architecture or preview_scaffold, but no explicit when-to-use or when-not-to-use condition is given. An agent must infer its place among the many get_/list_/search_ siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds the shape of what is returned (packages per platform, templates, screens/services/events/data models), but says nothing about lookup failure, missing names, or payload size.

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 dense sentence that front-loads the verb and resource, then enumerates the returned contents. No filler and nothing redundant with the schema or annotations.

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

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

With no output schema, the description takes on the burden of explaining the return value and does so by enumerating the workflow's constituent parts. It falls slightly short by not indicating error behavior for an unknown workflow name or how the nested reference architecture is structured.

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

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

There is a single 'name' parameter with 100% schema description coverage including concrete examples (local-handoff, backend-delivery). The description adds no extra syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (one workflow) and enumerates the payload contents: capabilities, packages per platform, starter templates and reference architecture. It is clearly distinct from list_workflows/search_workflows by implication, but never explicitly contrasts itself with sibling getters like get_package 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 phrase 'Get one ... in full' implies usage when the full workflow definition is needed rather than a search or list, but there is no explicit statement of when to use this tool versus the 14 siblings, nor any prerequisite or exclusion. Usage is left 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 declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value by disclosing the scope of the result set (all public-registry packages) and the fields carried in each entry, which matters given there is no output schema. It stops short of stating ordering, size, or whether pagination applies.

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

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

A single sentence, front-loaded with the verb and scope, with every clause earning its place by naming the returned fields. No filler, no restatement of the title.

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

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

With no parameters, no output schema, and annotations that fully cover the safety profile, the description only needs to convey scope and payload, which it does. Ordering/pagination and the explicit contrast with the search_* and get_* siblings are the only omissions, both minor for a zero-arg listing tool.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. Nothing in the text misleads about inputs; it correctly implies a no-argument enumeration.

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

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

Specific verb (List) plus a precisely scoped resource ('every Offline Protocol SDK package in the public registry'), and it enumerates the returned facets (version, platforms, capabilities, license). It does not name or differentiate against near-neighbors such as search_packages, resolve_packages, or get_package, so the agent must infer the split.

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 never states when to use this versus search_packages (filtered lookup) or get_package (single package detail). Usage is only implied by the word 'every', which hints at an unfiltered enumeration, but no explicit conditions or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the return-content hint ('with the situations it covers'); it says nothing about ordering, pagination, or size, which for a full-enumeration tool would be genuinely useful.

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

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

A single front-loaded sentence with no filler. Every word contributes: the verb, the scope, the domain gloss, and the payload hint.

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 parameters, no output schema, and annotations covering the behavioral profile, the description supplies enough to call the tool correctly and even indicates what each entry contains. Only the shape/volume of the result is left unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies no filtering inputs are 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?

Names a specific verb (list) and resource (skills), and even defines the domain term by noting a skill is an Offline Protocol integration guide. 'Every' distinguishes it from get_skill and search_skills, though those siblings are never named explicitly.

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

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

Usage is only implied: the word 'every' suggests this is the unfiltered enumeration path, in contrast to search_skills and get_skill. No explicit when-to-use or when-not-to-use statement is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds that each result includes capabilities and supported platforms, which is useful, but says nothing about pagination, ordering, or result size.

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

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

A single front-loaded sentence with no filler; the verb, scope, and returned content appear in one pass. Nothing could be trimmed without losing 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 and no parameters, the description carries the burden of indicating what comes back, and it does name capabilities and supported platforms. Minor gaps remain around ordering or whether the list is exhaustive across all products, but it is sufficient for a simple enumeration tool.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing to document, and the description correctly does not invent 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?

Clear verb 'List' plus resource 'workflows', with scope widened by 'every' and content qualified as capabilities and supported platforms. It implicitly contrasts with search_workflows and get_workflow, but does not explicitly name or differentiate from those 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?

'List every' implies use for full enumeration rather than a filtered search or single fetch, but no explicit when-to-use, when-not, or named alternative is given. Usage is only inferable from the wording and the sibling set.

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. The description adds the meaningful behavioral fact that it writes nothing and that creation needs an external CLI, which goes beyond the annotations' safety profile.

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

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

Two tight sentences: the first lists what the preview shows, the second clarifies the no-write behavior and points to the CLI. Front-loaded and zero waste.

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

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

For a read-only preview with full schema coverage and safety annotations, the description covers purpose, scope, and the key no-write constraint. It omits return-shape details, but with no output schema that is a minor gap given the preview nature.

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 each parameter richly documented, including conditional rules like platform being required for multi-platform workflows and enableOfflineId's defaulting behavior. The description adds no parameter-level detail beyond the schema, 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 (Preview) and resource (Offline Protocol starter), and enumerates its contents (workflow, template, packages, file list). Clearly distinguishable from siblings like get_template or generate_architecture, which retrieve or generate rather than dry-run preview.

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 frames this as a dry run that writes nothing, and notes that actually creating the project requires the local CLI instead. This effectively tells the agent when this tool applies vs. a create action, though it doesn't reference sibling preview/listing tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. With no output schema, the description usefully carries the return-shape burden by naming the install list contents (versions, peer deps, install commands, license notes), which is real added value beyond the structured fields.

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

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

A single dense sentence with the action front-loaded and the payoff (exact install list plus its contents) immediately following. No filler, no repetition of the title.

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

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

Given no output schema, the description compensates by describing the returned install list, and it signals the two input modes. It omits edge behavior such as what happens if both packages and workflow are supplied, but for a read-only resolution tool the definition is largely sufficient.

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

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

Schema coverage is 100% with clear per-parameter descriptions and an enum for platform, so the schema does the heavy lifting. The description only hints that packages and workflow are mutually exclusive alternatives and adds no format or limit detail beyond the schema.

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

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

States a specific verb (resolve) and resource (Offline Protocol packages/workflow) and even enumerates the output artifacts: versions, required/peer deps, install commands, license notes. This clearly separates it from list_packages or get_package, though it never names a sibling to sharpen the contrast.

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 'packages, or a workflow' implies the two are alternative inputs, which is mild usage guidance, but there is no statement of when to reach for this versus search_packages/get_package, nor any prerequisite such as needing a platform first.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds genuine value by disclosing the shape of the result (which packages, workflows and guides provide the capability), but says nothing about ranking, result limits, or partial-match behavior.

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

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

One sentence, front-loaded with the primary purpose and the output type, with no filler or repetition of the title. Every clause earns its place.

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

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

For a one-parameter, read-only search tool with no output schema, the description covers the essentials: what is searched, the domain, and what the results point to. It could be stronger by clarifying that results are cross-referenced resources rather than capability objects themselves, but 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?

There is a single parameter with 100% schema description coverage ('Search keywords', maxLength 200), so the schema carries the load. The description adds no query syntax guidance — whether it is keyword-based, whether multiple terms are ANDed, or how to phrase a capability query — so it does not exceed 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?

Specific verb (Search) plus a well-scoped resource (Offline Protocol capabilities) with concrete examples (peer discovery, encrypted groups). It also states what the result maps to — packages, workflows and guides — which sets it apart from the sibling search_packages/search_workflows/search_skills tools. It stops short of naming a sibling explicitly, so it is clear but not maximally differentiating.

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

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

Usage is implied: reach for this when you want to find what implements a capability rather than looking up a known package or workflow. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative among the many sibling search_* and get_* tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered. The description adds only that matching is keyword-based over example apps/integrations, and says nothing about result ordering, limits, or empty-result behavior.

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

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

One sentence, front-loaded with the verb and resource, with zero filler. Every clause earns its place.

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

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

For a single-parameter, read-only keyword search with rich annotations, the description covers what an agent needs. The only gap is not distinguishing this index from the other search_* indexes, which slightly matters given ten-plus siblings.

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

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

Schema description coverage is 100% for the single 'query' parameter (documented as 'Search keywords' with maxLength 200), so the schema carries the burden. The description adds no syntax, matching-mode, or phrasing guidance beyond what the schema already states; 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 (Search) and a clearly scoped resource (Offline Protocol reference example apps and integrations) searched by keyword. It implicitly separates itself from search_packages/search_skills/search_workflows by naming a different resource type, though it never names those siblings explicitly.

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

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

There is no when-to-use guidance, no caveats, and no mention of the many sibling search_* tools an agent could pick instead. The agent must infer from the resource noun alone which search tool applies.

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, closed-world, so the safety profile is covered. The description adds one genuine behavioral detail — results are ranked matches — but says nothing about result limits, pagination, scoring, or empty-result behavior, and the tool has no output schema to fill that gap.

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

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

Two short sentences, front-loaded with what is searched and followed by the return shape. No filler, though the second sentence is minimal and could carry more useful detail.

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

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

For a one-parameter read-only search with full schema coverage and annotations covering safety, the description covers what is searched and what comes back. The notable gap is disambiguation from the crowded sibling set (list_packages, search_capabilities, search_examples), which an agent would need to pick 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 coverage is 100% and the single parameter is documented, so baseline is 3. The description goes one step further by naming the fields the query is matched against (name, capability, description keywords), which meaningfully clarifies matching semantics beyond the schema's generic 'Search keywords'.

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 (Search) and resource (Offline Protocol SDK packages) and even enumerates the searchable fields (name, capability, description keywords). It does not differentiate itself from the many siblings that overlap it, notably list_packages and search_capabilities/search_examples, so an agent still has to guess at boundaries.

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 use case is implied — supply keywords to find matching packages — but there is no explicit statement of when to pick this over list_packages (browse everything) or resolve_packages/get_package. No prerequisites, no exclusions, no alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description's contribution is limited to 'Returns matching guide names', a useful return-value hint given there is no output schema, but it omits result limits, ranking, or empty-result behavior.

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

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

Two short sentences with zero filler; the action and the return value are front-loaded so an agent can decide in one read.

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 search tool with no output schema, the definition covers what it searches and what it returns, which is the key missing structure. It is close to complete, lacking only detail on result count or next-step routing (e.g., get_skill).

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

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

Schema description coverage is 100% and the single 'query' parameter is documented as 'Search keywords', so the schema carries the burden. The description adds only the mild framing of matching against 'topic', not syntax, tokenization, or matching rules.

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

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

States a specific verb (Search) and resource (Offline Protocol integration guides, glossed as 'skills') scoped 'by topic', which separates it from get_skill and list_skills by behavior. It never explicitly names a sibling, so the differentiation is implied rather than spelled out.

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 'by topic' implies keyword-driven lookup when the exact skill name is unknown, which contrasts with list_skills or get_skill. However, there is no explicit when-to-use statement, no exclusion, and no guidance on what to do if no match is returned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful scoping fact that the corpus is Offline Protocol product workflows, but says nothing about result count, ranking, or pagination.

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

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

A single front-loaded sentence with the resource named first and the qualifier second; no filler. The embedded example list is the only slight lengthening, and it earns its place by clarifying the domain.

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

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

For a one-parameter, read-only search tool with full annotation coverage and no output schema, the description covers what it searches and over what domain. The only gap an agent might want is how results are shaped or ranked, which is minor here.

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

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

One parameter with 100% schema description coverage, so the baseline is 3. The description adds semantic intent for the query (keywords describing what you want to build), which is mildly useful, but adds no format, length, or phrasing guidance beyond the schema's "Search keywords" (max 200).

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 (search) and resource (Offline Protocol product workflows) with concrete examples of the workflow domain (local handoff, nearby chat, backend delivery, OfflineID sign-in). The resource noun distinguishes it from the search_packages/search_skills/search_examples siblings, but it never names an alternative so the differentiation is implicit rather than explicit.

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?

"by keywords describing what you want to build" implies the discovery use case, but there is no explicit when-to-use statement, no contrast with get_workflow or list_workflows, and no note that this is the right entry when the workflow ID is unknown. Usage is implied only.

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