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

With no annotations, the description bears the full burden of behavioral disclosure. It only says 'clean up' without revealing whether cleanup is permanent, whether files are archived or deleted (though the schema mentions a type parameter), or any side effects or permission requirements. This is insufficient for a potentially destructive batch operation.

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

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

The description is a single, concise sentence that front-loads the verb and resource. No redundant words or filler, maximizing information density.

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 destructive batch operation with no annotations and no output schema, the description omits critical context such as default behavior when parameters are omitted (though schema covers defaults), potential side effects, return values, and permission requirements. Given the tool's destructive nature and many siblings, the description is under-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?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal extra meaning beyond the schema, only reinforcing the workspace/connector scoping. It does not clarify parameter interactions or defaults beyond what the schema already states.

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 'Clean up log files for specified workspaces and connectors' clearly states the tool's function (clean up) and resource (log files), and specifies scope (workspaces/connectors). It distinguishes this from sibling tools like delete_file (single file), delete_log (single log), and list_files (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?

No explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned. The phrase 'for specified workspaces and connectors' implies batch cleanup, but there is no comparison to delete_file or delete_log, leaving the agent without clear decision-making guidance.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the core behavior (copying settings and optional workspace) but does not disclose side effects such as whether the source is modified, what happens if the new connector ID already exists, or return values. This is adequate but not comprehensive for a mutation 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 two-sentence statement that is front-loaded with the main action. Every word earns its place, with no redundant information.

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

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

The tool has four parameters, no output schema, and no annotations. The description explains the purpose and the optional workspace parameter but omits details on return values, error conditions, or prerequisite checks. It's adequate for basic invocation but leaves some behavioral 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?

Schema description coverage is 100%, so all parameters are documented in the schema. The description only reinforces the behavior of newWorkspaceId by mentioning optional cross-workspace copying, adding no additional meaning 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 clearly states the tool copies connector settings to a new connector with a specified ID, using a specific verb and resource. It distinguishes itself from create/update by focusing on copying existing settings, and notes optional workspace targeting.

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 when to use this tool: when you need to duplicate a connector's settings, potentially into another workspace. It does not explicitly state alternatives or when not to use it, but the context is clear enough for an agent to select it over create_connector or update_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?

No annotations are provided, so the description must disclose behavior. It mentions the suffix for uniqueness but omits whether the new workspace is created (though schema hints), whether the source is affected, whether existing connectors in the target are overwritten, and what happens on failure. This leaves significant behavioral ambiguity.

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

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

Single sentence, front-loaded with the verb, and every phrase contributes meaning. 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?

The tool performs a complex bulk operation with potential side effects (creating workspace, renaming IDs, copying all connectors), and there is no output schema or annotations. The one-line description does not address return values, creation behavior, failure modes, or effect on source workspace, making it insufficiently 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?

Schema coverage is 100%, and the schema already describes all three parameters, including the suffix's purpose. The description adds little beyond restating the schema, so baseline 3 applies.

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

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

Description uses specific verb 'Copy' and clearly identifies the resource (all connectors) and transformation (suffix added to connector IDs). It distinguishes from sibling copy_connector which presumably copies a single connector.

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?

Description clearly states the action and context (copy all connectors from source to new workspace), making it obvious when to use. However, it does not explicitly mention alternatives like copy_connector for single-connector copies, so no exclusions are stated.

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 present, so the description carries the full burden. It discloses important behavior: the tool creates two files from one input, one containing the private key and one containing the public certificate. It also emphasizes that all four required parameters must be provided. Missing details like overwrite behavior or return values, but the core behavioral traits are clearly communicated.

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 well-structured: a one-sentence purpose, an IMPORTANT note about required parameters, followed by a clean bulleted breakdown of the two generated files. Every sentence serves an operational purpose without redundancy or fluff.

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

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

With 14 parameters, no annotations, and no output schema, this description compensates effectively. It explains the output artifacts, required inputs, and the typical AS2 integration use case. The only minor omission is potential conflict/overwrite behavior, but the description is sufficiently complete for an agent to correctly 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 already has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds value by re-emphasizing the four required parameters, advising a unique serial number (e.g., timestamp or random), and explaining how the filename parameter maps to two distinct output files. This goes beyond mere schema repetition.

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

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

The description opens with a clear verb+resource pair: 'Create a public/private certificate key pair.' It goes further by specifying the two output files (MyCert.pfx and MyCert.cer) and their uses, which distinguishes this creation tool from siblings like import_certificate and exchange_cert that handle existing certificates.

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 usage context by mapping the generated files to AS2 profile parameters (as2:signingkeypath, as2:privatekeypath, as2:publickeypath) and instructing that the .cer should be shared with trading partners. However, it does not explicitly mention when to avoid this tool in favor of alternatives, so it misses the 'when-not/alternatives' mark.

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 for behavioral disclosure. It mentions the required fields and default workspace, but fails to describe side effects (e.g., creating resources), idempotency, error handling, or whether special permissions are needed. For a create operation, this leaves important behavioral aspects undisclosed.

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 appropriately short and front-loaded with the core purpose. Each sentence serves a purpose: stating the action, listing required inputs, explaining a key property, and clarifying a default. It could be slightly more structured, but it is concise and readable.

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 16 parameters and no output schema, the description covers the essential creation context (required params, role of action, default workspace) without delving into optional parameter selection or return values. The 100% schema coverage compensates for most parameter-specific detail, but the lack of output/error information and connector-type-specific guidance makes it only minimally 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?

Schema coverage is 100%, so the description does not need to repeat parameter details. It adds minimal semantic value by explicitly naming the three required parameters and the default workspace behavior, both of which are already present in schema descriptions. The description thus provides no significant extra meaning 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 clearly states the tool's action ('Create') and resource ('a new Arc connector'), making it easily distinguishable from sibling tools like update_connector, delete_connector, and get_connector. The scope is explicit 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 some usage guidance by listing required parameters and explaining the default workspace behavior when workspaceId is omitted. However, it does not explicitly contrast with alternatives (e.g., update_connector for modifying existing connectors) or state scenarios where this tool should not be used.

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 fails to disclose any behavioral traits such as required permissions, whether content must be base64 encoded, side effects, or reversibility.

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 but under-specified. It essentially restates the tool name without adding substantive information, making it minimally viable but not appropriately sized for the tool's complexity.

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 11 parameters, 4 required, no output schema, and no annotations, this minimal description is completely inadequate. The agent receives no understanding of expected inputs, outputs, or 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?

The input schema has 100% coverage, so the description does not need to add parameter information. The baseline of 3 applies since the schema fully documents all 11 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 clearly states the tool creates a new Arc file with a specific verb and resource. However, it does not differentiate it from sibling tools like receive_file or send_file which may also create files.

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 receive_file or send_file. No prerequisites, context, or exclusions are provided.

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

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

With no annotations present, the description carries the full burden for behavioral disclosure, but it only states 'Create' with no details on side effects, permissions, failure modes, or return value. This is minimal and does not add meaningful context beyond the operation 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, clear sentence with no redundant words. It efficiently conveys the core purpose and is appropriately front-loaded, making it easy to parse.

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

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

For a tool with 12 parameters and no output schema, the description is underspecified. It lacks context about the return value, error conditions, or behavior of the created flow API. This is a significant gap given the tool's complexity.

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 all 12 parameters are already documented. The description adds no parameter-specific meaning beyond the schema; it only mentions the workspace scope, which is already in the schema. Baseline 3 is appropriate given the high 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 a specific verb ('Create') and resource ('Arc flow API') with a scope ('for a workspace'), clearly distinguishing it from sibling tools like get_flow_api, list_flow_apis, and delete_flow_api. It directly states what the tool does without ambiguity.

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 when to use the tool (when creating a new flow API) but provides no explicit context, exclusions, or mention of alternatives. It doesn't clarify prerequisites like needing an existing workspace or how this relates to update or delete operations.

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, but it only states that a report is created. It does not disclose side effects (e.g., saving, immediate execution, scheduling behavior), whether creation is reversible, or what response/ID to expect. This is a minimal disclosure for a potentially complex operation.

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 main action, and every sentence contributes. It avoids repeating schema details while highlighting the key column parameter.

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?

Although the tool has 16 parameters and no output schema, the rich schema descriptions cover all fields, and the description points to the most critical parameter. However, a brief overview of configuration categories (time period, scheduling, email, filters, grouping) would help an agent understand the tool's full capabilities at a glance.

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%, with detailed descriptions for all 16 parameters. The description adds emphasis on the 'Columns' parameter as critical and gives examples, but those examples are already listed in the schema's valid values, so it adds only marginal value beyond the structured field documentation.

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

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

The description clearly states 'Create a new Arc report' with a specific verb and resource, distinguishing it from siblings like list_reports, get_report, update_report, and delete_report. Mentioning 'specified configuration' reinforces the tool's creation role.

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

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

The description makes obvious the tool is for creating new reports, providing clear context for when to invoke it. It does not explicitly contrast with update_report or other alternatives, but the purpose statement alone gives sufficient guidance for typical use.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It only states 'Create' which implies mutation, but fails to mention potential side effects, required permissions, overwrite behavior, or return values. For a creation tool, this leaves the agent without knowledge of what happens when the vault entry is created.

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 redundant wording, making it efficient. However, it is so brief that it may under-specify, but conciseness is about eliminating waste rather than adding content. For the minimal content provided, it achieves the goal of being compact without 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?

Despite having 6 parameters (3 required), no annotations, no output schema, and sibling tools with similar operations, the description offers essentially no contextual information. It does not explain the purpose beyond the title, the meaning of the vault entry, the effect of creating, or any relevant details. For a tool with this complexity, the description is completely inadequate.

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 100% description coverage for all 6 parameters, so the schema already documents each parameter's meaning. The description adds no additional parameter context beyond the schema, which is acceptable but not value-adding. The baseline of 3 is appropriate because the schema carries the parameter documentation burden.

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 'Create a new vault entry' uses a specific verb and resource, clearly indicating a creation action. It distinguishes from sibling tools like get_vault_entry, update_vault_entry, and delete_vault_entry by the verb 'create'. However, it lacks any scope detail about what constitutes a vault entry, making it clear but not highly distinctive beyond the action.

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

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

The description provides no guidance on when to use this tool versus alternatives such as update_vault_entry or list_vault_entries. There are no usage scenarios, exclusions, or prerequisite conditions mentioned, leaving the agent without guidance on selecting this tool in context.

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

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

With no annotations to disclose safety characteristics, the description carries the full burden. It only states 'Create a new workspace' and fails to mention potential side effects, permissions, idempotency, or what happens on duplicate workspaceId or other error conditions.

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 conveys the tool's function with no unnecessary words. It is appropriately front-loaded and easy to parse.

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

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

Given the tool's relative simplicity and the full schema coverage, the description is minimally viable. However, the absence of annotations, lack of return value details, and no mention of behavioral constraints leave minor gaps that an agent would need to discover elsewhere.

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 already provides descriptions for all three parameters (name, description, workspaceId), achieving 100% coverage. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description 'Create a new workspace' clearly states the action (create) on a specific resource (workspace), making it distinct from sibling tools like get_workspace, update_workspace, and delete_workspace.

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 prerequisites for creating a workspace or scenarios where creating might not be appropriate. The description simply repeats the tool's basic function.

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. The word 'permanently' explicitly indicates an irreversible destructive operation, which is key transparency. However, it does not disclose potential failure conditions (e.g., certificate in use), required permissions, or side effects beyond the deletion.

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 immediately conveys the action and irreversibility. No redundant or extraneous text.

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 tool with one parameter and no output schema, the description adequately captures purpose and key behavior. It is slightly incomplete in not addressing error cases or post-deletion effects, but overall it is sufficient for an agent to invoke correctly in most 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?

The schema already provides 100% coverage by documenting 'name' as 'The name of the certificate file to delete'. The description adds no additional parameter semantics beyond confirming the resource type, so a baseline score of 3 is appropriate given 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 a specific verb ('Delete') and resource ('Arc certificate') with the adverb 'permanently' clarifying scope. It clearly distinguishes from other certificate tools (list, get, import, create, exchange) that do not delete.

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 this tool should be used versus alternatives, nor any prerequisites or conditions. It does not mention situations where deletion is not appropriate.

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

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

With no annotations, the description carries the full burden. It discloses that deletion is permanent, which is a key behavioral trait. However, it does not mention potential side effects (e.g., on dependent resources), required permissions, or error conditions, leaving significant gaps for a destructive operation.

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 with no wasted words. It is front-loaded with the verb and resource, making it 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?

Given the low complexity (single parameter, no output schema) and the absence of annotations, the description is minimally adequate. However, for a destructive tool, it would benefit from additional context on consequences, prerequisites, or expected behavior, which is missing.

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

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

Schema coverage is 100% for the single parameter 'connectorId', and the description does not add any semantic detail beyond what the schema already provides. The baseline of 3 applies because the schema fully documents the parameter.

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 (delete), the resource (Arc connector), and adds 'permanently' to indicate irreversibility. This distinguishes it from sibling tools like update_connector or copy_connector, making 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?

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or warnings about when not to use it. The phrase 'permanently' implies caution but does not explicitly address usage context.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It does add a key trait—deletion is permanent/irreversible—which is valuable. However, it omits other relevant details such as side effects on related records (e.g., transactions), required authorization, or behavior if the file does not exist.

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, compact sentence that conveys the essential action and a critical behavioral qualifier. Every word earns its place, and it is front-loaded with the action verb 'Delete'. No unnecessary 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?

The tool has 4 required parameters, no annotations, and no output schema. The description fails to explain the return value or success/error indication, which the agent needs to handle the result. It also does not clarify why connectorId and messageId are necessary for locating the file. For a mutation tool with no annotations and no output schema, this is insufficient.

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%, meaning every parameter (folder, filename, messageId, connectorId) already has a clear description in the schema. The tool description adds no additional meaning beyond that; it only reinforces that a specific file is targeted. Baseline 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 clearly states the action ('Delete'), the resource ('a specific Arc file'), and the critical qualifier ('permanently'). This distinguishes it from sibling tools like get_file, list_files, create_file, and update_file, making the purpose unmistakable.

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

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

No usage guidance is provided beyond the action itself. The description does not say when to use this tool versus alternatives such as cleanup_files (bulk deletion) or when deletion should not be performed, nor does it mention any prerequisites or restrictions.

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 discloses that deletion is permanent, which is a key behavioral trait. However, with no annotations, it does not mention other important factors such as idempotency, error handling, or authorization requirements.

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

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

The description is a single sentence with no filler, clearly front-loaded with the action and object.

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 delete tool, the description adequately conveys the purpose and a key behavioral aspect (permanence). It does not explain return values, but no output schema exists. Slightly more context about side effects or prerequisites could improve it, but the core functionality is clear.

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

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

The input schema covers 100% of parameter documentation, with workspaceId described as 'The workspace ID of the flow API to delete'. The description adds no additional parameter semantics, so baseline 3 applies.

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

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

The description uses a specific verb 'Delete', a specific resource 'Arc flow API', and an attribute 'permanently' that adds scope. It clearly distinguishes from sibling tools like delete_connector and delete_workspace.

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, nor any prerequisites or contextual conditions. It only states what it does, not when to invoke it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Delete' without indicating whether the operation is irreversible, requires specific permissions, or has cascading effects on related data such as transaction logs or reports.

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 with no filler words. It is concise and front-loaded with the action and target, though it could be improved by adding relevant context without sacrificing brevity.

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

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

For a simple deletion tool with no annotations and no output schema, the description omits important behavioral details such as return values, error handling, and prerequisites. While the schema covers the parameter, the tool description alone is minimally viable but incomplete for an agent to fully understand the operation's consequences.

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 fully covers the only parameter (logId) with a clear description (100% coverage). The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses the specific verb 'Delete' and identifies the resource as 'a specific log entry', making the purpose clear. It distinguishes itself from sibling delete tools (e.g., delete_connector, delete_file) by naming the log entry as the target, though it does not elaborate on what constitutes a log entry.

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_log, list_logs, or get_error_logs. There is no mention of prerequisites, exclusions, or scenarios where a different tool would be 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the key trait of permanent deletion, but it lacks any mention of side effects, permissions, or whether related data is affected. It adds some context but not rich behavioral transparency.

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

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

The description is a single, front-loaded sentence that states the action and the resource with no unnecessary words. It is highly concise and effectively structured.

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 delete tool with no output schema, the description is largely sufficient. It clearly states what is deleted and that deletion is permanent, which covers the main contextual need. It could be improved by explicitly mentioning that deletion is by name, but that is already implied by the 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 fully documents the only parameter 'name' with a clear description. The tool description itself does not elaborate on parameter usage, but since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description 'Delete an Arc report permanently' clearly identifies the verb (delete), resource (Arc report), and adds the important qualifier 'permanently' to signal irreversibility. It is distinct from sibling delete tools by specifying the report resource.

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 update_report or list_reports. There are no prerequisites, exclusions, or mentions of alternative tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive action, the description does not mention irreversibility, required permissions, potential side effects, or what happens to related data. The minimal statement lacks critical behavioral context for a delete operation.

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 and contains no filler. It efficiently communicates the core purpose without unnecessary 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 delete tool with one parameter and no output schema, the description covers the essential information. It says what the tool does and the schema identifies the required parameter. Given the low complexity, the description is adequate, though it could mention irreversibility or relation to request logging.

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% with the single requestId parameter clearly described. The tool description adds no additional parameter meaning, but the baseline of 3 is appropriate since the schema already provides full parameter documentation.

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

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

The description 'Delete a specific request log' clearly states the action (delete) and the target resource (request log). It distinguishes the tool from siblings like delete_log, delete_file, and delete_transaction by specifying the request log, and the verb is specific.

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. It does not mention any context, exclusions, or comparisons to sibling tools like delete_log or get_request. This is a no-guidance situation, falling between implied usage and no 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?

The description essentially restates the tool name and adds no behavioral context. It fails to disclose whether deletion is permanent, requires special permissions, or has side effects on related data, and no annotations are provided to fill this 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, direct sentence with no superfluous words, making it highly concise and easy to parse.

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

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

While the tool has a simple parameter set, it lacks annotations and an output schema. The description does not explain the result of deletion, irreversibility, or any related behaviors, leaving an agent without important context for a destructive operation.

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 fully documents the transactionId parameter with a clear description, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already covers.

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 'delete' and resource 'transaction', clearly stating it removes a single, identified transaction. This distinguishes it from sibling read/list tools like get_transaction and list_transactions.

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 regarding when to use this tool vs alternatives. It does not mention prerequisites, exclusions, or how it relates to other transaction tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete' which restates the tool's name and implies destructiveness, but it does not mention permanence, potential errors, required permissions, or any side effects. This is a minimal restatement rather than informative transparency.

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 with no filler or redundant information. It is appropriately sized for a simple tool with one parameter and effectively front-loads the action and target.

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 of the tool (one parameter, no output schema), the description is minimally adequate but lacks important context such as whether deletion is permanent, what happens if the entry does not exist, or any side effects. The description is not incomplete enough to be ineffective, but could benefit from more behavioral 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 input schema has 100% coverage with a clear description of the 'vaultId' parameter, so the schema itself provides the necessary semantics. The tool description adds no additional parameter meaning or usage detail, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Delete' and the resource 'specific vault entry', which clearly differentiates it from sibling tools like get_vault_entry, create_vault_entry, and update_vault_entry. The purpose is unambiguous and specific.

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 when to update rather than delete a vault entry. There are no prerequisites, exclusions, or context about appropriate use cases beyond the basic 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without explaining irreversibility, permissions, or side effects on associated data.

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 short, front-loaded sentence with no wasted words, making it easy to parse quickly.

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

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

The tool is simple with one parameter, but as a destructive operation with no annotations or output schema, the description lacks details about side effects or success behavior, making it minimally adequate.

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 fully describes the single parameter workspaceId (100% coverage), and the description adds no further meaning beyond 'by ID', so the schema does the heavy lifting.

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

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

The description uses a specific verb 'Delete' and resource 'workspace', clearly distinguishing it from sibling tools like create_workspace and get_workspace.

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 vs alternatives, nor are there any prerequisites, warnings, or exclusions 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 for behavioral disclosure. It only restates the action without revealing side effects, whether the operation is destructive, requires network connectivity, or expects particular protocol handshake behavior. This lack of additional context beyond the stated purpose is insufficient given the lack of annotation support.

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

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

The description is a single, efficient sentence that directly states the action and scope with no wasted words. It is well-structured and immediately front-loads the core purpose, though it could use the space to add a bit more context without losing 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?

This is a relatively complex tool with 9 parameters, 2 required, and no output schema. The description provides only a bare statement of purpose, leaving out crucial context such as the mechanics of the exchange, the significance of exchangeType values, conditional parameter requirements, and expected outcomes. The rich schema compensates somewhat, but the description alone is too sparse 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?

Schema description coverage is 100%, with each of the 9 parameters having a meaningful description including valid values for exchangeType and certificateUsage. The description itself does not add further parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'Exchange' with a clear resource 'certificate' and protocol scope 'AS2 or OFTP', distinguishing it from sibling certificate tools like import_certificate or delete_certificate. However, 'exchange' itself is slightly ambiguous and could benefit from more context about the nature of the exchange, so it falls 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 description implies use for exchanging certificates within AS2 or OFTP protocols, giving clear context about the intended domain. However, it does not explicitly state when to use this tool over alternatives like import_certificate or create_cert, nor does it mention any exclusions or prerequisites, so usage guidance 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?

With no annotations provided, the description carries the full burden. It does disclose that the key is exported as an encrypted package and requires a passphrase, which adds useful context. However, it does not state whether the operation is read-only, what side effects occur (if any), or what the output format is, leaving some behavioral ambiguity.

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

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

The description is a single, well-structured sentence that is front-loaded with the action and resource. There is zero waste; every word contributes to understanding the tool's purpose and key detail (passphrase protection).

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 is largely complete: it explains what is exported and how it is secured. The only gap is that it does not explicitly describe the return value or delivery mechanism (e.g., whether the package is returned in the response or written to a file), but the phrase 'export as an encrypted key package' gives a strong hint.

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

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

Schema description coverage is 100%, and the param description already fully explains that the passphrase is used to encrypt the exported key package. The tool description adds no additional semantic detail beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Export' and the resource 'Arc data encryption key', and specifies the output as an 'encrypted key package' secured with a passphrase. This differentiates it from sibling tools like import_data_encryption_key (opposite) and export_settings (different resource).

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 for safe transport/backup of the encryption key, but it does not explicitly state when to use this tool versus alternatives or any exclusions. For example, it does not mention using import_data_encryption_key for restoring the key, even though that sibling exists. Guidance is implied but not 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 present, so the description must disclose behavior. It does not mention that sensitive values are encrypted (flowPassword), whether the operation is read-only, or what the output is (e.g., a downloadable file).

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 words, making it highly concise.

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 7 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It lacks information about return values, output format, and edge cases like unspecified connectorId.

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

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

The input schema covers all 7 parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics 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 clearly states 'Export connector settings and workspace configuration to arcflow format', which is a specific verb+resource+format. It distinguishes from sibling tools like get_connector (single connector) and import_settings (opposite operation).

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 does not provide any guidance on when to use this tool instead of alternatives like export_data_encryption_key or get_workspace. It only states the function, leaving the agent to infer usage context.

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 burden. It states 'Get' which implies a read operation, but does not explicitly confirm non-destructiveness, permissions, or return format. The description adds minimal behavioral context beyond the tool name.

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 of 9 words, directly stating the purpose without any fluff. It is efficiently sized and 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?

The tool is simple with one required parameter, and the description conveys the operation clearly. However, 'detailed information' is vague and could specify what is returned, especially since no output schema exists. It is mostly adequate but has a minor gap.

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

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

Schema coverage for the only parameter 'name' is 100%, so baseline is 3. The description adds no additional parameter details beyond what the schema already 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 uses the specific verb 'Get' and identifies the resource 'specific Arc certificate', clearly distinguishing it from listing tools like list_certificates. It is a clear, non-tautological statement of the tool's 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?

The description implies usage for a single certificate via the word 'specific', but does not explicitly state when to use it versus alternatives or provide exclusions. It lacks direct guidance on when to prefer this tool over list_certificates or get_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?

With no annotations, the description must carry the full burden. It implies a read-only operation via 'Get' and 'Shows', and it adds the useful behavioral detail that all properties and current values are returned and that property names are compatible with update_connector. However, it does not explicitly state that there are no side effects, nor does it mention any prerequisites or response format caveats.

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

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

The description is two sentences with no filler. The first sentence front-loads the core purpose, and the second provides a concrete, actionable integration tip. Every sentence earns its place.

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

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

For a simple one-parameter get tool with no output schema, the description adequately covers the tool's purpose, the content of the response (all properties and values), and how to use the result. It lacks explicit error handling or edge-case details, but given the simplicity, it is largely 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 input schema provides 100% coverage for the single parameter connectorId with a clear description ('The unique identifier of the connector'). The tool description adds no additional parameter context (e.g., how to obtain the ID or any format constraints), so the baseline of 3 applies.

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

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

The description clearly states the action ('Get detailed information about a specific Arc connector') and the scope ('shows all available properties and their current values'). This distinguishes it from sibling get_* tools like get_file, get_transaction, and the list_connectors tool that presumably provides an overview.

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

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

The description provides a clear context for use by stating that the response contains all property names and values, and it explicitly instructs the agent to use those property names directly in update_connector. However, it does not explicitly name alternatives (e.g., list_connectors) or state when not to use this tool, so it falls just short of full guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states only the basic action and does not mention filtering behavior, default time ranges, or scope (e.g., all connectors vs. specific). The schema documents parameters, but the description adds no extra behavioral context.

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

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

The description is a single, focused sentence with no unnecessary words. It is concise and front-loaded with the key action.

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 optional parameters, but there is no output schema and there are overlapping sibling tools. The description does not explain return values or differentiate from related log-fetching tools, leaving the agent with limited guidance on selection and expected behavior.

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 provides complete descriptions for all three parameters (top, hours, connectorId), so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already documents.

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 'recent error logs', clearly indicating the function retrieves error logs. It does not explicitly differentiate from sibling tools like get_logs or get_transaction_logs, but the 'error' qualifier adds specificity.

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 only usage context is 'to help with troubleshooting', which implies a general use case but provides no guidance on when to use this tool versus alternatives such as get_logs or get_transaction_logs. No exclusions or alternative recommendations are given.

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 behavioral disclosure. It does not specify what constitutes a 'failed' request (e.g., status ranges as 4xx/5xx), how results are returned (pagination, list format), or any side effects. The schema documents parameters but not the operational behavior.

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, front-loaded with the verb ('Get') and resource ('recent failed HTTP requests'), with no redundant wording. It is appropriately concise for a simple retrieval tool.

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 this is a straightforward read tool with optional parameters and a fully documented schema, the description is adequate but not comprehensive. It lacks clarification of what 'failed' means and the return format, and it does not help differentiate among many sibling tools. Without annotations, more behavioral context would be needed for full 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?

Schema description coverage is 100%, with all three parameters (top, hours, statusRange) documented in the schema itself. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get') and a clearly identified resource ('recent failed HTTP requests'), making its purpose immediately apparent. It distinguishes from siblings like get_recent_requests or get_error_logs by focusing specifically on failed HTTP requests, even though 'failed' could be more explicit (e.g., status >=400).

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

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

The phrase 'for troubleshooting' implies a use case but is broad and does not provide explicit exclusions or alternatives. No mention is made of when to prefer this tool over get_recent_requests or get_error_logs, leaving usage guidance merely 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 are provided, so the description must carry the full burden of behavioral disclosure. It merely says 'Get detailed information' without mentioning read-only safety, permission requirements, error scenarios, or the content of the returned details. This is a minimal 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, front-loaded with the verb and resource, and contains zero filler words. Every word contributes to the core 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?

The tool is simple, and the schema thoroughly covers parameters. However, with no output schema and no behavioral details, the description leaves the agent uncertain about the exact return payload and edge cases. It is minimally complete but not fully informative.

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?

All four parameters (connectorId, folder, filename, messageId) are fully described in the input schema, providing 100% coverage. The description adds no additional meaning beyond what the schema already specifies, so a baseline score of 3 is appropriate.

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

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

The description explicitly states 'Get detailed information about a specific Arc file', using a clear verb (Get) and resource (detailed information about a specific Arc file). This distinguishes it from sibling tools like get_files_by_connector or get_recent_files that operate on collections.

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, nor any exclusions or preconditions. With many sibling file-related tools, explicit selection criteria would be valuable but are entirely absent.

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 behavioral disclosure. It only states the basic read operation, without mentioning pagination (top), ordering (orderby), return format, error handling, or any side effects. This is minimal for a tool that actually has pagination and sorting parameters.

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 wasted words. Every word contributes to the core purpose, making it exceptionally concise and easy to parse.

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

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

For a tool with no annotations and no output schema, the description is incomplete. It does not explain the return value (what fields are included), the effect of pagination parameters (top, orderby), or error scenarios. Given the presence of these parameters and the many sibling tools, more context is needed 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 coverage is 100% with descriptive text for all three parameters (connectorId, top, orderby). The description adds no additional parameter semantics beyond the schema, but the baseline for fully covered schemas is 3, and the schema itself provides sufficient 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 action ('Get') and resource ('files') with a specific scope ('processed by a specific connector'). This distinguishes it from sibling tools like list_files or get_recent_files, which have broader or different filtering. The phrase 'specific connector' immediately conveys the unique 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?

The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or provide context beyond the connector filter. The use case is only implied by the phrase 'by a specific connector', but there is no guidance on when this is preferable to list_files or get_recent_files.

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. The verb 'Get' implies a read-only operation, which is correct, but the description does not disclose what exactly 'detailed information' includes, potential 404 errors, or any required permissions. It adds minimal behavioral context beyond the obvious read operation.

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 words. It effectively communicates the tool's purpose in a concise manner.

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?

There is no output schema, so the description should ideally clarify what 'detailed information' includes. However, for a simple one-parameter read tool, the description is minimally adequate. It does not specify the return structure or error scenarios, 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 schema already provides a complete description for the single parameter (workspaceId), so schema coverage is 100%. The tool description only reiterates 'by workspace ID', adding no new meaning beyond what the schema states. The baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get'), the resource ('detailed information about a specific Arc flow API'), and the scope ('by workspace ID'). It distinguishes itself from sibling tools like list_flow_apis and delete_flow_api by explicitly targeting a single flow API.

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 context by mentioning 'specific' and 'by workspace ID', contrasting with listing operations, but it does not explicitly mention when to use this tool instead of alternatives like list_flow_apis. No exclusions or prerequisites are stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, what response format to expect, or any error/edge-case behavior. The phrase 'detailed information' is vague and does not disclose what fields or metadata will be returned.

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

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

The description is a single, clear sentence with no filler. It front-loads the action and object, making it efficient and easily parsed.

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, but without an output schema, the description should at least hint at what 'detailed information' includes. It does not. There is no mention of return structure, pagination, or any usage guidance, leaving the agent under-informed about the tool's full behavior.

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 provides 100% coverage for the single parameter logId, including its type and description ('The unique identifier of the log entry'). The description adds no additional semantic context beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and names the resource ('detailed information about a specific log entry'). It clearly distinguishes this from sibling tools like list_logs (which lists logs) and get_error_logs (which fetches error logs).

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. It does not state that a valid logId is required or that this tool should be used when a specific log entry is already known, nor does it mention any exclusions or prerequisites.

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 adds the behavioral detail that it counts all messages in Send folders, implying a read-only aggregation. However, it does not disclose whether permissions are required, the response format, or any edge cases that might affect the count.

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 front-loaded with the core purpose and adds a clarifying clause. Every word contributes to understanding the tool's function, with 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 counter with two optional filters, the description fully conveys the tool's scope and behavior. It does not explain the return format, but given the tool name and the nature of a count operation, the return value is self-evident. The description is complete enough for an agent to select and invoke the tool correctly.

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

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

The input schema has 100% coverage, with both connectorId and workspaceId clearly described. The description adds no parameter-specific semantics, but the schema already provides the necessary meaning, justifying the baseline 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 uses the specific verb 'Get' and clearly identifies the resource as 'unsent messages count for connectors,' further elaborating with 'counts all messages in Send folders.' This distinguishes it from sibling count tools like get_transactions_count and get_requests_count by focusing on the message domain.

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

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

The description implies the tool is for retrieving unsent message counts but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is limited to the tool's direct purpose.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. The verb 'Get' strongly implies a read-only operation with no side effects, but the description does not explicitly state that it does not modify settings or mention any authentication/error behavior. It is minimally adequate but lacks explicit behavioral guarantees.

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 of eight words, front-loaded with the action 'Get'. 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 zero-parameter getter with no output schema, the description adequately explains what is returned (current profile and configuration settings). Given the tool's simplicity and clear sibling context (e.g., update_profile for modifications), no additional detail is necessary.

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 schema is an empty object, so schema coverage is complete. The description's mention of 'profile and configuration settings' provides context for what the tool operates on, but with no parameters to explain, the baseline of 4 is appropriate.

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

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

The description clearly identifies the tool as retrieving the current Arc application profile and configuration settings. The verb 'Get' specifies the action, and the resource is distinct from sibling tools like get_connector or get_file, so there is no ambiguity.

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 purpose implies usage when you need the current profile/configuration, but the description does not explicitly mention when to use this tool versus alternatives like update_profile, nor does it state any exclusions or prerequisites. The usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure, but it only says 'get recently processed files' without mentioning ordering, pagination, or authorization requirements. This minimal disclosure is insufficient for an agent to predict the tool's output behavior.

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 redundant wording, making it easy to parse. It is appropriately concise for a read-only listing tool, though it omits some contextual detail that is penalized elsewhere.

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 core purpose is clear and parameters are fully covered by the schema, but the lack of output schema and sparse description means the agent may not know what fields are returned or how results are sorted. Given the simplicity of the tool, this is a moderate gap.

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

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

Both parameters have schema descriptions with 100% coverage, so the schema already explains 'top' and 'hours'. The description does not add any additional parameter semantics beyond what the schema provides, meeting the baseline.

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

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

The description clearly states the action (get), the resource (recently processed files), and the scope (across all connectors). This distinguishes the tool from related siblings like get_files_by_connector or list_files.

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 list_files or get_file. The description only states the function without exclusions, prerequisites, or recommendations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') and mentions a 'status summary', but does not explain return format, pagination behavior, authorization requirements, or any limitations. This is insufficient for a tool that returns potentially complex request data.

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 wasted words. It front-loads the primary purpose and includes key capabilities ('status summary and filtering') in a compact form, making it easy to parse.

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

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

Despite having a fully self-documenting schema, the tool lacks annotations and an output schema. The description does not explain what the returned data looks like beyond a vague 'status summary', nor does it clarify the meaning of 'recent' (though the hours parameter helps). Given the complexity of HTTP request data and the lack of structured output info, 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?

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds only generic mention of 'filtering', which maps to method and status parameters, but does not enrich parameter semantics beyond what the schema already 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 clearly states the tool retrieves recent HTTP requests, which is specific and distinct from sibling tools like get_recent_files or get_recent_transactions. It also mentions 'status summary and filtering', adding scope and unique functionality, but does not explicitly differentiate from list_requests or get_request.

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 list_requests or get_request. It does not state any exclusions or prerequisites, leaving usage context entirely implicit or absent.

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 for disclosing behavior. It only states the operation and a hint about output, with no mention of side effects, return format, pagination, authentication, or whether this is a safe read-only operation. This is a significant gap for a tool that could be used in various contexts.

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 tool's purpose and a key aspect of the output. This is appropriately concise for a simple retrieval tool.

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 additional description, the tool is under-specified. The meaning of 'status summary', the exact response shape, and the definition of 'recent' (though partially covered by the 'hours' parameter) are unclear. For an agent to use this tool correctly, more context is needed.

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 already describes both parameters ('top' and 'hours') with their defaults and meanings, so schema coverage is 100%. The description adds 'status summary' but does not enhance parameter understanding. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states a specific verb ('get') and resource ('recent transactions'), and adds 'with status summary' to indicate output contents. This distinguishes it from siblings like 'get_transaction' (singular) and 'list_transactions' (likely broader), though it does not explicitly name 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?

The description implies usage: use this to retrieve recent transactions with a status summary. However, it does not explicitly contrast with alternatives or state when not to use it. The presence of sibling tools like 'get_transaction' and 'list_transactions' offers context, but the description itself provides only implicit direction.

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. It implies a read-only operation via 'Get' but does not disclose error behavior, permissions, or what 'detailed information' includes. The read-only nature is clear, but no additional behavioral context is added.

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 sentence that is front-loaded and free of redundancy. It efficiently conveys the tool's purpose without unnecessary detail.

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, but the description does not explain the return format or error conditions. It is adequate for a basic getter but leaves room for improvement.

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 fully describes the only parameter ('name') with 100% coverage, and the description does not add additional meaning beyond the schema. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('detailed information about a specific Arc report'). It distinguishes from list_reports by implying a single report.

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 instead of alternatives like list_reports or other get tools. No conditions, exclusions, or alternative tools 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?

With no annotations, the description carries the full burden, but it only says 'detailed information' without disclosing permissions, side effects, or return format. It's a read operation, but this is not explicitly stated, and there's no mention of error behavior or rate limits.

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?

Single concise sentence, front-loaded with the verb and resource, no unnecessary words. It is appropriately 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 one-parameter read tool, the description is minimally sufficient, but the lack of annotations and output schema means the agent gets no information about expected return values, error conditions, or distinguishing edge cases.

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 covers the sole parameter (requestId) at 100%, so the description doesn't need to add parameter details. The description aligns with the schema, offering no additional meaning but nor requiring compensation.

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') and the target resource ('detailed information about a specific request log'), distinguishing it from list/recent/error request tools. However, it doesn't explicitly mention 'by request ID' in the description, relying on the schema.

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 list_requests or get_recent_requests. The description is purely definitional and gives no indication of prerequisites or alternative 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation but never explicitly states that, nor does it describe the return format (e.g., an integer), whether it counts all matching logs by default, or any potential performance implications. The optional filtering is mentioned, but nothing else about behavior.

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

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

The description is a single, concise sentence that front-loads the main purpose and mentions the optional filter. No wasted wording or unnecessary 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 tool is simple with one parameter, no output schema, and no annotations. The description states the purpose and the optional filter, which is enough for a count operation. However, it does not explicitly confirm what the count represents or what the response looks like, though this is largely inferable from the name and nature of 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 single parameter 'filter' is fully described in the input schema with an OData example, giving 100% schema coverage. The description adds only the phrase 'optional filtering', which adds minimal value beyond what the schema already states. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool gets a total count of request logs, with an optional filter. This distinguishes it from sibling count tools like get_transactions_count and get_message_count by naming the resource (request logs). The verb 'Get' and resource 'request logs' are specific.

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_requests (which lists requests) or other count tools. It does not mention exclusions or context like 'use this when you only need a count, not the list'. This leaves the agent to infer usage from the tool 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?

No annotations are present, so the description must provide transparency. It only says 'Get detailed information' without disclosing the return format, possible errors, authentication requirements, or any side effects. For a read operation this is minimal but still insufficient for full transparency.

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 with no redundant words. It communicates the essential purpose immediately and is appropriately compact for a simple get-by-ID tool.

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 low in complexity (one parameter, no nested objects) and no output schema, so the description needs to explain what 'detailed information' entails. It does not, leaving the return value undefined. This is adequate for a basic lookup but lacks 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?

The schema covers 100% of the single parameter (transactionId) with a clear description. The tool description adds little beyond 'specific,' so baseline 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 a specific verb ('Get') plus a well-defined resource ('detailed information about a specific Arc transaction'), clearly indicating this is a single-transaction lookup. It distinguishes itself from sibling tools like list_transactions (multiple) and get_transaction_property (single property), though 'detailed information' remains 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?

Usage is implied: use this when you have a transactionId and want full transaction details. However, there is no explicit guidance on when to prefer this over get_transaction_property or get_transaction_logs, nor any mention of alternatives.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It implies a read-only retrieval but does not explain what 'details and log files' entails, return format, potential large payloads, or any filtering behavior. This is a significant gap for a tool that could return potentially heavy log content.

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

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

The description is a single, front-loaded sentence with no filler. It effectively communicates the core action and target resource in a concise manner, earning a perfect score for 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?

Given the tool has 7 parameters, no annotations, and no output schema, the description is too sparse. It fails to explain the return structure, how parameters like 'type' or 'includeContent' affect results, and what 'log files' means in this context. The description needs more detail to be 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?

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds no extra parameter semantics, only hinting at the message transaction context. This aligns with the baseline score of 3.

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 tool's purpose: retrieving transaction details and log files for a specific message transaction. It distinguishes the tool from siblings like 'get_transaction' (which likely returns only details) and 'list_logs' or 'get_log' (which may not be message-scoped), though the word 'details' is somewhat vague and could overlap with 'get_transaction'.

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 such as 'get_transaction', 'list_transactions', or 'get_log'. It does not mention exclusions, prerequisites, or scenarios where another tool would be 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only that it 'gets' a property value, without mentioning whether it is read-only, how it behaves for nonexistent properties, or any error handling. This leaves the agent with incomplete information about expected outcomes.

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 or extraneous words. It clearly states the action and the target resource, making it an exemplar of 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?

Given that there is no output schema and no annotations, the description should explain return values and edge cases. It does not specify the shape or type of the returned property value, nor what happens if the property is missing. This is a significant gap for a tool that is otherwise very simple.

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 already provides 100% coverage for both parameters, including examples for 'propertyName'. The tool description adds no additional semantic value beyond the schema—it merely echoes the resource being accessed. According to the baseline, a score of 3 is appropriate when schema describes parameters fully.

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 identifies the resource 'transaction property', clearly distinguishing this from sibling tools like 'get_transaction' (which retrieves the whole transaction) and 'list_transactions'. It precisely indicates the tool's scope: retrieving one property value from a transaction.

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 when to use the tool—when you need a specific property from a transaction—but does not explicitly state when NOT to use it or mention alternatives like 'get_transaction'. There is no clear exclusion or guidance, so the usage context is merely implied rather than articulated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly implies a read-only count operation, but it does not mention the return format (e.g., a plain integer or an object with a count field), any limitations on counting, or potential error conditions. The description adds little beyond the tool name 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 sentence of eight words, front-loaded, with no redundant or filler content. It efficiently communicates the core function.

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 (one optional parameter, no output schema), and the description adequately states the purpose. However, it lacks guidance on choosing this tool over similar ones and does not clarify the response shape, which would help the agent use the tool more confidently. Given the low complexity, the description is workable 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?

Schema description coverage is 100%, and the 'filter' parameter is well-documented with an OData filter expression example. The tool description merely says 'optional filtering' without adding new information, so the schema already does the heavy lifting, warranting the baseline score of 3.

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 'Get the total count of transactions with optional filtering' clearly states the verb (Get) and resource (transactions count), distinguishing it from sibling tools like list_transactions (which lists transactions) and get_transaction (singular). It also signals the optional filtering capability.

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 for counting transactions rather than listing them, but it provides no explicit guidance on when to use this tool versus alternatives such as list_transactions or get_message_count. There are no clear exclusions or specific scenarios 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?

With no annotations, the description carries the transparency burden. It implies a safe read operation ('Get') and notes optional filtering, but doesn't disclose return format, error handling, or behavior with invalid filters. For a simple count tool, this is adequate 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 a single concise sentence that communicates the core function and optional filtering without any fluff 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?

For a simple tool with one optional parameter and no output schema, the description is sufficient: it states the purpose and the filtering capability. It doesn't explain the return value, but 'count' inherently implies a numeric result, so no further details are necessary.

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

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

The schema covers the filter parameter with a clear OData expression description and example. The description adds no additional parameter semantics beyond the schema, so baseline 3 applies.

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

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

The description clearly states the tool returns the total count of vault entries, with optional filtering. This distinguishes it from sibling tools like list_vault_entries (which returns entries) and get_vault_entry (which returns a specific entry), making 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 description gives clear context: use this when you need a count rather than the entries themselves, and optionally filter the count. It doesn't explicitly mention alternatives, but the 'count' phrasing implies a different use case from listing or searching.

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 behavioral traits. While it indicates a read operation, it does not specify what 'detailed information' includes, whether the entry must exist, or what response format to expect. This is a minimal description that does not add sufficient context beyond the tool's name.

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 redundant words. It efficiently communicates the tool's purpose without unnecessary elaboration, making it easy for an agent to quickly parse.

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

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

The tool is relatively simple with one well-documented parameter and no output schema. However, the description omits any information about the return value or what 'detailed information' entails, and it does not reference sibling tools. This is sufficient for a basic getter but leaves gaps in fully understanding the tool's behavior.

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 provides 100% coverage for the sole parameter 'vaultId' with a clear description ('The unique identifier of the vault entry'). The tool description adds no extra parameter semantics, but since the schema already documents the parameter adequately, a baseline score of 3 is appropriate.

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

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

The description 'Get detailed information about a specific vault entry' uses a specific verb and resource, clearly indicating a read operation for a single entry. It is concise and understandable, though it does not explicitly distinguish itself from sibling tools like get_vault_property or search_vault_by_type, which could also return entry-related information.

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. Sibling tools such as list_vault_entries, get_vault_property, and search_vault_by_type exist, but the description does not mention any of them or provide context for choosing this tool. This leaves the agent without explicit usage direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('get') without mentioning return format, error behavior, or side effects. For instance, it does not clarify what happens if the property is missing or whether the operation is read-only (though 'get' implies it). This leaves significant behavioral ambiguity.

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

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

The description is a single, clear sentence with no redundant information. It is front-loaded and concise, effectively communicating the tool's purpose in minimal 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?

The tool is simple with two well-described parameters, but the lack of an output schema and annotations means the description should provide some context about return values or error cases. It does not, leaving the agent to guess expected output. It is minimally adequate but with 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 input schema covers both parameters (vaultId, propertyName) with descriptions, achieving 100% coverage. The description adds no extra parameter semantics beyond what the schema already provides. Since schema does the heavy lifting, the baseline of 3 is appropriate.

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

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

The description clearly states the action (get) and resource (a specific property value from a vault entry), distinguishing it from related tools like 'get_vault_entry' by emphasizing 'specific property value'. However, it does not explicitly mention alternatives or contrast with siblings, so it misses the highest clarity mark.

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. It does not mention conditions, prerequisites, or exclusions. The user must infer that this tool is for retrieving a single property rather than a full entry, but no explicit usage context is given.

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 implies a read-only operation via 'Get', but it does not disclose response format, error behavior for invalid IDs, or any additional behavioral details. This is sufficient for a simple getter but not richly informative.

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 resource. Every word earns its place, with no wasted or redundant text.

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, but there is no output schema, and the term 'details' is vague. While the schema covers parameters, the description does not clarify what properties will be returned or any edge-case behavior, making it minimally complete for a basic retrieval.

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

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

Schema description coverage is 100%, so the schema already explains both parameters. The description adds no new meaning about 'select' or 'workspaceId' beyond what the schema provides, falling at the baseline for full 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 a specific verb ('Get') and resource ('details for a specific workspace'), and clearly identifies the key parameter (by ID). It distinguishes itself from sibling tools like list_workspaces and search_workspaces, which are for listing or searching rather than retrieving a single entity.

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

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

The description implies the tool should be used when you have a specific workspace ID, but it does not explicitly mention when to avoid it or mention alternatives. There is no exclusion or alternative guidance, making it adequate but not strong.

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 responsibility for behavioral disclosure. It only says 'get a specific property value' but does not mention what happens if the property is missing, whether the operation is read-only (implied but not explicit), expected return types, or error conditions.

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 clearly states the core action. It is appropriately sized for a simple getter, though it could have comfortably included additional context 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?

The tool is simple, but the absence of an output schema and annotations means the description should explain what the return value looks like and any edge-case behavior. The one-line description is insufficient for an agent to confidently predict the tool's output or failure modes.

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 fully documents both parameters with descriptions (workspaceId and propertyName), giving 100% coverage. The description adds no extra semantic value beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb 'Get' and a clear resource 'property value from a workspace', making the tool's function evident. It is distinct from sibling tools like get_workspace, which likely return the full workspace object, but does not explicitly call out 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?

No guidance is provided on when to use this tool versus alternatives such as get_workspace or get_vault_property. There are no use cases, exclusions, or alternative recommendations, leaving the agent without context for 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?

No annotations are provided, so the description carries the full burden. It only adds 'with optional filtering,' but does not disclose the return format (e.g., bare integer vs object), authentication needs, rate limits, or any side effects. This is minimal for read-only 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, front-loaded sentence with no wasted words. It clearly states the operation and a single qualifier.

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 count tool, the description is adequate but has gaps: there is no output schema, so the return value type/format is not explicitly stated. It also omits any caveats about workspace visibility or filtering behavior beyond what the schema already covers.

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 fully describes the 'filter' parameter with example syntax (100% coverage). The description redundantly says 'optional filtering,' adding no new meaning beyond the schema's required-field list (zero required params). Baseline 3 applies.

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

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

The description clearly states the tool returns a count of workspaces, with optional filtering. This distinguishes it from sibling tools like list_workspaces (which lists details) and get_workspace (singular fetch).

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

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

The description implies usage (use when you need a total count) but does not explicitly mention when-not-to-use or alternatives. There is no guidance about choosing this over list_workspaces or search_workspaces.

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 burden for behavioral disclosure. It notes the operation is an import (mutation) and requires existing base64 data, but does not disclose whether it overwrites certificates, what permissions are needed, or what the response looks like. Minimal beyond usage 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?

Three sentences, all carrying distinct value: purpose, usage condition, and alternative. Front-loaded and free of fluff.

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

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

For an import tool with 15 parameters and no output schema, the description covers the core decision (existing vs. new certificate) and the base64 requirement. It does not mention return values or side effects, but the schema handles parameter details. Slightly above baseline due to the clear alternative guidance.

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 baseline is 3. The description mentions the base64-encoded data requirement, which aligns with the 'data' parameter, but adds no additional meaning beyond what the schema already 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?

Description clearly states 'Import an existing certificate into Arc' with a specific verb and resource. It distinguishes from sibling create_cert by explicitly noting the difference between importing an existing certificate and generating a new one.

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

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

Provides explicit when-to-use: 'Use this ONLY when you already have a certificate file and need to upload it.' Also names the alternative for new certificates: 'To generate a NEW certificate from scratch, use create_cert instead.' This is clear guidance.

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

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

No annotations are provided, so the description bears the full burden. It does not disclose any side effects (e.g., whether the existing key is overwritten, required permissions, or impact on data encryption). It only states the inputs, leaving behavioral traits opaque.

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, clear sentence with no redundancy. It is front-loaded and concise, stating the action, the resource, and the required inputs efficiently.

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 2-parameter import tool, the description covers the essential purpose and inputs. However, due to the lack of annotations and absence of side-effect disclosure, it is not fully complete in a security-sensitive context.

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

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

Schema coverage is 100% and both parameters have descriptions in the schema. The tool description merely restates 'key package' and 'passphrase' without adding any new meaning or format details beyond what the schema already 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 clearly states the verb (Import), the resource (Arc data encryption key), and the context ('previously exported'). It distinguishes the tool from siblings by referencing the export process and the key package/passphrase.

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 implies the appropriate use case (importing a key that was previously exported) by mentioning 'previously exported,' but it does not explicitly state when not to use it or mention alternatives like import_certificate. Still, the context is clear.

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 fails to disclose side effects, whether overwriting occurs, if decryption is required, or what the return value is. The only behavioral hint is 'base64 encoded', which is limited.

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 wasted words. It efficiently states the core purpose without excessive detail.

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 (9 parameters, no annotations, no output schema), the description is insufficient. It lacks information on return values, error handling, or operational context, relying entirely on the schema for parameter details.

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 provides detailed descriptions for all 9 parameters (100% coverage), so the baseline is 3. The main description adds no parameter-specific meaning beyond what the schema already documents.

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 imports partner/connector profiles from arcflow data (base64 encoded), which is a specific verb and resource. It distinguishes from sibling tools by mentioning the source (arcflow data), but does not explicitly reference alternatives like export_settings.

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. The description simply states the action without providing context or exclusions, leaving the agent without direction 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?

No annotations are provided, so the description carries the full burden. It states that the operation lists certificates and supports filtering/pagination, which implies a read-only action. However, it does not disclose return format, authentication requirements, rate limits, or any side effects. It adds some context but is not rich in behavioral detail.

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

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

The description is a single, well-structured sentence that front-loads the verb and resource. Every word contributes meaning, 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?

Despite having 5 optional parameters and no output schema, the description is adequate for a simple list operation. The schema provides rich parameter documentation, and the description covers the high-level purpose. It could mention return format or default pagination behavior, but these are not critical for the agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description's mention of 'filtering and pagination' summarizes the top/skip/filter parameters but adds no additional semantics beyond the schema, which already provides detailed descriptions and examples for each parameter.

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 with a specific verb ('List'), resource ('Arc certificates'), and qualifiers ('with optional filtering and pagination'). It distinguishes from siblings like get_certificate (single certificate) and import_certificate (import operation).

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

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

The description implies usage: use this tool to list certificates with optional filtering/pagination. It provides clear context for when to use it, though it does not explicitly mention alternatives or when not to use it. Sibling tools like get_certificate are not referenced, but the purpose is self-explanatory.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral aspects of filtering and pagination, but does not explicitly state that listing is read-only or describe default behavior (e.g., returns all connectors if no filter). The word 'List' implies non-mutating, but the description leaves some behavioral context unstated.

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 filler. It front-loads the primary purpose ('List Arc connectors') and efficiently adds the key optional capabilities. Every word earns its place.

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

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

For a simple list tool with 5 optional parameters and no output schema, the description covers the essential usage (filtering and pagination). It could be more complete by noting that omitting filters returns all connectors, but overall it provides sufficient context for a straightforward list operation.

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%, with each parameter (top, skip, filter, select, orderby) having a detailed description. The tool description adds only a general mention of 'filtering and pagination', which does not exceed what the schema already conveys. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description 'List Arc connectors with optional filtering and pagination' uses a specific verb (List) and resource (Arc connectors), clearly distinguishing it from sibling tools like get_connector (single item) and create/update/delete_connector (mutations). The scope of listing with optional filters and pagination is clearly stated.

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 this tool is for listing multiple connectors, as opposed to get_connector for a single connector. However, it does not explicitly exclude any alternatives or state when not to use this tool. It provides clear context but lacks explicit 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 provided, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation but does not disclose return format, default limits, or side effects. The mention of filtering and pagination is generic and adds little beyond the 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?

The description is a single, focused sentence with no redundant words. It communicates the tool's purpose and key capabilities in a compact form.

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

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

Given no output schema and no annotations, the description should explain what the return value looks like and any default behavior. It does not mention that the result is a list of file objects, what the default page size is, or how this differs from other list tools. The description is too minimal for a tool with 5 optional parameters.

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 description's 'optional filtering and pagination' loosely maps to the filter and top/skip parameters but adds no details about syntax or semantics beyond what the schema already documents.

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 specifies the verb 'List' and resource 'Arc files', clearly indicating the tool's function. However, it does not explicitly distinguish this from sibling tools like get_files_by_connector or get_recent_files, which also list files but with different scopes.

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 context on when to use this tool versus alternatives such as get_files_by_connector or get_recent_files. It merely states the capability without exclusions or prerequisites.

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 mentions filtering and pagination, but does not describe default pagination behavior, result limits, response format, or any side effects. This is minimal for a list tool with options.

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