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

With no annotations, the description carries the behavioral disclosure burden. It does reveal key behavior: it creates a new action, requires prior approval, and returns the created action's ID. However, it does not mention side effects, reversibility, permission requirements, or what happens if approval was not obtained, so the transparency is incomplete.

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-loaded, with the core purpose first followed by requirements, optional fields, and workflow guidance. Each sentence adds useful information, though it is slightly longer than necessary due to the list of optional parameters.

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 moderate complexity and the presence of an output schema, the description covers the essentials: required vs optional fields, the important priority_id default behavior, the approval workflow, and the return value. It is sufficient for an agent to call correctly, though it could mention which sibling tool to use for retrieving the created action afterward.

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, but the description adds meaningful semantic guidance beyond the schema. It clarifies that priority_id is an org-specific UUID and that omitting it uses the system default, and it reinforces that only title is required.

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 'Create a new action in Mitti,' naming a specific verb, resource, and system. This clearly separates it from siblings like actions_update_action_status and actions_get_action, which operate on existing actions.

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

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

It provides explicit sequencing: 'Call request_approval first and wait for the user's decision before calling this tool,' which tells the agent when it is appropriate to invoke this tool. It also states the minimum requirement of a title, giving clear entry conditions, though it does not describe when not to use the tool beyond the approval prerequisite.

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 burden. 'Get' implies a read-only operation and the returned fields are listed, but there is no explicit statement about not-found behavior, authentication needs, or side effects. It adds some context but leaves behavioral gaps.

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 focused sentences with no filler. The core purpose is front-loaded, and the field list earns its place by setting expectations about what 'full details' means.

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 single-parameter get operation with an output schema available, the description plus schema is nearly complete. It could mention error handling or authorization, but nothing essential 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 covers 100% of parameters and already describes action_id as 'The unique action ID.' The description only reinforces 'by its ID' without adding format, source, or usage nuances, so baseline 3 is appropriate.

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

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

States a specific verb ('Get'), a specific resource ('full details of a specific Mitti action by its ID'), and lists the returned fields. This clearly distinguishes it from sibling actions_list_actions, which lists actions rather than retrieving 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 phrase 'by its ID' makes the usage context clear: call this when you already have an action_id and need full details for that single action. It does not explicitly name alternatives or exclusions, but the intended trigger is 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?

No annotations are provided, so the description carries the behavioral burden. It adds value by disclosing server-side filtering and enumerating returned fields, and read-only behavior is implied by 'List.' However, it does not mention pagination, ordering, or any limits beyond the schema's existing limit parameter.

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 concise sentences with no filler. It front-loads the core purpose and account context, then efficiently covers filtering and return fields. 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 low-complexity read-only list tool with an output schema and fully documented optional parameters, the description is largely complete. It provides return fields and filter semantics, though it omits pagination and ordering behavior; these are minor gaps given the output schema and simple parameter set.

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

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

Schema description coverage is 100%, so the schema already documents status and priority_id, including allowed status values and the UUID type. The description mostly restates this information rather than adding new semantic meaning, though it does clarify that filtering is applied server-side.

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: 'List actions from the Mitti (formerly SafetyCulture) account.' It clearly differentiates this tool from siblings like actions_get_action (single action), actions_create_action, and actions_update_action_status by focusing on listing and filtering.

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 use case clear: listing actions with optional server-side filtering by status or priority_id. It does not explicitly name alternatives or state when not to use this tool, but the listing/filtering context is unambiguous among 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?

No annotations are provided, so the description carries the burden. It discloses the valid statuses and the required approval precondition, and states the return is success or an error message. However, it does not mention whether the update is idempotent, whether it overwrites existing status, or any permission requirements. The approval precondition is valuable behavioral context, but the description could go further.

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, each earning its place: what the tool does, valid values, and the critical precondition. The most important usage constraint is front-loaded after the purpose statement. No wasted words.

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 mutation with an output schema, the description covers the essential workflow (approval first) and the valid inputs. It lacks details on edge cases like whether status transitions are restricted, but the output schema and simple parameter set keep the gap small.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the valid status values, which are also in the schema's status description, so it adds little beyond the schema. 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 ('Update'), a specific resource ('status of a Mitti action'), and enumerates the valid status values. This clearly distinguishes it from sibling tools like actions_update_action_title and actions_create_action.

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 to call request_approval first and wait for the user's decision before using this tool. This is a clear when-to-use directive that prevents misuse and distinguishes it from the approval workflow.

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 behavioral burden. It discloses the mandatory approval gate and states the return behavior ('Returns success or an error message'), which is more than a bare mutation statement. It could add details like irreversibility or permission requirements, but the most important behavioral trait is covered.

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, no filler, and the most actionable guidance (approval ordering) is included with a direct command. 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 two-parameter update with a full input schema and an output schema present, the description covers purpose, workflow placement, and result. An agent has enough information to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents both title and action_id. The description adds only that the action is a 'Mitti action,' which is useful context but does not change how parameters should be filled.

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 object: 'Update the title of a Mitti action.' This clearly distinguishes the tool from sibling actions_update_action_status and the many inspection/template tools, so an agent knows exactly what resource is affected.

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 sequential precondition: call request_approval first, wait for the user's decision, then call this tool. This names the relevant sibling and tells the agent precisely when in the workflow this tool is valid.

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 fully carries the burden of behavioral disclosure. It clearly states this is a write operation, describes the prerequisite status and sequencing, and mentions the return behavior ('Returns success or an error message'). This is comprehensive for a simple state-transition tool.

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

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

The description is three sentences total, with the primary action first, followed by critical preconditions and return behavior. Every sentence adds necessary information with no redundancy or padding.

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

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

Given a single required parameter, a high-coverage schema, an output schema, and no annotations, the description covers all essential operational context: what it does, when to call it, what to do before it, and what to expect as a return. 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?

Schema description coverage is 100% and the audit_id parameter is already described as 'The unique audit/inspection ID to complete.' The description does not add much beyond this, aside from reinforcing that the parameter is an inspection ID tied to the completion operation. Baseline 3 applies because the schema handles the parameter documentation.

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 action and resource: 'Mark a Mitti inspection as complete.' It clearly differentiates from sibling tools like inspections_list_inspections and request_approval by identifying the completion action and its write nature.

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 provides usage conditions: the inspection 'must be in in_progress status' and the tool should be called only after request_approval and waiting for the user's decision. This gives clear procedural guidance and prevents misuse.

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 burden of behavioral disclosure. It states what the tool returns (name, template, owner, dates, score, status) but doesn't disclose whether this is a read-only operation, whether it can fail (e.g., not found), or any rate limits. Since it's a 'get' operation, the read-only nature is implied but not explicitly stated. The description adds some value by listing return fields, but lacks deeper behavioral 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?

The description is a single, concise sentence that front-loads the core purpose and lists the key return fields. Every word earns its place, and there is 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 single-parameter get tool with an output schema, the description is largely complete. It identifies the resource, the identifier, and the key fields returned. It doesn't mention error cases (e.g., invalid audit_id) or explicitly state read-only behavior, but these are minor gaps given the tool's simplicity and the presence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents the audit_id parameter well, including its format ('starts with audit_'). The description adds the context that this is the audit/inspection ID, but doesn't add significant meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 tool's purpose: 'Get full details of a single Mitti inspection by its audit ID.' It specifies the resource (inspection), the action (get full details), and the identifier (audit ID). It also lists the key fields returned (name, template, owner, dates, score, status), which distinguishes it from sibling tools like inspections_list_inspections and inspections_get_inspection_web_report_link.

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: use this tool when you need full details of a single inspection by audit ID. It doesn't explicitly state when not to use it or name alternatives, but the context signals and sibling names (e.g., inspections_list_inspections for listing, inspections_get_inspection_web_report_link for web report link) make the usage context clear. A clear exclusion or alternative mention would push this to 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?

No annotations are provided, so the description carries the full burden. It discloses that the returned URL is permanent and shareable, which is useful, but it does not mention authentication requirements, whether the link requires an existing/completed inspection, or any side effects. The basic read-only behavior is implied by 'Get' but not explicitly safe.

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 main purpose and the key output trait are both 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 one-parameter tool with an output schema, this is nearly complete: it states the purpose, output type, and sharing behavior. It could be improved by noting whether the report link is available before inspection completion, but that is a minor 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?

The only parameter, audit_id, is fully described in the schema as 'The unique audit/inspection ID.' The tool description adds no extra meaning to the parameter, and with 100% schema coverage 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 states a specific action ('Get') and a distinct resource ('shareable web report link for a Mitti inspection'), and clarifies the output is a permanent URL. This distinguishes it from siblings like inspections_get_inspection, which returns inspection data rather than a shareable link.

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 'can be shared with others to view the inspection report' gives clear usage context: use this when a shareable link is needed. It does not explicitly name alternatives or when-not conditions, but for a one-purpose link tool 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?

With no annotations, the description carries the burden of disclosure. It clearly states a key behavioral trait: only audit_id, template_id, and modification date are returned, and the search API does not return name, owner, score, or status. It implies read-only behavior by saying 'list', although it does not cover rate limits or authentication detail.

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, each serving a distinct purpose: statement of purpose, supportable capabilities, and a field limitation with an alternative call. There is no fillable extra text or irrelevant detail; every sentence is front-loaded and adds value.

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 presence of an output schema means return values do not need full explanation; the description still covers the critical limitations and directs the agent to a richer tool. It does not mention the sibling 'inspections_list_inspections_view', which could cause mild ambiguity, but the overall context is sufficient for guided use.

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 covers all three parameters with 100% description coverage, so the schema already explains limit, template_id, and modified_after. The description repeats the 'modification date' and 'limiting' concepts but adds no new parameter-level semantics 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 states the specific verb and resource ('List inspections from the Mitti account') and explicitly differentiates this tool from get_inspection by saying 'Call get_inspection with a specific audit_id for full details.' It also communicates the limited field set, which helps distinguish it from a fuller inspection 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?

It explicitly tells the agent when to use get_inspection instead ('Call get_inspection with a specific audit_id for full details'), serving as a clear alternative. It also describes the general filtering and limiting capabilities, giving a sense of when the 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds meaningful behavior context: the result is an interactive, sortable, searchable table rendered in conversation, and it only exposes audit_id, template_id, and modification date. This goes beyond a generic list operation and informs the agent about constraints, though it stops short of discussing pagination or precise interaction mechanics.

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

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

Three sentences with no fluff: the first states the core action, the second gives a direct usage warning, and the third discloses the output limitation. Each sentence adds unique value and key 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 read-only listing tool with three optional, fully documented parameters, the description covers the tool's purpose, visual output, and column limitations. It does not provide an output schema but compensates by describing the rendered table. Slightly more detail about pagination defaults or sorting behavior could make it fully complete, but the description is adequate for correct invocation.

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

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

Schema description coverage is 100%; the input schema already fully documents limit, template_id, and modified_after with types, defaults, and descriptions. The tool description adds no additional parameter-level meaning, so the baseline 3 for high schema coverage 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 clearly identifies a specific verb (show), resource (inspections from the Mitti account), and delivery mode (interactive, sortable, searchable table rendered in conversation). It also explicitly differentiates from list_inspections by the visual browsing use case, making the tool's unique purpose unmistakable.

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 states when to use this tool: 'Use this instead of list_inspections when the user wants to browse inspections visually.' This gives the agent a clear routing rule and names the alternative, satisfying the when/alternative requirement.

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 present, the description carries the full behavioral burden and handles it admirably. It explains that the user sees an approval card, that the decision appears as a conversation message in a specific format, and that the agent must halt until that message arrives. This gives the agent an accurate mental model of the tool's asynchronous interaction pattern.

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 longer than average but every sentence earns its place: purpose, proactive usage, card behavior, response format, and required post-call behavior. The structure is front-loaded and logically ordered, making it easy for an agent to extract the key rules.

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 an interactive approval tool with no annotations and no output schema, the description is remarkably complete. It covers the UI presentation, the user response mechanism, the mandatory stop-and-wait behavior, and the appropriate actions after approval or rejection. No critical behavioral context appears to be 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 description coverage is 100%, so the schema already documents each parameter. The description does not add meaningful parameter-level detail beyond mentioning the summary and optional details, and it does not clarify the button variant parameters. This matches the baseline score for a fully documented 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 opens with a specific verb and resource: 'Request human approval before proceeding with an action.' This clearly distinguishes the tool from the unrelated inspection, template, action, and user siblings. There is no ambiguity about what the tool accomplishes.

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 explicit when-to-use guidance: call proactively before significant or irreversible actions, and do not wait for the user to request approval. It also tells the agent to stop after calling and wait for the user's decision, with clear instructions for both approved and rejected outcomes.

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 behavioral burden. It discloses that only summary metadata is returned and names the exact fields. The read-only nature is implied by 'Get summary metadata', though not explicitly 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?

Two tight sentences: the first states purpose and scope, the second lists return fields. No filler or redundant restatement of the 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 single-parameter get-by-ID operation with an output schema, the description covers purpose, selection, and return contents. No additional context is needed for correct invocation.

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

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

Schema coverage is 100% and the schema already documents template_id, including the 'template_' prefix. The description only adds 'by its ID', which does not materially enrich parameter semantics beyond 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 uses a specific verb ('Get'), a clear resource ('summary metadata for a specific Mitti template'), and a selection criterion ('by its ID'). It also enumerates the returned fields, making it distinguishable from list and definition 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?

The description implies the tool is for retrieving one known template's summary metadata, but it does not explicitly state when to use this over templates_list_templates or templates_get_template_definition. There is no when-not or alternative 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 burden of behavioral disclosure. It only says the tool 'returns a structured summary,' which is vague and somewhat inconsistent with the earlier claim of returning the 'full definition.' It does not clarify permissions, errors, or what happens when the template_id is invalid.

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 with the core action in the first sentence. However, the second sentence repeats the idea of returning the template definition and uses the vague phrase 'structured summary,' so it does not fully earn its place as distinct, valuable 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?

For a one-parameter getter with an output schema available, the core invocation details are sufficient and the return format can be inferred from the schema. However, the ambiguity between 'full definition' and 'structured summary,' plus the lack of distinction from templates_get_template, leaves the agent with incomplete context for confident tool selection.

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 single parameter template_id is already fully documented with its type and prefix convention. The description adds no parameter-level detail, so the baseline score of 3 is appropriate given the schema does the heavy lifting.

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 ('Get') and names the resource ('full definition of a Mitti template'), enumerating contents such as questions, sections, and scoring rules. It is clear about what the tool does, but it does not differentiate itself from the sibling tool templates_get_template, which may look very similar to an agent.

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 about when to use this tool versus alternatives. The near-identical sibling templates_get_template is not mentioned or contrasted, leaving the agent to guess which retrieval tool fits the need. The only usage signal is the implied 'full definition' wording, which is not explicit enough.

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 behavioral disclosure burden. It clearly communicates the tool's limited return shape (ID, name, dates only) and directs the agent to get_template for omitted fields. It does not mention rate limits or auth, but for a simple read-only list with an output schema, this is strong behavioral 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?

The description is two sentences with no filler. The core action and return scope are front-loaded, and the pointer to get_template earns its place as actionable guidance.

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, an existing output schema, and two optional parameters fully documented in the schema, the description is nearly complete. It clarifies the returned data subset and the next step. Minor gaps are that it does not explicitly address pagination and does not disambiguate between templates_get_template and templates_get_template_definition.

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

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

Schema description coverage is 100%, so the schema already fully documents limit and archived. The description adds no additional parameter-specific meaning beyond the schema, 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 opens with a specific verb and resource: 'List templates available in the Mitti account.' It further distinguishes itself from get_template by stating exactly what fields are returned (ID, name, dates) and what is omitted, so an agent can confidently differentiate it from 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?

The description explicitly states when to use the full-detail sibling: 'description, owner, and archived status require get_template,' and instructs the agent to use the returned template_id to get the full definition. This provides clear when-to-use and when-not-to-use 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?

With no annotations to fall back on, the description carries the full burden of behavioral disclosure. It does this excellently by stating that the tool always returns failure and includes guidance toward a working alternative, preventing false expectations.

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-loads the nominal purpose, and immediately adds the critical caveat. There is no wasted verbiage, and the most important behavioral fact is prominent.

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 zero parameters, presence of an output schema, and the explicit failure-plus-alternative behavior, the agent has everything it needs to decide not to call the tool and to use users_search_users instead. 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?

The tool has zero parameters, so schema coverage is trivially 100%. The description has no input semantics to add; the baseline of 4 for a zero-parameter tool 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 the intended operation — get the profile of the currently authenticated Mitti user — and immediately contrasts it with the actual behavior: the endpoint does not exist and always returns failure. This clearly distinguishes it from sibling tools like users_search_users and users_list_users.

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 goes beyond vague context by explicitly telling the agent that this tool always fails and that the alternative, search_users with a known email, should be used instead. This is a direct when-to-use/when-not-to-use statement.

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 burden of disclosing behavior. It warns that status is only 'active' or 'inactive' with no 'pending' status, and notes the role indicator is 'best-effort', providing important caveats about data accuracy. It does not mention pagination, but the schema covers limit.

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 focused three-sentence structure: action, deliverables, and a practical use-case. There is no padding, and the most important fact 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 straightforward list endpoint with an output schema and two parameters, this description covers the essentials: what it returns, the status semantics, and why an agent would call it. It could mention pagination behavior, but the schema's limit and the simple nature of the tool make the gap minor.

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?

Given 100% schema coverage, a score of 3 is the baseline. The description adds meaningful nuance by explicitly defining the only possible statuses and calling out that 'pending' does no, which helps agents interpret both the status filter and the returned data.

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 it lists users in the Mitti organization and lists the returned fields, making the tool's action and scope specific. It does not explicitly distinguish itself from the sibling users_search_users, so it's strong but not a full 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?

It offers an implied use case ('Useful for finding user IDs to assign to actions'), but there is no explicit when-to-use guidance or comparison with alternatives such as users_search_users. The agent must infer the selection from the name and statement.

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 and discloses a significant non-obvious behavior: the API only supports exact-match filters, so the tool downloads all users and filters locally. It also states the returned fields, giving the agent a clear picture of side effects and cost.

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 focused sentences front-load the purpose, add a crucial efficiency caveat, and state return contents. No filler words; 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?

Given the two-parameter schema with full descriptions, an output schema, and the behavioral disclosure in the description, an agent has all the information needed to invoke this tool correctly. The efficiency warning is particularly important context.

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 description adds the important 'substring' interpretation of the query, plus the client-side filtering implication. The limit parameter is already fully described in the schema, so no further description 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 clear verb and resource: search for Mitti users by name or email substring. It does not explicitly name sibling users_list_users, so differentiation rests on the word 'search' rather than an explicit 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 warning about fetching all users for client-side filtering and being inefficient for large organizations gives an implicit when-not-to-use signal. However, it does not mention alternatives such as users_list_users or state precise conditions for choosing this tool.

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