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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states the calculation purpose and implies no side effects, but does not disclose anything about the input ranges, output format, or any constraints. An agent cannot predict what the function returns or how it behaves with varying inputs.

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 concise sentence with no fluff, but it is under-specified for a tool with five parameters. It is well-structured in its brevity but fails to provide necessary context, making it merely a bare statement rather than an effective guide.

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 five required parameters and no output schema, annotations, or parameter descriptions, the description is severely incomplete. It does not explain the scoring scale, how to interpret results, or any prerequisites, leaving an agent largely in the dark about correct usage.

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

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

Schema coverage is 0% and the description makes no mention of the five required parameters, their meanings, or how they relate to the automation score. The parameter names (frequency, rule_clarity, etc.) are self-descriptive but the description adds zero value in interpreting them or their expected values.

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 clear verb (calculate) and resource (business process suitability for automation), distinguishing it from siblings like calculate_time_cost which focuses on cost. However, it does not specify the nature of the score or how it is derived, which slightly weakens differentiation but remains 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?

There is no guidance on when to use this tool versus alternatives. It does not mention that it should be used when evaluating a process for automation, nor does it differentiate from calculate_time_cost or the create/save tools. No context or exclusions are 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?

There are no annotations, so the description carries the behavioral transparency burden. It only states that the tool 'calculates,' implying a read-only, side-effect-free operation, but it does not disclose assumptions like weeks-per-month conversion, rounding, or whether the result includes both time and cost as separate outputs.

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 with no filler. Every word contributes to the purpose, making it easy to parse quickly.

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

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

The tool is simple and has an output schema, so the description does not need to explain return values. However, it omits key assumptions (e.g., how weeks are converted to months) and does not clarify when to prefer this tool over calculate_automation_score, leaving some context gaps for an agent.

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 needs to compensate by clarifying parameter semantics. It adds only the 'monthly' context, which helps interpret frequency_per_week, but it does not explain units, formulas, or relationships among the required 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 uses a specific verb ('Calculate') and resource ('monthly time and labor cost of a manual process'). This clearly distinguishes it from the sibling calculate_automation_score, which focuses on a scoring metric rather than cost/time calculation.

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 intended use is implied by the description: use this tool when you need the monthly time/labor cost of a manual process. However, it does not explicitly mention when not to use it or contrast it with alternatives such as calculate_automation_score.

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 behavioral burden. It states that the tool creates and stores a business, which implies persistence, but it does not mention whether creation is idempotent, whether duplicates are allowed, what authorization is needed, or what happens on success or failure.

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, focused sentence that front-loads the action and object. It is concise and easy to parse, though it sacrifices detail that other dimensions need.

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 small schema and no output schema, but the description does not mention return values, error behavior, or required-field semantics. For a create operation with no annotations, an agent would still need more context to use it confidently.

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, but it does not explain any of the three parameters. The parameter names are self-explanatory at a basic level, but units, constraints, and how they relate to an automation audit are left unspecified.

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 ('Create and store') with a clear resource ('a business') and a domain purpose ('for an automation audit'). It is clearly distinct from sibling tools like create_process and save_audit because it targets the business entity specifically.

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 'for an automation audit' gives implied context about when this tool is relevant, but it does not explicitly state when to use it versus alternatives like create_process or save_audit. No exclusion criteria or preferred ordering 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?

No annotations are provided, so the description carries the full burden. It only states that a process is created, but does not disclose side effects, permissions required, idempotency, or what happens to existing processes. For a create action, this is a minimal disclosure that leaves behavioral expectations largely unspecified.

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, concise and front-loaded with the core action and purpose. However, it is so brief that it omits necessary detail; while it earns its place for purpose clarity, it sacrifices completeness for brevity.

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 three required parameters and no output schema, the description should explain parameter roles and perhaps return behavior. It does neither. The description only clarifies the 'what' and 'why', leaving the 'how' (parameter usage) and 'what to expect' completely unaddressed. Given the tool's simplicity, a bit more context would be expected.

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% for all three parameters (business_id, name, description), and the description provides no additional meaning for any of them. The description does not compensate for the schema's lack of doc comments, so an agent has to infer parameter semantics purely from their names. This is a significant gap for a tool with required 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 verb ('Create'), a resource ('business process'), and the intent ('to evaluate for automation'). This clearly distinguishes it from siblings like create_business or save_discovery_answer, which target different entities.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description does not mention conditions under which another tool (e.g., create_business) would be more appropriate. An agent would have to infer usage from the name and schema alone.

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 all behavioral disclosure. It only states a retrieval action with no mention of side effects, permissions, or return characteristics. The term 'complete' is vague and does not reveal what fields or structure are returned.

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, short sentence with no filler. It front-loads the action and resource, making it easy to parse. There is no redundant 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?

Given the absence of an output schema and annotations, the description is incomplete. It does not describe the return value's structure, possible errors, or the meaning of 'complete audit.' For a simple retrieval by ID, some context like typical usage or response format is expected but 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 input schema has 0% coverage—audit_id is defined only by its runtime type and title. The description does not explain what audit_id refers to or how to obtain it, beyond the implication from the tool name. It relies on the property name to carry meaning, which is minimal but not entirely useless.

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 'Retrieve' and the resource 'one complete automation audit,' which distinguishes it from sibling tools like list_audits that likely return multiple audits. The word 'one' and 'complete' make the scope 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?

No guidance is given about when to use get_audit versus alternatives such as list_audits or save_audit. An agent is left to infer that this retrieves a single audit, but there is no explicit statement of conditions or 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?

With no annotations, the description must carry behavioral disclosure. The word 'list' conveys a read-only operation and 'all saved' signals no filtering, which is useful. However, it does not explicitly state that the operation is non-destructive, nor does it mention pagination, ordering, or side effects, though the output schema may cover the return shape.

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 exactly what the tool does without any filler. 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?

For a parameterless listing tool with an output schema, this description is largely complete: it names the resource, the operation, and the scope. It only falls short in not pointing the agent to get_audit for single-audit scenarios, which is a minor gap given the sibling list.

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 accepts zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies, and the description appropriately requires no additional param details.

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 ('list') and identifies the exact resource ('saved automation audits'), adding a scope marker ('all') that distinguishes it from the sibling get_audit, which implies retrieving a single audit. This is unambiguous and directly tells an agent what the tool returns.

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

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

The description implies the tool should be used when an agent needs a collection of all saved audits, but it does not explicitly state when it should not be used or name get_audit as the alternative for a single audit. The usage context is present but 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'save', which implies a write operation, but it does not mention whether the tool is idempotent, whether it overwrites existing audits, what permissions are required, or any side effects. This is insufficient for a mutation tool without annotation support.

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, concise sentence with no wasted words. It is appropriately sized for a simple save operation, though it could be expanded to cover essential context. It is front-loaded with the action and object, making it easy to parse.

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 6 required parameters, no output schema, and no annotations, the description is far too minimal. It does not clarify what values are expected for parameters like automation_score, category, or monthly_hours, nor does it describe the overall workflow context (e.g., that the audit must be calculated first). An agent would struggle to populate the parameters correctly without additional information.

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 by explaining the parameters. It mentions none of the six parameters, their meanings, or their relationships. The schema titles (e.g., 'Automation Score') provide minimal clues, but the description adds no additional semantic value, making it impossible for an agent to understand parameter intent from the description alone.

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 verb ('Save') and a specific resource ('completed automation audit'), and it distinguishes from sibling calculation tools (calculate_time_cost, calculate_automation_score) and retrieval tools (list_audits, get_audit) by indicating a persistence action. The word 'completed' also hints at its position in the workflow.

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 after an audit is completed, but it does not explicitly state when to use it relative to the calculation tools, nor does it mention prerequisites or alternatives. The guidance is implicit rather than explicit, so it earns a middle score.

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 of behavioral disclosure. It only says 'Save or update', but does not clarify upsert semantics, overwrite behavior, idempotency, error handling, or any side effects. The agent cannot predict what happens if the answer already exists or what the response will be.

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 concise sentence with no wasted words. However, it is under-specified rather than efficiently informative, so it does not fully earn a 5 for 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?

For a tool with four required parameters, no annotations, and no output schema, the description is grossly incomplete. It lacks context on what constitutes a discovery answer, how question_key is derived, and what the expected return value is.

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% and the description provides no explanation of any parameters. None of the four required parameters are described, leaving the agent to guess the meaning of process_id, question_key, question_text, and answer_text.

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 'Save or update' and the resource 'discovery answer for a business process'. It distinguishes the tool from siblings like save_audit by specifying the unique concept of a discovery answer, though it does not explicitly contrast it with alternatives.

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

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

No guidance is given on when to use this tool vs alternatives. It does not mention any conditions for use, prerequisites, or differences from sibling tools such as save_audit or create_business.

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