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

With no annotations provided, the description carries the full burden. It discloses the critical fact that deletion is permanent, which alerts the agent to irretrievability. However, it does not mention required permissions, cascading effects on related resources (e.g., jobs/triggers), or side effects beyond the deletion itself.

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, dense sentence that conveys the core action, resource, permanence, and endpoint. Every word earns its place 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?

For a simple delete operation with one parameter, the description is adequate at a basic level. However, it omits practical details such as whether the deletion cascades to related recipes, what happens to in-flight jobs, expected response status, or authorization requirements. Since there is no output schema or annotations, the description should have provided more context for safe invocation.

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

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

Schema description coverage is 0%, and the description provides no additional meaning for the 'id' parameter beyond what the schema already conveys (an integer identifier). The parameter is straightforward, but the description does not compensate for the missing schema documentation, leaving any format constraints or context undocumented.

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 explicitly states the action ('Delete'), the resource ('a recipe'), and the permanence ('permanently'), also specifying the HTTP endpoint. This clearly distinguishes it from sibling tools like get_recipe, start_recipe, or list_recipes.

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 alternatives such as stop_recipe or reset_recipe_trigger. The description does not mention conditions, prerequisites, or scenarios where deletion is appropriate, leaving the agent to infer usage.

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 full responsibility for behavioral disclosure. It mentions a rate limit of 1 request per second, which is useful, but it does not disclose whether force_run is destructive, whether it interrupts an existing run, or what side effects it may have. This is a significant gap for an operation named 'force_run'.

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 to the point, with the endpoint reference and rate limit in a single sentence. No filler words appear, though it could have expanded on behavior without becoming verbose.

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 simplicity (one parameter, no output schema) the description is minimal but missing critical context: return value, error behavior, and the difference from start_recipe. The rate limit is noted but not the nature of the operation, so an agent lacks enough context to safely invoke this 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 input schema contains a single 'id' parameter with no description, and the schema description coverage is 0%. The description does not explain what 'id' refers to (though the endpoint implies recipe_id) or provide any additional meaning. Since the description does not compensate for the schema's lack of documentation, the semantic coverage is poor.

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 names a specific action ('Force-run') on a clear resource ('a recipe') and includes the endpoint path. However, it does not differentiate itself from the sibling start_recipe, so an agent may not know when force-run is appropriate instead of a normal start.

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 force_run versus start_recipe or other recipe-related tools. The only usage hint is 'on demand', which is vague and does not explain prerequisites or conditions that would warrant forcing a run.

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 explaining side effects. 'Get details' clearly signals a read-only operation, but no other behavior is disclosed (e.g., whether the call may fail if the ID doesn't exist, or if any remote fetch is involved). The description is not misleading, but it provides minimal behavioral context beyond the obvious.

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 one concise sentence that is front-loaded with the action and subject. Every word earns its place; there is no fluff or redundancy. It is optimally sized for the tool's simplicity.

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 tool with one parameter and no output schema, the description gives the caller the essential information: what it does and the key parameter. However, it does not explicitly state what is returned ('details' is vague) or error behavior if the ID is not found. This is adequate but not comprehensive, especially given the absence 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?

The schema has one required parameter 'id' with no description coverage. The description says 'by id', which clarifies that the parameter refers to the connection identifier, adding meaning beyond the raw schema. However, it does not elaborate on the source or format of the ID, or what happens for invalid IDs. Minimal but sufficient for this single-parameter tool.

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

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

The description clearly states a specific operation: 'Get details' with resource 'single connection by id'. This distinguishes it from list_connections, which would return multiple. However, it does not explicitly contrast with sibling tools, but the resource and single entity modifier make the purpose 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 instruction 'single connection by id' implies use when you have a specific connection ID and need its details, versus list_connections for all connections. This is an implied usage context, but no explicit alternatives or exclusions are given. It is adequate but not as strong as naming the alternative.

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 clearly indicates a read operation ('Get metadata'), implying no destructive side effects. However, it does not disclose potential error behaviors, permission requirements, or the structure of the returned metadata, which would be useful given the absence of an output schema.

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, concise sentence that directly states the tool's function with no filler. The key scoping ('by id') is front-loaded, making the purpose immediately clear.

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 parameterized get operation, the description covers the core purpose. However, without an output schema or annotations, the agent has no guidance on what the returned metadata contains or what happens if the id does not exist. This is a moderate gap for a tool that must be invoked autonomously.

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 explain the 'id' parameter. It does so by stating the operation is 'by id', which tells the agent that the parameter identifies the target connector. However, it provides no additional context such as where to find the ID or what values are valid, beyond the integer type already 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 uses a specific verb ('Get') and resource ('metadata of a custom connector') with a clear scope ('by id'). It unambiguously distinguishes this tool from siblings like list_custom_connectors and get_custom_connector_code, which are related but different operations.

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 this tool should be used when fetching metadata for a single custom connector by its identifier, but it does not explicitly state when to choose this over get_custom_connector_code or list_custom_connectors. The usage context is clear enough, but no alternatives or exclusions are mentioned.

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 of disclosing behavior. It indicates a read operation but doesn't mention any authentication requirements, potential size of the returned code, error conditions, or whether the source code is always available. The description is minimal and doesn't go beyond the literal statement.

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, direct sentence that immediately states the purpose and the key detail (block DSL). There is no filler, and the essential 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 tool with a single simple integer parameter and no output schema, the description provides the essential information: it retrieves the source code of a custom connector by id. It names the return content type (block DSL). It lacks notes on error behavior or use cases, but given the simplicity of the operation, the description is mostly 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?

The schema has a single integer parameter 'id', and the description says 'by id', which adds minimal meaning by tying the id to the custom connector. However, with 0% schema description coverage, the description could have clarified what the id refers to (e.g., the custom connector's unique identifier) and any constraints like must be positive. It only states the obvious.

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 action ('Get the source code'), the specific resource ('custom connector'), and the key qualifier ('block DSL', 'by id'). This distinguishes it from the sibling tool get_custom_connector, which presumably retrieves the full connector object rather than just the code.

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 no guidance on when to use this tool versus alternatives like get_custom_connector, nor does it mention any prerequisites or excluded cases. There is no explicit routing to a sibling or indication of the distinct use case beyond the immediate action.

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 disclose behavior. It states a read operation but omits any details about return format, potential errors, or access requirements. For a tool with no output schema, this leaves a significant transparency gap.

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

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

The description is a single, efficient sentence with no fluff. It is appropriately concise for such a simple tool, though it could be slightly more informative without becoming verbose.

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 that there is no output schema, the description should explain what 'details' will be returned. It does not mention any response fields, pagination, or handling of missing ids. For an agent to correctly interpret the result, this is incomplete.

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 single required parameter 'id' is referenced in the description ('by id'), clarifying its role. However, the schema provides no description for the parameter (0% coverage), and the description does not elaborate on what type of id or how it should be formatted. It adds minimal meaning beyond the schema's type declaration.

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 action ('Get details') and the resource ('folder/project by id'), making it distinct from list_folders (which lists all folders). It specifies the key identifier needed to retrieve a single item.

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 you have a specific folder/project id, but it does not explicitly mention when to prefer get_folder over list_folders or other sibling tools. There is no direct exclusion or alternative guidance, leaving the context to be inferred.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool returns details including input/output and error trace, suggesting a read-only operation. It does not mention side effects, authentication, or error behavior, but for a simple single-job getter, the provided behavioral indicators are reasonable. A 3 reflects the partial disclosure.

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 completely front-loaded, stating the verb and object first, then adding the key extra details. There is no filler or redundant content; every word contributes to the meaning.

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 there is no output schema, the description must explain the return value. It mentions 'input/output and error trace', which gives a partial picture, but it does not enumerate other job attributes (e.g., status, timestamps, execution time). For a get-job tool, a bit more on what 'details' includes would help. It is adequate but not fully 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?

The schema has only one parameter 'id' with zero description coverage. The description merely says 'by id', which essentially restates the parameter name without adding meaningful semantics. It does not describe the format, range, or whether the ID is numeric (integer). With low schema coverage, the description fails to compensate, offering minimal value.

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?

Description uses a specific verb ('Get'), a clear resource ('a single job'), and focuses on the scope ('by id'), while mentioning what is included (input/output and error trace). This clearly distinguishes it from sibling tools like list_jobs, which lists multiple jobs. The purpose is 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 clearly implies when to use the tool: when you have a job ID and need details about a single job. However, it does not explicitly state when not to use it or mention alternatives (e.g., list_jobs for listing) and provides no exclusions. This leaves the agent to infer the boundary partially.

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 disclosure burden. It reveals the tool's behavior by listing the returned fields (name, description, code, config, trigger, status, job counts, tags, version info) and explains the includes parameter's effect. It does not cover error handling or auth, but for a read-only GET this is reasonable.

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, dense with useful information. The main purpose is front-loaded, and the optional parameter tip is separated clearly. 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 single-resource fetch, the description is nearly complete: it states the resource identifier, the expected output fields, and the optional include behavior. Missing details like error cases or authentication are minor for this simple GET tool. The returned field list partially compensates for the absence 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 baseline is 3. The schema already explains both id and includes, and the description reinforces the includes usage without adding significantly new meaning 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 a specific verb ('Get full details') and a specific resource ('a single recipe by id'), and explicitly names the endpoint. It distinguishes itself from sibling list tools like list_recipes by emphasizing 'single recipe', so an agent can clearly understand 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 description provides clear context: use this to retrieve full details for one recipe by id, versus listing or searching. It does not explicitly name alternatives or exclusion conditions, but the 'single recipe' phrasing and the inclusion of the includes parameter give enough guidance for correct 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states only that the tool lists properties but does not mention pagination, return format, ordering, rate limits, or any side effects (though likely read-only). Minimal behavioral context beyond the obvious 'list' action.

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, clear sentence with no filler. The parenthetical clarification adds value without bloating the text, and the core verb-resource pair 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 parameterless list operation, the description is nearly complete: it names the resource and its scope. However, without an output schema it does not describe the response structure or whether the result is an array, which would be useful but not critical for 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 tool has zero parameters and schema coverage is 100%, so there is no parameter information missing. The description correctly implies no inputs are needed, matching the empty 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 states a specific verb ('List'), a distinct resource ('account properties'), clarifies what they are ('named constants'), and scopes them to the Workato account. This clearly differentiates from sibling list tools like list_recipes or list_jobs.

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 provided about when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or alternative tools for similar purposes, leaving the agent to infer usage solely from the tool name.

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

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

There are no annotations provided, so the description must carry the full burden of disclosing behavior. The description just says 'List' without revealing that the operation is read-only, that it returns a paginated result, or that it does not modify state. It adds no information beyond the obvious list intent.

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

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

The description is a single, short sentence which is concise, but it omits essential details about pagination and parameters. It is not structured to front-load the most useful constraints or intent behind the list operation. The brevity is a trade-off with completeness.

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?

This is a list tool with two parameters and no output schema or annotations. The description provides only a minimal statement, leaving the agent with no understanding of what a 'connection' consists of, how pagination works, or what the return structure is. This is heavily insufficient for correct usage.

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

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

Schema description coverage is 0%, and the description does not explain the two parameters 'page' and 'per_page' at all. An agent has no idea that 'per_page' controls page size or that 'page' starts at 1. The description fails to compensate for the lack of schema 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 states a clear action ('list') and a clear resource ('connections'), and the 'configured in the account' clarifies scope. It is distinct from get_connection (which likely retrieves a single connection) and from list_custom_connectors (which lists a different resource). However, it does not elaborate on what counts as a connection or which account is meant.

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 no guidance on when to use this tool versus list_custom_connectors or get_connection. It does not mention any typical scenarios, exclusions, or criteria that would help an agent decide between the siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List', implying a read operation, but does not mention pagination behavior, output format, permissions, or any side effects. No behavioral traits beyond the literal verb are disclosed.

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

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

The description is a single short sentence with no redundancy, but it is under-specified. While concise, it omits essential context, and the simplicity does not compensate for lack of substance.

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 list tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It lacks pagination semantics, return value details, and any usage context 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?

The schema description coverage is 0%, and the description does not mention the 'page' or 'per_page' parameters at all. An agent has no way to know their meaning, defaults, or allowed ranges from the description, and the schema itself provides no 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 states a specific verb ('List') and resource ('custom connectors') with a scope ('in the account'), clearly conveying the tool's basic function. However, it does not explicitly differentiate from sibling tools like get_custom_connector, relying instead on the name 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?

No guidance is provided on when to use this tool versus alternatives such as get_custom_connector or search_recipes. The description offers a bare action statement with no 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?

With no annotations, the description must disclose behavior, but it only states the basic listing action. It does not mention pagination semantics, response shape, whether folders include hierarchy, or any permissions required. The agent is left without crucial operational 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?

Two short sentences, no fluff, and the core action is front-loaded. The second sentence adds useful domain context. From a pure conciseness and structure standpoint, it is excellent.

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 list tool, the description is too thin given no annotations and no output schema. It does not explain pagination parameters, return format, or relationship to get_folder. An agent would struggle to know how to use pagination or interpret results without additional assumptions.

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

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

Schema description coverage is 0% and the description does not mention the parameters page or per_page at all. Since the schema itself provides no descriptions, the complete burden falls on the description, which fails to explain the meaning or expected values of these parameters.

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

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

The description uses a specific verb ('List') and a clear resource ('project folders in the account'), and adds context by explaining that folders group recipes and connections. This unambiguously distinguishes it from sibling tools like list_recipes or list_connections.

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 no guidance on when to use this tool versus alternatives such as get_folder or list_recipes. There is no mention of scenarios, prerequisites, or exclusion criteria, leaving the agent to infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions a listing operation and filters, but doesn't disclose pagination behavior (page/per_page), how filters combine, or any response format. For a read-like tool with zero annotation coverage, this is insufficiently transparent.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the action, filters, and a use case, though it omits some critical details that would make it more complete.

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 7 parameters, no output schema, and no annotations, the description only scratches the surface. It fails to clarify pagination, flow_id semantics, output shape, or how this tool relates to get_job. The agent is left with too many open questions to invoke it reliably in unfamiliar contexts.

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 only 14%, so the description must compensate for undocumented parameters. It mentions recipe_id, status, and date range but omits flow_id, page, and per_page entirely. Since pagination and flow_id are left unexplained and the coverage gap is large, this scores low.

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

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

The description clearly states a specific verb (List) and resource (jobs), and mentions optional filters, making the core action unambiguous. However, it does not explicitly differentiate this list tool from its sibling get_job (singular), so it stops short of a 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?

The phrase 'Useful for monitoring recipe execution history' gives a clear context for when this tool is appropriate, but it provides no exclusions or alternatives. There is no guidance on when to choose list_jobs over get_job or other list tools, leaving the usage guidance 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?

No annotations exist, so the description carries the full burden. It discloses pagination defaults (per_page=100, max 100), the performance impact of exclude_code, and the API's lack of name-search support. It does not mention rate limits or error behavior, but the disclosed details are substantive and useful.

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

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

Two clearly separated paragraphs: the first describes the tool's core behavior and key options, the second provides an important routing note. Every sentence adds information without 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?

For a complex, 12-parameter tool with no output schema, the description covers essential invocation details: scope, filters, pagination, performance optimization, and when to prefer a sibling. Nothing critical that an agent needs to call this correctly is missing.

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

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

With 83% schema coverage, the description adds value beyond the schema by summarizing the filter dimensions (folder, adapters, running status, date range) and highlighting the performance tradeoff of exclude_code. It also states default pagination values, which the schema does not fully convey.

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 lists recipes for the authenticated user via a specific endpoint, and explicitly contrasts it with search_recipes for name-based lookup. This distinguishes it from siblings and leaves no ambiguity about its function.

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

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

Explicitly instructs when to use search_recipes instead (when searching by name) because the API does not support server-side name search. This provides clear routing guidance relative to an alternative tool.

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 full behavioral burden. It discloses the operation and return value, but lacks details on failure behavior or side effects. For a read-only ping, this is an acceptable but not rich description.

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

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

The description is two sentences, front-loaded with the primary purpose and followed by a clear usage directive. Every word earns its place with no 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?

For a zero-parameter tool with no output schema, the description adequately explains what it does and when to use it. Minor gap: it doesn't specify response format or error behavior, but this is not critical for a simple connectivity check.

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, and the empty schema fully documents that. The description adds no parameter details, but the baseline score of 4 is appropriate for zero-parameter tools.

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 'Validate Workato credentials and return the current user,' which is a specific verb and resource. It clearly distinguishes this tool from siblings that manage recipes, jobs, and connections.

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 says 'Use this first to confirm the connection works,' providing clear when-to-use context. It does not mention alternatives, but none are relevant for a connectivity check.

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 full disclosure burden. It reveals the side effect of duplicate records and specifies the trigger type limitation, going beyond a generic 'reset' statement. It does not cover auth or rate limits, but the core behavior is transparent.

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

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

Three sentences cover the task, usage, constraints, and side-effect warning. It is concise without sacrificing essential information, though the lack of parameter detail keeps it from being perfectly 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?

For a single-parameter tool with no output schema, the description covers what it does, when to use it, its limitations, and a critical side effect. It lacks explicit info about the id parameter and the response format, but these are minor gaps given the tool's simplicity.

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 the tool description does not mention the 'id' parameter or what it represents. An agent must infer that 'id' refers to a recipe ID, but this is not explicitly stated in either the schema or description, creating a gap for correct invocation.

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 action ('Reset a recipe trigger cursor'), the resource ('recipe trigger'), and the endpoint. It also explains the purpose ('re-sync data from the source'), which distinguishes this from other recipe operations like starting or stopping triggers.

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

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

It explicitly states when to use it ('to re-sync data from the source') and includes critical constraints ('Only works with polling and scheduled triggers'). It doesn't name specific alternative tools, but the condition of usage is clear enough to avoid 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?

With no annotations, the description carries the behavioral burden. It discloses that the tool auto-paginates through all recipes and filters client-side, which is a critical implementation detail. It also gives a concrete example. However, it does not describe the return format, potential performance implications, or any rate limits, but the core non-obvious behavior is clearly revealed.

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 plus an example, with no wasted words. The key behavior (client-side filtering) is stated up front, and the example is substantive and aids understanding. 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 search tool without an output schema, the description sufficiently explains the main behavior and provides a realistic example. It does not detail the return shape or edge cases, but given four parameters and no nested objects, the description is reasonably complete. The absence of an output schema is slightly mitigated by the descriptive example.

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 75%, and the description adds extra meaning for the required 'name' parameter by giving a full example and emphasizing case-insensitivity. The other parameters already have descriptive schema text. The description enriches the primary parameter without needing to repeat all others.

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: 'Search recipes by name (case-insensitive)'. It names the specific resource (recipes) and the operation (search), with an explicit behavioral note about case-insensitivity. This distinguishes it from generic list/get operations among 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 explains why the tool exists (no server-side search, so it auto-paginates and filters client-side), which implies when it should be used. However, it does not explicitly state when to prefer this over list_recipes or other siblings, nor does it mention exclusions. Usage context is implied but not made 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?

No annotations are provided, so the description must carry behavioral disclosure. It only states 'Start (enable)' and the HTTP method, but does not explain what enabling a recipe entails, side effects, permissions, or whether it is reversible. This is a significant gap for an action-oriented 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 a single concise sentence with no redundancy, but it provides minimal information. While it is not bloated, it borders on under-specification rather than being a well-structured, informative summary.

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

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

With no output schema, no annotations, and no parameter explanation, the description omits crucial context such as what happens after starting a recipe, expected return values, or error conditions. Even for a simple action, the agent lacks enough information to confidently invoke the 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 input schema has a single 'id' parameter with 0% schema description coverage, so the description must compensate. The placeholder ':id' in the HTTP endpoint implies it is the recipe identifier, but the description does not explicitly define the parameter's meaning or format, leaving the agent to infer it from the tool name.

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 'Start' and resource 'recipe', and adds an 'enable' clarification plus the HTTP endpoint. This makes the tool's action clear, though it does not explicitly differentiate it from sibling tools like force_run_recipe or stop_recipe.

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 force_run_recipe or stop_recipe. The description only states the action without any context about prerequisites or conditions that would select this tool.

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 full responsibility. It discloses that the tool disables a recipe, but omits whether the operation is reversible, idempotent, whether it generates immediately, or any permission requirements. While not contradictory, the minimal behavioral context is only marginally adequate.

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 includes both the action and the endpoint. No filler or redundant explanation; it is front-loaded and 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 tool lacks an output schema and the description does not mention the response format, possible errors, or the expected outcome of the stop operation. For a simple state-changing action, it is minimally viable, but it leaves the agent guessing about what happens after 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 schema has one integer parameter 'id' with 0% description coverage. The description, via the endpoint :id, implies it is the recipe identifier, but it does not explicitly state a human-readable definition. Since it is a single parameter, the meaning is easily inferable, but the description doesn't add explicit semantic value.

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 ('Stop') and resource ('recipe'), and includes the exact endpoint (PUT /api/recipes/:id/stop), which is unambiguous. The verb clearly distinguishes it from siblings like start_recipe and force_run_recipe.

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

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

There is no guidance on when to use this tool versus alternatives, nor mention of prerequisites such as the recipe needing to be started. It does not explicitly state that start_recipe would reverse the stop, or that force_run_recipe might override a stopped state.

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