Klarefi

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

Annotations mark this as destructive and not read-only, but the description adds no behavioral context about side effects, permanence, or required authentication. It only provides value format constraints, which are more relevant to parameter semantics.

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, directly states the purpose and key formatting rules, with no filler or redundant content.

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 lacks guidance on authentication flow (url vs access_token+session_id) and doesn't explain task_id/session_id, which is significant given the tool's 6 parameters and no output schema. It is minimal and leaves important operational details for the agent to infer.

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 description adds format guidance for yes_no and date fields beyond the schema, clarifying acceptable values for the fields object. However, it doesn't explain the purpose or usage of task_id/session_id parameters, which are undocumented in the schema.

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

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

The description clearly states the tool's function: answering structured requested facts keyed by fact_id. It uses a specific verb and resource, but doesn't distinguish itself from the sibling tool answer_question, so it lacks sibling differentiation.

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

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

The description implies the tool is for responding to structured fact requests, but it doesn't explicitly say when to use it over answer_question or other intake tools. No exclusions or alternative recommendations 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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds minimal behavioral context beyond the parameters (free text, optional task_id) and does not contradict the annotations. It lacks details about workflow impact or reversibility, but the annotation covers the safety profile.

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

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

A single, front-loaded sentence that conveys the action, the target, and the optional parameter with no wasted words. The structure is extremely efficient.

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

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

The description is minimally viable for a mutating tool with annotations, but it assumes the reader understands the 'active applicant question' workflow and does not mention return values, errors, or how the session/url context is established. With no output schema, a bit more context about the expected outcome would improve completeness.

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

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

With 50% schema description coverage, the description compensates by clarifying the two key parameters lacking schema descriptions: text ('free text') and task_id ('optionally targeting'). The remaining parameters (url, session_id, access_token, api_base_url) already have schema descriptions, so the description fills the gap for the undocumented essentials.

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 ('Answer') with a clear resource ('active applicant question') and a distinguishing detail ('with free text'), which differentiates it from sibling tools like answer_fields. The optional task_id adds further scoping context.

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 responding to an active applicant question and optionally targeting a task_id, but it does not explicitly state when to use this vs alternatives (e.g., answer_fields) or mention any prerequisites or exclusions. Some usage context is present but not fully developed.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the description doesn't need to restate them. The description adds useful context that the result reports active vs staged-for-approval status, but it does not disclose the side effects of updating an existing manifest. No contradiction with annotations.

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

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

Two concise sentences, front-loaded with the primary action, with the second sentence adding unique output behavior. No redundant or filler content.

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 5 required parameters and no output schema, the description lacks parameter explanations and does not clarify what distinguishes a create from an update (e.g., existing connector_key). It also fails to mention the alternative create_connector_from_openapi, leaving an agent without enough information to invoke the tool reliably.

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 contains no property descriptions, and the description does not explain connector_key, label, connector_type, transport, or functions. Despite the context signal claiming 100% schema coverage, the visible schema provides zero parameter documentation, so the description should compensate and does not.

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 or update') and resource ('Klarefi verification connector manifest'), making the core action clear. However, it does not differentiate from the sibling tool create_connector_from_openapi, which likely overlaps in purpose.

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 versus create_connector_from_openapi or delete_connector. The description implies a create/update operation but never states prerequisites, ordering, or exclusion conditions.

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?

It discloses important behavioral context: the created connector may be 'active' or 'staged for operator approval', which goes beyond the annotations. The annotations already indicate this is not read-only and is destructive, so the description adds the approval/activation nuance without contradicting the structured metadata.

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

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

Three short sentences deliver the core purpose, the key format constraint, and the post-import result behavior. There is no filler or repetition; every sentence adds distinct 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?

The description is adequate for understanding the tool's basic operation and result, but it leaves gaps around parameter meanings and prerequisites for a 4-parameter creation tool. There is no output schema, so the description's brief mention of active/staged status is helpful but not a full substitute for more explicit behavioral or parameter detail.

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 only implicitly clarifies openapi_url as a public JSON URL. It does not explain connector_key, label, or base_url beyond their names, and it fails to specify the required identifier semantics or how the optional fields are used.

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 the action ('Import'), the resource ('public OpenAPI JSON URL'), and the output ('a Klarefi verification connector'). It also adds format constraints and result state. However, it does not explicitly differentiate itself from the sibling create_connector tool, relying mostly on the tool name to make that distinction.

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 concrete usage constraints: the URL must be public, the spec must be JSON, and YAML must be converted first. It tells the agent when this tool is appropriate based on spec format, though it does not call out alternatives such as create_connector or delete_connector.

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

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

The description simply restates the tool's name and offers no additional behavioral disclosure. It does not mention side effects like persisting a session, generating a URL, or requiring specific permissions, and the annotations (all false) provide no useful signal. With no annotation support, the description carries full burden but fails to add value.

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 its brevity undermines usefulness. For an 8-parameter tool with no output schema, one sentence is under-specification rather than appropriate conciseness.

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 provides almost no context for a complex tool. It does not explain what a 'hosted' session entails, what the return value is, how to construct the prefill object, or any constraints around the parameters. Combined with missing output schema and sparse schema descriptions, the tool is far from adequately specified.

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 description is silent on all eight parameters, and the schema's own description coverage is only 13% (just prefill). The required case_type_id and key options like ttl_hours, return_url, and external IDs are left completely unexplained, leaving the agent to guess their meaning and constraints.

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 identifies a specific action (create) and a resource (a hosted Klarefi intake session), but it does not explain what that session actually is or how it differs from related tools like open_intake or submit_intake. The phrase 'Klarefi intake session' is jargon without context, leaving the purpose somewhat vague.

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 versus siblings, nor are any prerequisites or preconditions mentioned. An agent is left without context on whether this is the right tool for starting a new intake flow or whether other tools such as save_intake_draft or submit_intake are more 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?

The annotations already establish destructiveHint=true, while the description adds useful context by mentioning that deletion may be staged for operator approval. This goes beyond the annotations, but it leaves ambiguous what triggers staging and what the outcome of the call 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 sentence with no redundant phrasing. It front-loads the primary action and then adds the important staging nuance, making it easy to scan 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?

For a one-parameter destructive tool, the description gives the essential action but not enough detail about the staging behavior, the meaning of connector_key, or what the caller should expect after invocation. The destructive annotation covers the safety profile, but operational expectations remain unclear.

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?

With 0% schema description coverage, the description must clarify connector_key. It does partially by saying the operation happens 'by key', indicating that connector_key selects the connector. However, it does not explain what a key is, where to find it, or its expected format.

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 ('Delete') with a specific resource ('configured Klarefi connector') and a clear lookup method ('by key'). It also distinguishes itself from the sibling create_connector tools simply by naming the deletion 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 intended use is implied: call this when you want to remove a configured connector. However, it does not explain when direct deletion applies versus when deletion is staged for operator approval, nor does it mention any prerequisites 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?

Annotations already declare read-only and idempotent behavior. The description adds that the tool retrieves 'resolved facts,' which gives some indication of the return payload but doesn't elaborate on formatting, pagination, or any side effects. It provides minimal additional behavioral context beyond annotations.

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

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

The description is a single concise sentence that directly states the action and resource, with no extraneous content.

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 with one parameter and no output schema, so the description is relatively complete for basic use. However, the term 'resolved facts' is undefined, and there is no mention of what the response contains or any edge cases, leaving some ambiguity.

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 sole parameter case_id is required, but the schema has no description. The description mentions retrieving a case but doesn't directly explain the case_id parameter or its format. Given the low schema coverage, the description does little to compensate, offering only implicit identification.

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 'Retrieve' and identifies the resource as 'a Klarefi case and resolved facts.' This clarifies the tool's function and distinguishes it from sibling tools like get_case_package and get_case_workspace, though it doesn't explicitly contrast them.

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

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

There is no information about when to use this tool versus alternatives such as get_case_package or get_case_workspace. No exclusions or preferred scenarios are provided, leaving the agent without guidance on tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds that the URL is 'signed read-only', reinforcing the non-destructive nature. It also clarifies the specific return artifacts, which is useful beyond the annotations. No contradiction found.

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 is front-loaded with the action and key objects. Every word contributes value, and there is no unnecessary elaboration.

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 one-parameter tool with good annotations, the description covers the basic purpose and return objects. However, it lacks usage context vs siblings, what 'cited' means, and any mention of output format. It is adequate but has clear gaps.

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 has one required parameter, case_id, with no description and 0% schema description coverage. The description does not explain case_id's format, meaning, or relationship to the 'cited' case package. The tool name provides context, but the description fails to compensate for the uncovered schema.

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

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

The description uses a specific verb ('Get') and clearly identifies the resources: the cited case_package.v1 artifact and a signed read-only case-file URL. This distinguishes it from sibling tools like get_case or get_case_workspace, which focus on other case-related data.

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 such as get_case or get_case_workspace. The description only states what the tool does without providing context, prerequisites, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's statement 'This does not mutate the case' is redundant. The description adds context about the returned content but no additional behavioral traits (e.g., rate limits, auth requirements) beyond what annotations provide.

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 that is concise, front-loaded with the action, and provides specific content details without extra fluff. Every word contributes to understanding the tool's 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?

For a simple read-only tool with one parameter and strong annotations, the description lists the key components of the workspace, which serves as an implicit return-value preview. It does not mention edge cases or pagination, but the tool's scope and safety profile are well covered.

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 has one parameter (case_id) with 0% description coverage. The tool description does not explicitly explain the parameter, but the name 'case_id' combined with 'Inspect a case workspace' makes its purpose inferable. This indirect clarification is enough for a baseline, but the description does not add meaningful detail beyond the schema.

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

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

The description uses a specific verb ('Inspect') and resource ('case workspace'), and enumerates the components (facts, cited evidence, blockers, ownership, timeline). This clearly distinguishes it from sibling tools like get_case or get_case_package by focusing on the workspace's internal contents.

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 when a user needs to inspect the case workspace, but it does not explicitly state when to prefer this tool over alternatives such as get_case or get_case_package. No when-not or alternative guidance is provided, so the usage context is only implied.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safe read behavior is known. The description adds context about the hosted MCP endpoint and authentication requirements, but does not disclose return format, error scenarios, or state semantics beyond what 'state' implies.

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, tight sentence that states the action and parameter usage without unnecessary verbiage. 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?

While the description is adequate for a simple getter, it omits any details about the return value (what constitutes 'intake state'), and api_base_url is not mentioned. Without an output schema, this lack of context leaves some ambiguity for the 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 coverage is 75%, and the description reinforces the relationship between url and session_id/access_token, which is already partially described in the schema. It does not clarify api_base_url, and session_id lacks a schema description, so the description adds limited new meaning.

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 fetches the current applicant intake state, using a specific verb and resource. It is distinct from sibling tools like get_case or open_intake, though it doesn't explicitly differentiate itself.

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 on when to use this tool versus alternatives like open_intake or get_case. The description only explains parameter combinations (url or session_id + access_token) for the hosted endpoint, not selection criteria.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds the behavioral trait of polling (repeated calls expected) and indicates the response contains a status and result, which is useful context beyond the annotations.

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

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

The description is a single, front-loaded sentence with zero waste. It conveys the action, resource, and result type efficiently, earning its place without redundancy.

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

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

The tool is simple with only two parameters and no output schema, but the description does not mention return format, possible status values, error behavior, or how to use the result. Given the richness of annotations and the context of sibling tools, it is minimally sufficient but lacks operational details for an agent to fully anticipate the response.

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% description coverage and the description itself does not explain `case_id` or `command_id`. While the parameter names are somewhat self-explanatory, the description adds no meaning or context about their format, relationship, or how to obtain them, so it fails to compensate for the schema's lack of descriptions.

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 'Poll' and a clear resource 'status and result of an intake-review command', which clearly distinguishes it from sibling tools like `get_case` or `submit_case_review`. It unambiguously states what the tool does and its scope.

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

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

The word 'Poll' implies usage after initiating a review command, but the description does not explicitly state when to use this tool versus alternatives like `get_case` or `get_intake_state`. No exclusions or alternative tools are mentioned, so the usage guidance is implied rather 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?

Annotations already declare the operation as read-only, non-destructive, and idempotent. The description adds useful context beyond these: it specifies the 'bounded' nature, environment scoping, and the required permission cases:review. This is valuable additional behavioral information without contradicting any annotation.

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 concise and front-loaded: two sentences that state the core action and the key requirement. Every word adds value, with no redundancy or filler.

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

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

Given a simple tool with one parameter, good annotations, and no output schema, the description covers essential context: purpose, environment scoping, bounded nature, and permission. It doesn't detail the return format, but that's less critical for a straightforward list operation, and the annotations cover the safety profile.

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 0%, meaning the description provides no explanation of the 'limit' parameter. Although the schema gives type and constraints (number, 1-200), the description doesn't compensate by explaining that 'limit' controls the maximum number of queue items returned. The parameter is named 'limit' and is fairly intuitive, but the description offers no semantic clarification.

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 action (List), resource (bounded Klarefi operator queue), and scope (for this API key's environment). This distinguishes it from sibling tools, none of which explicitly address operator queue listing.

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 clear context: it lists a bounded queue specific to the API key's environment and requires the cases:review permission. It doesn't explicitly name alternatives or exclusions, but no sibling tool serves the same purpose, so the context is sufficient.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful domain context by specifying that these are 'versioned' declarations and identifies the 'Form · Fact · Verify' classification, which helps the agent understand what the tool operates on without contradicting annotations.

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

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

The description is a single, front-loaded sentence with no unnecessary filler. Every word adds meaning and it is immediately clear what the tool does.

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 zero-parameter list operation with robust annotations, the description is adequate. It lacks details about return values or pagination, but given the simplicity and the absence of an output schema, the description covers the essential 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?

The tool has zero parameters, so the baseline is 4. The description offers no parameter details, but none are needed since there are no inputs to explain.

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 the specific verb 'list' and clearly identifies the resource as 'versioned Form · Fact · Verify workflow declarations', which distinguishes it from sibling tools like list_operator_queue or get_*. The qualifiers 'versioned' and 'Form · Fact · Verify' give precise scope.

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 that the tool is for listing workflow declarations, but it provides no explicit guidance on when to use it versus alternatives or any exclusions. There are no mentions of alternative tools or contexts where this tool is inappropriate.

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

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

Annotations already declare read-only and idempotent, and the description adds useful context: no API key required, and a credential reuse requirement for later calls. This supplements the annotation information without contradicting it.

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

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

Two sentences, front-loaded with the core action, no redundant text. Every sentence provides 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?

For a read tool with no required params and no output schema, the description covers the essential input selection and credentials. It could mention what is returned, but the name and purpose imply intake data.

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 75% and already describes most parameters. The description adds the key relationship that url OR session_id+access_token are alternatives, clarifying the mutual exclusivity not fully explicit in 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 clearly states the tool reads an applicant intake, with two alternative authentication methods (signed URL or session_id+access_token). It distinguishes itself from sibling tools that create, submit, or save intakes.

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?

Provides clear context on when to use: reading an intake via hosted or local endpoint. Includes specific guidance about credentials and the hosted endpoint, but does not explicitly mention alternatives 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?

Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description's disclosure burden is lower. It adds useful behavioral context by clarifying that the operation does not submit and that field values must be strings or null, but it does not explain the nature of the destructive behavior (e.g., overwriting existing drafts) or other side effects beyond what annotations imply.

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

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

The description is a single sentence with no unnecessary words. It front-loads the key action and constraint, making it easy to parse. Every word earns its place.

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

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

Given the tool's moderate complexity (5 params, nested object) and high schema coverage, the description provides the essential context: purpose and a key constraint. It doesn't explain alternative parameter combinations (url vs. session_id/access_token), but those are described in the schema. The absence of an output schema also reduces the need for return-value details. Overall, it is sufficient for basic understanding, though slightly thin on side effects.

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 high (80%), so baseline is 3. The description adds significant meaning beyond the schema by specifying that field values must be strings or null, which is not stated in the fields property description (it only says 'additionalProperties: true'). This extra semantic guidance raises the score.

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 function: 'Save applicant form draft fields without submitting.' The verb 'save' and resource 'applicant form draft fields' are specific, and the phrase 'without submitting' distinguishes it from sibling tools like submit_intake. This makes the purpose immediately understandable and unambiguous.

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

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

The description provides clear context: it is for saving draft fields without submission, implying use when the user wants to preserve progress without finalizing. However, it does not explicitly name alternative tools (e.g., submit_intake) or state when not to use it, so it falls short of full explicit exclusion guidance.

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

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

Annotations already indicate destructiveHint=true, and the description does not contradict this. The description adds behavioral context by stating the tool validates and saves, and cannot publish or activate. However, it does not elaborate on side effects, such as whether existing drafts are overwritten or if any permissions are required. This is sufficient given the annotations, but not rich.

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

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

The description is two short sentences with no filler. The main action is front-loaded, and the limitation is stated in a second sentence. Every word earns its place.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose and a key limitation. However, it omits details about return values, error behavior on validation failure, or what 'draft' implies in the system. The annotations mitigate some of this, but the description could be more complete for a mutation 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 has 0% description coverage and a single 'workflow' parameter that is an opaque object with additionalProperties: true. The description calls it a 'workflow declaration,' which gives some semantic hint, but it does not explain its structure, required fields, or validation criteria. With such low schema coverage, the description should compensate more than this.

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 function: 'Validate and save a workflow declaration as a draft.' It uses a specific verb ('save') and resource ('workflow declaration'), and the phrase 'as a draft' indicates the output state. This also distinguishes it from siblings like save_intake_draft, which targets intake drafts rather than workflow drafts.

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 clear context: use this tool to validate and save a workflow declaration as a draft. It also gives an explicit exclusion: 'This tool cannot publish or activate the workflow,' which tells the agent when not to use it. However, it does not name alternative tools for publishing or activation, so it falls 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?

Annotations already flag the tool as destructive and non-read-only. The description adds the 'auditable' trait and a high-level scope of allowed actions, but it does not explain side effects, permission requirements, or response behavior, leaving moderate gaps beyond what annotations imply.

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 only two sentences, front-loaded with the primary action, and every sentence contributes useful scope or exclusion information. There is no filler or redundancy.

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

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

Given the tool's complexity (6 parameters, nested payload, no output schema), the description is too sparse. It does not explain how to construct the command, what the payload should contain, or what the response will look like, making it insufficient for reliable 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?

With 0% schema description coverage, the description must compensate for parameter explanations. It only loosely maps command_type to the listed command categories, but leaves case_id, payload, trace_id, rationale, and idempotency_key unexplained. This partial coverage earns a low score.

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 function: submitting an auditable intake-review command. It enumerates the allowed command categories and explicitly excludes completing or reopening a case, which distinguishes it from sibling tools like submit_intake or get_review_command.

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 clear context about what commands are allowed and an explicit exclusion ('cannot complete or reopen a case'). However, it does not name alternative tools or provide direct 'use this instead of X' guidance, so it stops short of a perfect 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?

Annotations already declare destructiveHint: true and readOnlyHint: false. The description adds return-value information but does not disclose behavioral traits such as irreversibility, prerequisite conditions, or side effects beyond what the annotations already convey.

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 short sentences, front-loaded with the core action, and contains no redundant information. Every word earns its place.

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

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

Given the tool has 5 parameters, nested objects, no output schema, and is destructive, the description is thin. It mentions return values but not their structure, nor prerequisites or side effects. It is minimally sufficient but leaves gaps for an agent to infer.

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 80%, so the schema already documents most parameters. The description adds no parameter-level detail, but the baseline of 3 is appropriate given the high schema coverage.

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

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

The description uses the specific verb 'submit' with the resource 'applicant intake', clearly distinguishing it from sibling tools like 'save_intake_draft' and 'open_intake'. It also states the return value ('submitted, blockers, and the fresh intake state'), which clarifies the outcome.

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 this is the final action for an intake, contrasting with 'save_intake_draft', but it does not explicitly state when to use it or mention alternatives. The usage context is only implied, not fully specified.

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

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

The annotations already declare readOnlyHint:false and destructiveHint:false, so the description does not need to restate that this is a write operation. The description adds valuable behavioral details beyond annotations, such as the 5MB and 25MB size limits, the requirement to include url on every hosted call, and the fact that api_base_url is ignored on hosted. These specifics help an agent anticipate behavior without relying on annotations alone.

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 concise, using only three sentences. It front-loads the main purpose and then packs in usage constraints efficiently. Every sentence contributes essential information—purpose, parameter selection, and size limits—without redundancy or filler.

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

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

Given the tool has 9 parameters and no output schema, the description explains the main execution modes and size limits, but it does not describe the return value, success/error indicators, or how to handle failures. It also leaves several parameters unexplained. While the description covers the core usage well, the absence of output semantics and some parameter details makes it only partially complete.

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

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

With schema description coverage at only 44%, the description compensates by clarifying key parameter relationships: content_base64 for hosted, file_path for local, filename defaulting to basename, and api_base_url being local-only. It also explains size constraints tied to these parameters. This adds significant meaning beyond the raw schema, though some parameters (task_id, session_id, mime_type) remain under-explained.

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 ('Upload') and a clear resource ('requested applicant document'), making the tool's purpose immediately obvious. This clearly distinguishes it from siblings like submit_intake or save_intake_draft, which focus on other actions. The phrase 'requested applicant document' also suggests a precise context, enhancing clarity.

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 clear guidance on how to use the tool in different environments (hosted MCP vs. local stdio) and which parameters to use accordingly. However, it does not explicitly mention when to use this tool over alternative tools, or when not to use it, leaving some ambiguity for an AI agent. The environment-specific instructions are useful but not a full replacement for explicit usage boundaries.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description supplements this by revealing the polling loop and timeout behavior, which is valuable context. No contradiction exists with annotations.

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

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

The description is extremely concise—two sentences—with the primary action front-loaded. Every word earns its place, containing no fluff 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?

The description covers the core behavior (polling condition, timeout handling) and hints at the response via 'timed_out'. However, it does not describe the full response shape or provide guidance on parameter usage, leaving some gaps for a read-only polling tool.

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

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

Schema description coverage is 60%, leaving session_id and timeout_seconds undocumented. The description does not explain any parameters or add meaning beyond the schema, failing to compensate for the missing parameter 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 clearly states the tool's function: 'Poll until the intake leaves processing or the timeout expires.' This specifies a unique verb (poll), resource (intake), and condition, distinguishing it from sibling tools like get_intake_state or submit_intake.

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 clear usage context by defining when to poll and how to handle timeouts ('If timed_out is true, call wait_for_next_action again'). However, it does not mention alternatives or when not to use this tool, so it falls short of explicit exclusion guidance.

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