flowpack

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

No annotations are provided, so the description carries the full burden. It discloses that results are paged and include 'id/name/description and metadata-only marker', which is useful. However, it does not mention permissions, rate limits, error behavior, or clarify what 'metadata-only marker' means, leaving some 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 two sentences, front-loaded with the tool's identity ('Universal catalog reader') and then efficiently details routing, optional filters, return shape, and usage. Every sentence earns its place; no filler or 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 5 parameters, no output schema, and no annotations, the description covers the essential behaviors: domain routing, facet/query filters, paging, and return structure. It stops short of explaining 'metadata-only marker' or edge-case behavior, but for a catalog listing tool, it is sufficiently complete for an agent to select and invoke it.

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

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

Schema coverage is 0%, so the description compensates by explaining domain (listing all enum values), facet (giving an example like 'button.hover'), and query ('free-text query'). It also references paging, which maps to page and page_size, though these are not explicitly named. The parameter meanings are largely clear from the description and names.

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 this is a 'Universal catalog reader' and specifies it routes by domain with a list of valid domains. It explicitly concludes with the use case: 'Use this for ANY merchant question about what options are available or show me X', which distinguishes it from siblings like diagnose or recommend.

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 a clear directive on when to use the tool: 'Use this for ANY merchant question about what options are available or show me X'. It does not explicitly name alternatives or state when not to use it, but the sibling tool names suggest distinct purposes, making the guidance more implicit than explicit.

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

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

With no annotations, the description carries the full burden. It discloses return structure (categorized issues, severity, fix_plan_id, health_score), notes that fix_plan_id is callable via execute(), and implies a read-only diagnostic behavior. However, it does not clarify whether the check has side effects or how the deep parameter affects execution, though the schema provides 'slower'.

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, information-dense paragraph with no fluff. Each sentence contributes: what it does, usage modes, return categories, and scoring. It is well-structured and front-loaded with the core purpose.

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 adequately explains return values (categorized issues, severity, fix_plan_id, health_score). It could be more explicit about parameter combinations (e.g., what happens if both symptom and kit are provided, or neither) and the 'execute()' reference is ambiguous without cross-tool context, but overall it is nearly complete for a diagnostic 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 schema covers only 33% of parameters (deep has a description). The description compensates by explaining 'symptom' (free-text) and 'kit' (scoped check), and implicitly that these are alternative modes. It does not add detail on 'deep' beyond the schema's 'slower', but overall the description provides meaning for the two primary 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 a specific diagnostic purpose: 'Runtime + theme + settings harmony check' with concrete examples like 'cart drawer feels slow'. It clearly distinguishes itself from siblings (browse, explain, plan, recommend) by focusing on issue detection and providing categorized results (theme_compat, settings_conflict, etc.).

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 usage context: free-text symptom OR kit-scoped check, with examples. It does not explicitly mention when not to use it or point to alternatives, but the two modes cover the primary scenarios and the sibling names imply different purposes.

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?

With no annotations, the description discloses the output form (natural-language explanation), detail levels including deep content ('full context + related settings + a11y notes'), and audience variants. It implies read-only behavior, though it doesn't explicitly state side effects or auth requirements.

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

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

Three tightly scoped sentences, each adding distinct information: resource types, audience/detail options, and trigger examples. No filler or 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?

Given no output schema, the description states the return type ('natural-language explanation') and covers optional parameters and use cases. The sibling context and absence of required parameters make this 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 description coverage is 0%, so the description must compensate. It does: plan_id is defined as 'what it does', setting_path as 'what one setting controls', audience includes 'merchant (default), developer, or reviewer', and detail is explained as 'brief' vs 'deep' with content. This fully covers all 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 opens with a specific verb and resource: 'Natural-language explanation of a plan_id... or setting_path...'. It clearly distinguishes from sibling tools by naming the exact objects and output type.

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 states when to use: 'Use when merchant asks "what does this do" or "why this preset".' It also provides audience and detail context. However, it does not mention when not to use or name alternatives, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals exactly what the tool returns (opaque plan_id, change count, preview URL, reasoning) and dictates a mandatory preview step before execution, which is meaningful behavioral context beyond the schema. It does not mention side effects or permissions, but for a planning tool this is reasonably transparent.

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 four sentences, each serving a distinct purpose: introducing the tool, providing examples, stating scope, and detailing return values and workflow. It is front-loaded with 'MASTER KEY' and is tightly written without filler, earning a high score for conciseness and structure.

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 explains return values (plan_id, change count, preview URL, reasoning) even though no output schema exists, which is essential. It also mentions the target kits (Button, Cart, Badge, Variant, Frosty Pill) and the preview/execute flow. The main gap is the lack of guidance on the 'context' parameter's nested fields, which slightly reduces completeness for an agent needing to construct valid input.

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 description coverage is 50% (only 'intent' has a description). The description adds value by offering multiple examples of intent ('make my buttons feel premium', 'wellness brand vibe', 'BFCM aggressive'), which clarifies the expected natural-language format. However, the 'context' object and its nested fields (theme, market, season, products, brand_hint, constraints, current_settings) are left completely unexplained in both the schema and the description, leaving a significant semantic gap.

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 ('analyzes') and resource (natural-language merchant intent → plan of settings changes) with concrete examples ('make my buttons feel premium', 'wellness brand vibe', 'BFCM aggressive'). It clearly distinguishes itself from siblings by claiming to be the 'MASTER KEY' tool that spans multiple kits and returns a structured plan, setting it apart from diagnose, recommend, or browse.

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 instructs 'ALWAYS call preview() before execute()', providing a clear workflow constraint. It also notes the tool handles both single tweaks and full overhauls with the same call, indicating scope. However, it does not explicitly contrast with alternatives (e.g., when to use diagnose vs plan), so it lacks full exclusionary 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?

No annotations are provided, so the description must carry the full behavioral burden. It only details the output shape for one scenario (personalized_4_plans) and leaves the other six scenarios unexplained. It does not state whether the operation is read-only, what the response looks like, or what the 'context' parameter does.

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 short and front-loaded, but the extensive list of scenario names largely duplicates the schema enum without adding meaningful detail for most items. The opening definition and usage sentence are useful, but the list adds redundant length.

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

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

With no output schema and no annotations, the description should explain per-scenario behavior, the role of context, and return values. It fully explains only one of seven scenarios, leaving the tool under-specified for correct agent invocation.

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

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

Schema description coverage is 0%, so the description needed to explain the parameters. It gives partial meaning for 'scenario' by listing enum values and detailing one, but the 'context' parameter is completely omitted, and most scenario names are just labels without semantic content.

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 identifies a 'goal-oriented recommendation engine' and lists concrete scenario names, one with a detailed example (personalized_4_plans returns 4 diverse plans). It distinguishes itself from siblings by framing the tool as proactive suggestion-generating, though it does not explicitly contrast with browse/diagnose/explain/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?

The description gives an explicit usage trigger: 'Use for proactive suggestions when merchant intent is unclear.' This is clear context for when to invoke the tool, but it lacks exclusions or explicit alternative tool guidance, so it does not reach a full 5.

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