Hudu MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation3/5
Many tools follow clear entity-action patterns, but there are overlapping tools like 'list_assets' vs 'list_company_assets' and 'delete_magic_dash' vs 'delete_magic_dash_by_id'. Some names like 'lookup_cards' and 'jump_to_card' serve similar purposes, causing potential confusion.
Naming Consistency4/5
Most tools use a consistent verb_noun pattern (list_, get_, create_, update_, delete_). However, there are deviations like 'kickoff_procedure', 'upsert_magic_dash', and 'delete_magic_dash_by_id' that break the pattern, preventing a perfect score.
Tool Count1/5
With 147 tools, this server is vastly over-scoped. The sheer number overwhelms any agent and far exceeds the typical 3-15 tool range for a cohesive server. This creates unnecessary complexity and slows tool selection.
Completeness4/5
The tool surface covers a wide range of Hudu entities with comprehensive CRUD operations, including assets, articles, companies, procedures, and networks. Minor gaps exist, such as no create_expiration or delete_user, but overall the coverage is extensive and most workflows can be completed.
Average 2.9/5 across 124 of 147 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. It does not state whether the update is a partial or full replacement, whether it requires an existing record, what happens to unspecified fields, or any side effects. With no annotations provided, the description entirely fails to convey what the tool actually does beyond the generic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It wastes the opportunity to provide useful structure or context, and the single sentence adds no information beyond what the tool name already conveys. While there is no redundancy, the brevity is not a virtue here as it amounts to empty specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 8 parameters, no annotations, no output schema, and no description details. The description is woefully incomplete—it fails to explain the operation's behavior, parameter roles, expected outcomes, or any constraints, making it nearly unusable for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage, and the description does not mention any of them or their meanings. It provides no insight into what fields like 'width', 'height', or 'max_wattage' represent or how they are used in the update, leaving the agent to guess from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a Rack Storage.' is a direct restatement of the tool name, providing no additional context about what the update entails or which aspects of the resource are modified. It is essentially a tautology, offering no value beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, such as create_rack_storage, delete_rack_storage, or get_rack_storage. There is no mention of prerequisites, typical use cases, or situations 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.
Behavior1/5
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 'Update' without explaining whether it performs a partial update, what happens to omitted fields, required permissions, idempotency, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too sparse to be considered good conciseness. While it is short, the single sentence adds no value beyond the tool name and fails to earn its place, resulting in under-specification rather than appropriate brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters), lack of annotations, and no output schema, the description is severely incomplete. It provides no context about required fields, update behavior, or how this tool fits into the broader VLAN management workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters or fields. The schema lists 10 parameters, but the description adds no meaning beyond the raw property names, making it impossible for an agent to understand parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VLAN' simply restates the tool name 'update_vlan' with no added detail. It is a tautology that does not specify what aspects of a VLAN can be updated or how it differs from related tools like create_vlan or delete_vlan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. There is no mention of prerequisites, exclusions, or scenarios where update_vlan is preferred over create_vlan or delete_vlan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Get a list', which implies a read operation but does not explicitly state read-only behavior, parameter requirements, or any side effects. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is extremely concise but under-specifies the tool. It is not appropriately sized given the tool's complexity and lack of structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a minimal description. The agent lacks critical information about parameter usage, response format, and behavior. The description is not complete enough for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters with zero description coverage. The tool description does not mention any of the parameters (name, company_id, procedure_id) or explain how they affect the listing. The agent has no way to know whether these are filters, required fields, or what values they accept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of Procedure Tasks' simply restates the tool name without adding any additional scope or context. It is essentially a tautology, providing no new information about the resource or its specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus other listing tools (e.g., list_procedures or get_procedure_task). The description lacks any context about filtering, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to fill the gap, and the description does not disclose any behavioral traits such as whether partial updates are supported, whether permissions are required, or what the return value is. This leaves the agent completely in the dark about the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness; it adds no information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no annotations, no output schema, and no behavioral details, the description is wholly inadequate for an agent to safely invoke this mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions, and the description does not explain any of the five parameters (id, description, flagable_id, flag_type_id, flagable_type). With 0% schema coverage, the description provides zero semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a Flag.' restates the tool name 'update_flag' in sentence form, providing no additional detail about what a Flag is or what updating entails. It does not differentiate from sibling tools like update_flag_type or update_asset, though the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided; there is no mention of when to use this tool versus alternatives, nor any prerequisites or side effects. The description gives no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It merely states the action without any details about side effects, required inputs, permissions, or return behavior. This is a significant transparency gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence that is not verbose, but it is under-specified to the point of uselessness. It lacks any structural elements like parameter highlights or behavioral notes, making it minimalist without being helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no annotations, no output schema), the description is grossly incomplete. It fails to explain the creation behavior, field meanings, constraints, or what the agent should expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 15 parameters with 0% schema description coverage, yet the description adds no semantic meaning to any parameter. Even the required 'name' field is not explained, leaving the agent with no understanding of what each field represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new company' directly restates the tool name 'create_company' without adding any scope, context, or distinction from sibling tools. It is a tautology that offers no added clarity beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 update_company or archive_company. It does not mention prerequisites, typical use cases, or conditions that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Create a new Procedure Task.' It does not mention any requirements, side effects, permissions, or the need for an existing procedure. For a mutation operation with 8 parameters, this lack of context is a serious gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is undeniably concise and front-loaded. However, it is under-specified for an 8-parameter tool, and the sentence merely restates the tool name without adding substantive content. It is not verbose, but it fails to provide necessary structure or explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is far too brief for a tool with 8 parameters, no output schema, and no annotations. It provides no context about what a Procedure Task is, how it relates to procedures, what fields are required, or how to handle the parameters. The statement may help with tool selection but is inadequate for ensuring correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 13% (just the due_date field has a description), yet the tool description adds absolutely no parameter information. It does not define name, procedure_id, assigned_users, priority, or any other parameter, so the agent receives zero value beyond the raw schema names, making correct invocation very difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Procedure Task.' is essentially a direct restatement of the tool name 'create_procedure_task' with almost no added information. It states the action and resource but does not add any distinguishing detail or nuance beyond the name itself, making it a tautology rather than a truly clarifying description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool vs. alternatives such as update_procedure_task or create_procedure. No prerequisites, exclusions, or contextual hints are provided, leaving the agent without any help in deciding if this is the correct tool for the scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It only states a creation action with no mention of side effects, required permissions, or conditional behavior based on the 'security' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified for a tool with five parameters. It sacrifices necessary detail for brevity, so it does not earn credit for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the security enum and conditional allowed_groups, plus no output schema, the description fails to explain behavior, return values, or use cases. It is minimally viable at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with only 'allowed_groups' having a description. The tool description does not explain any of the parameters (name, security, company_id, description) or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'password folder', making the purpose unambiguous. However, it does not distinguish itself from similar creation tools like 'create_folder' beyond the entity name, and it adds no extra scope or constraints, 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.
Usage Guidelines2/5
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 vs alternatives such as 'create_folder' or 'update_password_folder'. It doesn't mention prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It merely says 'retrieve a list' and gives no details about pagination, result structure, side effects, or potential limitations. This is a significant gap, so 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is not verbose, but it is under-specified to the point of providing no actionable information. The brevity is not an asset when it omits essential usage details, so 2.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no annotations, and no output schema, the description is far from complete. It doesn't explain return data, pagination, or parameter purposes, leaving the agent unable to call the tool correctly. This is a 1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 12 parameters with zero description coverage. The description does not mention any parameters or clarify ambiguous names like 'slug', 'id_in_integration', or 'updated_at'. Since schema_coverage is 0%, the description must compensate but does not, so 1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves companies ('Retrieve a list of companies'). It uses a specific verb and resource, but does not add scope or filtering details that would distinguish it from other list_* tools. This is a clear but undifferentiated description, so 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 filtering capabilities, pagination, or relationships to other tools like get_company or list_company_assets. With no context for selection, this scores 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only states 'Update a Rack Storage Item' without mentioning permissions, side effects, error behavior, reversal, or return value. This is insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified for a tool with 10 parameters and no additional context. It provides no more information than the tool name itself, making it insufficient rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the one-sentence description is completely inadequate. It does not explain the resource, parameter semantics, return values, or usage context. The agent would have no way to correctly invoke this tool beyond guessing from parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information. The schema has 10 parameters with 0% description coverage, so the description must compensate but does not mention any of the fields (e.g., side, status, power_draw) or their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'update' and names the resource 'Rack Storage Item', distinguishing it from sibling tools like update_rack_storage and delete_rack_storage_item. However, it does not provide any context about what a rack storage item is or what updating entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites, excluded scenarios, or related tools such as create_rack_storage_item or get_rack_storage_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the only source of behavioral info, but it merely repeats the action 'create' without disclosing side effects, required permissions, error conditions, idempotency, or any impact on related data. This is a serious gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no wasted words, making it concise. However, it is under-specified for a tool with nine parameters and no additional annotations; brevity is achieved by omitting necessary content rather than by efficiently conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (9 parameters, no schema coverage, no annotations, no output schema), the description is completely inadequate. It does not explain return values, constraints, relationships to other entities, or any operational context, leaving the agent without enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with 0% description coverage, and the description adds no meaning to any of them. Terms like 'rack_storage_role_id', 'side', 'status', or 'power_draw' remain unexplained, so the agent must guess their purpose and allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new Rack Storage Item' with a specific verb ('Create') and resource ('Rack Storage Item'), clearly distinguishing it from sibling operations like list/get/update/delete. However, it lacks additional context about what a Rack Storage Item is or how it differs from the related 'create_rack_storage' tool, so it is not fully helpful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what prerequisites exist, or which alternatives to prefer. It only provides the bare action statement, leaving the agent to infer usage from the tool name and sibling context. No exclusions or comparisons are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only implies a read-only operation. It does not mention pagination, filtering, or whether archived items are included, leaving significant ambiguity for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which earns it a high score on efficiency. However, it is under-specified given the complexity of the tool, so it is not fully appropriate in size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description is severely lacking. It provides no context about the list's scope, filtering options, pagination, or return format, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains 8 parameters with zero description coverage, and the tool description offers no explanation of what each parameter does. The phrase 'Get a list of Passwords' adds no meaning to the schema fields, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that it retrieves a list of Passwords, which gives a clear verb and resource, but it lacks the specificity of 'asset passwords' and does not distinguish itself from sibling list tools. It is not a pure tautology but is very close to restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_password_folders or get_asset_password. There are no use-case descriptions, prerequisites, or exclusions, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get a list of IP addresses,' which simply restates the tool's name and gives no information about side effects, return format, pagination, or required permissions. This is essentially a tautology with no added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no irrelevant information. However, given the tool's complexity (8 optional parameters), the description is too sparse and lacks structure to guide the agent. It is not appropriately sized for the tool's richness, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema, so the description alone must provide a complete picture. It only states what the tool does, omitting any detail about parameter semantics, filtering, or return values. This is inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 8 parameters with 0% description coverage, and the description provides no information about what any of these parameters (e.g., fqdn, status, address) do or how they affect the list results. Since the description must compensate for the schema gaps, it completely fails to do so, leaving the agent without any understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves IP addresses with a specific verb ('Get a list') and resource ('IP addresses'). It distinguishes itself from sibling tools like get_ip_address, which retrieves a single address, and create_ip_address, which creates a new one. However, it does not mention that the list can be filtered by the provided parameters, which could add additional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to use this tool versus alternatives, such as get_ip_address for a single address or create_ip_address for creating one. There is no mention of filtering capabilities or prerequisites, leaving the agent without guidance on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely restates the operation name without explaining filtering behavior, pagination, sorting, or what is returned. This is a significant gap for a tool with eight parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. While it is not verbose, the extreme brevity borders on vague, making it less effective than a more balanced description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's complexity (8 parameters, no output schema), the description is grossly incomplete. It omits what Rack Storage Items are, how the parameters filter results, and what the response contains. It is too sparse to guide correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has eight parameters with zero descriptions and no enums. The description does not clarify any parameter semantics, such as how 'side', 'status', or 'start_unit' affect the query. The tool description offers no compensation for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (get a list) and the resource (Rack Storage Items), distinguishing it from sibling tools like list_rack_storages. However, it lacks detail on what Rack Storage Items are, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_rack_storage_item or list_rack_storages. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral disclosure, but it only says 'Update an integration matcher.' It fails to explain whether the update is partial or full, if it returns the updated object, or what happens in error cases, leaving the agent blind to side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words, so it is concise. However, it is too sparse to be considered well-structured; it lacks detail or a logical breakdown that would help an agent understand the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, no output schema, and a one-line description. It does not explain what an integration matcher is, how updates behave, what each parameter does, or what the return value looks like, making the description grossly inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists 5 parameters (id, sync_id, company_id, identifier, potential_company_id) but the description gives zero context about them. With 0% schema description coverage, the agent has no way to infer the meaning or required format of these fields, making the tool nearly unusable without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update) and the target (integration matcher), which is distinct from sibling tools like delete_matcher and list_matchers. However, it is terse and does not mention what specific fields or behaviors are involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no context such as whether the matcher must exist first. It simply states the action without any practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, and the description does not disclose any behavioral traits such as permissions required, idempotency, duplicate handling, or side effects on related resources. For a mutating tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, which is concise but under-specified. It lacks any structural elements like examples, parameter highlights, or warnings, making it insufficient for a tool with 8 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter creation tool with no output schema, no annotations, and only 13% schema coverage, the description is wholly inadequate. It does not explain required fields, relationships, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, and the input schema has only 13% coverage (only 'address' has a description). With 8 parameters and no elaboration, the description fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new network' uses a specific verb (create) and resource (network), clearly distinguishing it from sibling tools like update_network, delete_network, and list_networks. It is unambiguous about the primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no context for how creation relates to updating or deleting networks. It simply states the action without caveats or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states 'Create a new Rack Storage' without describing side effects, whether the operation is idempotent, permissions required, or any relationship to company_id/location_id. This is a significant gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, but it essentially restates the tool name and adds no informative value. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no output schema, this creation tool needs substantial context about return values and side effects. The description provides none, making it completely inadequate for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 8 parameters with 0% description coverage, and the description makes no mention of any parameter names, types, or required fields. It does not clarify the meaning of fields like company_id, starting_unit, or max_wattage, leaving the agent to guess from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'Rack Storage', distinguishing it from sibling tools like create_rack_storage_item. However, it is extremely minimal and does not define what a Rack Storage is, though the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_rack_storage or create_rack_storage_item. It does not mention any prerequisites, required context, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only implies a write operation via 'create' but discloses no side effects, permissions, idempotency, or behavior when relation already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundant words. However, its brevity borders on under-specification given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 4 required, no output schema, and no annotations, this one-sentence description is vastly insufficient. It omits return values, error cases, and the meaning of key parameters like is_inverse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any parameter semantics. The phrase 'between two entities' hints at fromable/toable but fails to clarify is_inverse or description parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('relation'), and clarifies scope ('between two entities'), distinguishing it from sibling tools like list_relations and delete_relation. However, it lacks detail on the nature of the relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, prerequisites, or alternatives. It does not reference list_relations or delete_relation, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'get a list' which is inherently read-only but provides no information about pagination, sorting, filtering parameters, or what fields are returned. It does not reveal any side effects or caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is very concise, but it essentially restates the tool name. It conveys no additional information beyond the resource being listed, and it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, this description is severely inadequate. It leaves all behavioral aspects—filtering, pagination, default page size, response format—to the imagination. The description does not meet the burden for a non-trivial list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, meaning 8 of 9 parameters are undocumented. The description adds nothing about the parameters—it doesn't explain what 'name', 'slug', 'search', etc. do. The only documented parameter (updated_at) has a schema description, but the description doesn't even acknowledge the parameters. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: fetching a list of Knowledge Base Articles. It uses a specific verb ('get') and resource, and is distinct from sibling tools like get_article (single article). However, it lacks any detail about the scope or filtering behavior, so it's clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as get_article. It does not mention any prerequisites, pagination, or whether it supports filtering. The description implies a simple list operation but gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without detailing filtering behavior, pagination, archive inclusion, permissions, or return format. This is a minimal description that does not meaningfully exceed what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than appropriately concise. It does not earn its place by adding useful information beyond the tool name. For a tool with 7 optional parameters, this level of brevity is not appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain how to filter results, whether archived VLANs are included, or what the response structure is. This is inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the 7 parameters. The schema also lacks parameter descriptions, so there is no added meaning. The description fails to compensate for the low coverage, leaving the parameters entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of VLANs' clearly states the verb (get/list) and resource (VLANs), and the plural form distinguishes it from singular get_vlan. However, it does not explicitly differentiate from other list tools or mention the scope of the listing, so it's clear but not maximally distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools like get_vlan exist for single retrieval, and other list tools may share patterns, but the description lacks any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 'Update an existing Password entry,' which offers no information about side effects, permissions, reversibility, or whether it performs a partial or full update. This is significantly under-specified 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It is appropriately short and front-loaded, stating the core action immediately. While it lacks detail, this dimension rewards conciseness, and the sentence is efficient for what it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema, no annotations, zero schema descriptions), this one-sentence description is grossly inadequate. It does not explain the update behavior, the meaning of the parameters, or the expected result. The tool cannot be reliably used based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 13 parameters with zero description coverage in the schema, and the description provides no additional meaning for any parameter. It does not mention which fields are updatable, that only id is required, or any constraints (e.g., password format, folder association). The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing Password entry'), which is specific enough to distinguish it from general asset update tools. However, it does not go beyond the name to add scope or additional differentiation from sibling tools like update_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, typical use cases, or situations where another tool might be more appropriate. The description is purely declarative with no contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It does not disclose whether the update is partial or full, whether id is required, what happens if the network does not exist, or any side effects. It adds almost no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. It is a single sentence that barely goes beyond the tool name, offering no useful structure or detail for a tool with 9 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, mutation, no annotations, no output schema), this description is severely incomplete. It fails to cover field meanings, update behavior, return values, or when to use the tool, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not interpret any of the 9 parameters. An agent cannot infer the meaning of fields like network_type, vlan_id, or company_id from the schema or description, so parameter semantics are completely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Update an existing network.' This distinguishes it from create/delete/get operations on the same resource. However, it lacks detail on what specific aspects of the network can be updated, so it does not fully differentiate from other update_* tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_network or delete_network, nor any prerequisites or conditions. The one-sentence description provides no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 merely says 'update' without explaining side effects, partial update behavior, required permissions, or what happens to existing settings. This provides no insight 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, extremely concise with no fluff. It front-loads the core action and resource. However, its brevity borders on under-specification, but for conciseness alone it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is far too minimal. It fails to cover return values, validation rules, side effects, or any operational context, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not mention id, name, security, company_id, description, or allowed_groups at all. The agent gets no information about what each field means or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a password folder, using a specific verb and resource. It distinguishes itself from siblings like create_password_folder and delete_password_folder, though it doesn't list the specific fields that can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_folder or create_password_folder. It gives no context about prerequisites or scenarios, so the agent gets no usage direction beyond the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'Archive' without explaining side effects, reversibility, permissions, or what happens to the asset. This is a significant transparency gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) with no wasted words, but it is under-specified. It lacks essential information about the operation, making it inappropriately minimal rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sparse description, no annotations, and no output schema, the tool is not contextually complete. It does not explain what archiving does, how it differs from deletion, or what the expected outcome is, leaving the agent without sufficient information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters. The param names 'id' and 'company_id' are self-explanatory from the schema, but the description adds no additional meaning or context, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive an Asset' clearly states the action (archive) and the resource (asset), distinguishing it from sibling tools like delete_asset and unarchive_asset. However, it lacks any additional detail about what archiving entails, so it's clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of scenarios where archiving is preferred over deleting, or how it relates to unarchive_asset. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 says 'Create a new Asset Layout' without mentioning side effects, permissions, reversibility, or any other behavioral traits. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb, and easy to parse. However, it is under-specified and adds little value beyond the tool name, so it is not effectively earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no annotations, and no output schema, a one-sentence description is completely inadequate. It does not explain required fields, parameter meanings, or return values, leaving the agent without crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters at all. With schema description coverage at only 40%, most parameters (like include_comments, include_passwords, password_types) remain undocumented, and the description does nothing to compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Asset Layout' clearly states the action (create) and the resource (Asset Layout), distinguishing it from sibling tools like get, update, and delete asset layout. It is specific and unambiguous, even if minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. The usage is implied only by the verb 'create,' but the description itself doesn't articulate any context or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states 'Create a new Password entry' without mentioning side effects, permissions, required fields, return values, or any operational constraints. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is under-specified for a tool with 12 parameters, lacking the structural detail that would make it useful beyond a basic statement of intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema), the description is far from complete. It does not address return values, required field relationships, or any behavioral context, leaving significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with 0% description coverage, and the tool description adds no parameter-level meaning. It does not explain fields like password_type, passwordable_id, or in_portal, forcing the agent to rely solely on unhelpful parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('Password entry'), which aligns with the tool name 'create_asset_password'. It distinguishes from sibling create tools by focusing specifically on password entries, though it could be more specific about 'asset password' rather than the generic 'Password entry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 update_asset_password or delete_asset_password. The description lacks any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 uses the verb 'initiate' which suggests a side-effect (creating an export) but does not explain whether the operation is asynchronous, what it returns, or any side effects beyond creating a record. Permissions and rate limits are also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads the key action and resource, which is efficient. However, it is terse to the point of under-specification for a tool with 10 parameters, and the sentence could easily have been expanded with useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no output schema, and no annotations, so the description must be comprehensive but is not. It fails to explain what the tool returns (e.g., an export ID), how to track the export, or the meaning of the many include flags for archived items. This is inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 10 parameters, including required ones like 'include_passwords' and 'include_websites'. The only parameter hinted at is 'format' via the mention of 'PDF or CSV', but that information is already present in the schema enum. The description adds no meaningful parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Initiate'), the resource ('export'), and the scope ('of a company'), and specifies the two output formats ('PDF or CSV'). It distinguishes from the sibling 'create_s3_export' by mentioning the formats, though it does not explicitly contrast with that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'create_s3_export' or 'get_export'. There is no mention of prerequisites, context, or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 operation, with no mention of side effects, permissions, parent-folder requirements, or return behavior. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is easy to parse. However, it is under-specified rather than effectively concise; it omits critical information such as required parameters and usage context, making it borderline minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the one-line description is inadequate. It does not mention important hierarchical aspects like parent_folder_id or any other fields, leaving the agent without enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% coverage, and the description adds nothing about any parameter. It does not clarify the meaning or required format of parameters like 'name', 'company_id', or 'parent_folder_id'. The description completely fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create') and resource ('KB article folder'), which distinguishes it from sibling tools like create_password_folder. However, it lacks any additional scope or contextual detail, so it is not as informative as a fully specified purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It only implies through the phrase 'KB article folder' that this is for article folders, but it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of disclosure. It only states the creation action without mentioning return values, side effects, permissions, or behavior around optional parameters like company_id. Minimal behavioral information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at a single sentence, which is structurally clean. However, it is under-specified for a 4-parameter create tool; the brevity omits essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimal description, the tool definition is highly incomplete. It does not explain what a Procedure is, the meaning of most parameters, or what to expect after creation, making it inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only company_id has a description). The tool description adds no parameter meaning whatsoever, leaving the other parameters (name, description, company_template) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('Procedure'), also clarifying the synonym 'Process'. It does not differentiate from sibling tools like create_procedure_from_template or duplicate_procedure, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_procedure_from_template or duplicate_procedure. There is no mention of prerequisites or context for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It merely states 'Create a new VLAN' and does not mention side effects, validation rules, default values (e.g., archived flag), idempotency, or required permissions. This is a mutation tool with zero behavioral disclosure beyond the word 'create'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise and front-loaded. However, it is so minimal that it borders on under-specification, providing no value beyond a basic action statement. It is not overly verbose, but it does not earn its place by adding meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description is severely inadequate. There is no mention of what the tool returns, any uniqueness constraints, potential errors, or expected behavior on success. The agent has almost no context to correctly invoke this tool beyond the schema's raw field names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is extremely low at 11% (only vlan_id has a description). The description adds no parameter details, leaving eight of nine fields (name, company_id, notes, archived, etc.) unexplained. Required fields like company_id are not described anywhere. The description fails to compensate for the sparse schema, making parameter usage nearly impossible for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new VLAN' clearly identifies the action (create) and the resource (VLAN), making the purpose unambiguous. It does not explicitly differentiate from sibling tools like 'update_vlan' or 'list_vlans', but the verb 'create' inherently distinguishes it from those. Since it lacks any detail about what the VLAN creation entails, it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_vlan' or 'list_vlans'. There is no mention of prerequisites, required fields, or scenarios where this tool should be chosen. The agent is left to infer usage entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides the only behavioral disclosure. It states 'Create' which implies a mutation, but it does not disclose permissions, idempotency, validation behavior, or return values. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and is front-loaded. However, it is under-specified even for a create operation, sacrificing informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 3 required, no annotations, and no output schema. The one-sentence description does not explain the expected behavior, return value, or relationships to other entities, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only vlan_id_ranges has a description). The tool description does not mention any parameter semantics, leaving the agent to infer meaning from parameter names alone. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Create) and the resource (VLAN Zone), distinguishing it from sibling operations like list_vlan_zones, get_vlan_zone, update_vlan_zone, and delete_vlan_zone. However, it lacks additional scope or detail that would elevate it to a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or alternatives. While it is implicitly the create operation for VLAN Zones, the description offers no context for an agent selecting between CRUD tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only the core action 'Delete' but does not mention whether the deletion is permanent, cascading, or requires special permissions. This lack of contextual detail is inadequate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and avoids verbosity, but it is under-specified rather than concisely informative. It omits essential usage context, making the brevity a drawback rather than an asset.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description should compensate with richer detail. 'Delete an Asset' alone is not sufficient for an agent to understand invocation semantics, potential side effects, or the role of each parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the meaning or purpose of 'id' and 'company_id'. The agent must infer that 'id' refers to the asset and 'company_id' is a scope, but no explicit help is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('Asset'), clearly distinguishing it from sibling tools that target other resource types like Company, Article, or Asset Password. However, it lacks additional context such as whether the asset is permanently deleted or any scoping details, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives like archive_asset (soft delete) or other delete tools. There is no mention of prerequisites or context where deletion is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only implies a read-only operation via 'Get'. It does not mention pagination behavior despite a 'page' parameter, default filtering, or whether the result is comprehensive across all asset layouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, which is appropriately concise for a simple listing operation. However, it is under-specified, lacking any parameter or context details, so it falls short of a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is wholly insufficient for a tool with five optional parameters and no output schema or annotations. It fails to clarify what an Asset Layout is, how parameters interact, how pagination works, or what the response contains, leaving major knowledge gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has five parameters with zero description coverage, and the tool description does not explain any of them. Parameter names like 'slug', 'active', and 'updated_at' lack context, so the agent cannot infer their purpose or expected formats from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of Asset Layouts' uses a clear verb ('Get') and specific resource ('Asset Layouts'), distinguishing it from the singular get_asset_layout and other asset layout operations. It is slightly minimal but unambiguous about the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_asset_layout, or when filtering by parameters like active or updated_at would be relevant. There is no mention of exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It only states a list operation, omitting pagination behavior, filtering semantics, or response shape. This leaves the agent without critical 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and free of fluff, which is structurally concise. However, it is under-specified for a 6-parameter list tool, so the brevity works against usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a tool with 6 parameters, no annotations, and no output schema. It does not explain how filters interact, whether pagination is supported, or what the response contains, making correct invocation difficult.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17% (only flagable_type has a description), and the tool description adds no parameter meaning. With 6 parameters, including page, page_size, and multiple filter fields, the description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of Flags.' clearly names the action and resource. It distinguishes from sibling get_flag by implying a collection, but it doesn't specify scope or filtering, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use list_flags versus get_flag, list_flag_types, or other list tools. The description implies usage for listing flags but provides no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, but it only says 'Get a list' without disclosing whether the list is filtered, paginated, or what the return value contains. It fails to mention that parameters like page and page_size control pagination, or that name/color might filter results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with no filler. It is front-loaded and efficient, but it is so minimal that it sacrifices usefulness. Still, for conciseness itself, it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return value structure, filtering behavior, pagination, or any edge cases, making it inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not reference any of the 5 parameters (name, page, slug, color, page_size). It provides no meaning beyond the bare property names, so an agent cannot infer how to use these parameters for filtering or pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of Flag Types' clearly states the action (get) and the resource (list of Flag Types). It distinguishes itself from siblings like get_flag_type (singular) and list_flags (different resource) by using the plural 'Flag Types', though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention that this is for retrieving all flag types as opposed to a specific type via get_flag_type, nor does it indicate any filtering or pagination use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the basic action without revealing pagination, search capabilities, return format, or any side effects, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is brief and front-loaded, with no unnecessary words. It is concise, though the lack of any structural elements like parameter notes slightly limits its usefulness for a tool with five parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is grossly incomplete for a tool with five parameters, no annotations, and no output schema. It omits essential context about filtering, pagination, and company scoping, making it insufficient for an 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the five parameters. It fails entirely to compensate for the missing parameter details, leaving the agent without any indication of what 'name', 'page', 'search', 'page_size', or 'company_id' mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a list of password folders' clearly states a specific verb and resource, making the purpose understandable. However, it does not differentiate from sibling tools like 'list_folders' or 'get_password_folder', so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of exclusions, prerequisites, or situations where another tool like 'get_password_folder' 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.
Behavior2/5
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 that it returns a list, without disclosing pagination behavior, filtering capabilities, or what the response contains. This is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, effectively front-loading the core purpose. However, it is under-specified, which slightly reduces the score from 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is severely incomplete. It fails to explain return values, pagination, filtering, or any operational context, leaving the agent without essential information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not reference any of the 8 parameters, and the input schema has 0% description coverage. The agent receives no semantic guidance for parameters like 'name', 'page', 'slug', or 'global_template', making the tool difficult to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a list of Procedures (Processes)' clearly specifies the action (get) and resource (list of procedures). It distinguishes from the sibling 'get_procedure' which likely returns a single procedure, but does not differentiate from other list_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks any mention of prerequisites, use cases, or exclusions, leaving the agent without context on when to select this over similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 restates the tool's name without detailing pagination behavior, authentication needs, return structure, or any filtering semantics beyond 'public'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no verbosity, and it is front-loaded with the main verb. However, it is under-specifying, providing little value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional pagination, the description is too sparse. It fails to indicate what a 'photo' contains, whether results are paginated by default, or the response format. Given the absence of an output schema, the description should fill that gap but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (page, page_size) with zero description coverage, and the description does not mention pagination or any parameter details. Thus, the agent receives no additional meaning beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get a list) and resource (public photos), using a specific verb and resource. However, it does not explicitly differentiate from sibling 'list_photos', relying on the 'public' qualifier in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'list_photos' or other list tools. No prerequisites, exclusions, or alternative scenarios are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation but does not mention filtering, pagination, authentication, or return value shape. The description essentially restates the name without adding meaningful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is concise. However, it is under-specified rather than appropriately informative, as it omits essential details needed for usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain any parameters or what the response contains, making it inadequate for an agent to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists 5 parameters with no descriptions, and the description mentions none. With 0% schema description coverage and no parameter explanation in the tool description, an agent has no way to understand what the parameters do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of VLAN Zones, which is a specific verb+resource. However, it does not distinguish between VLAN Zones and VLANs (sibling list_vlans), nor does it clarify the relationship, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the similar list_vlans or get_vlan_zone. No context is provided about scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for exposing behavioral traits. It only states the basic action and says nothing about pagination, filtering, authentication, side effects, or return behavior. The description is purely declarative and lacks any behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose. It wastes no words and is adequately front-loaded. However, it is extremely terse and omits useful detail, though that is a completeness issue rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no annotations, and no output schema. The description only says 'get a list of monitored websites,' which is insufficient to understand pagination, filtering, or the response format. It provides a bare minimum of context and is inadequate for a tool with this parameter complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the six parameters. It fails to explain how 'name', 'page', 'slug', 'search', 'page_size', or 'updated_at' influence the returned list, leaving the agent without semantic understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a list of monitored websites, using a specific verb and resource. It identifies the scope ('monitored') and distinguishes it from other list tools by its target resource, though it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of criteria for selecting this over other list tools, no exclusions, and no context about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only shows a read operation ('Look up') but says nothing about matching semantics, potential multiple results, pagination, or error behavior. Minimal value added beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, earning its place as a concise statement. However, it is so brief that it omits essential context, making it under-specified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no schema descriptions, no annotations, and no output schema, the description must offer substantial context. It completely fails to explain return values, matching logic, or parameter semantics, leaving the agent without enough information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter meanings. It only offers the phrase 'external integration details', which does not distinguish integration_id, integration_slug, or integration_identifier. The agent cannot determine which parameters are needed or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') with a resource ('Hudu records') and a distinguishing mechanism ('by external integration details'). It differentiates from sibling get_* tools by focusing on external integration rather than direct IDs, though it could be more explicit about the exact kind of record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any exclusions or preconditions. The description merely states the action without explaining contexts, leaving the agent to infer usage from parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only restates the action without explaining side effects, reversal, permissions, or return values. It adds no new information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. It essentially repeats the tool name and provides no additional context, making it a placeholder rather than a well-structured, informative explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter documentation, the description is insufficient. It fails to clarify the role of company_id or id, or specify what unarchiving entails, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two required parameters (id and company_id) with zero description coverage in the schema. The description does not explain what these parameters represent or how they relate to the asset, forcing the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'unarchive' with the resource 'Asset', clearly distinguishing it from sibling tools like unarchive_company or unarchive_asset_password. This matches the tool name and is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., the asset must be archived) or compare to related tools like archive_asset, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Update', implying a mutation, but does not disclose whether it performs partial updates, whether missing fields are reset, what permissions are required, or what the response looks like. This is a significant transparency gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise and well-structured. However, this brevity sacrifices helpful detail, but for what it is, it is clean and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (6 parameters, no annotations, no output schema), the description is severely incomplete. It omits parameter explanations, side effects, usage context, and return values, making it inadequate for an agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with zero descriptions, and the description does not add any meaning to them. 'Update a Knowledge Base Article' hints that the parameters like name, content, or folder_id are updatable fields, but provides no specific semantics or constraints. With 0% schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'Knowledge Base Article', which distinguishes it from sibling tools like create_article or archive_article. However, it does not elaborate on what aspects of the article can be updated, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is a terse statement of what the tool does, but does not mention prerequisites, exclusions, or scenarios where another tool like create_article or archive_article would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only says 'Update an existing Asset.' It does not disclose whether the update is partial or full replacement, how unspecified fields are treated, any authorization requirements, or the response format. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundancy, which is concise. However, it's not structured to convey more than the core action; it could benefit from a brief list of key updateable fields, but that would increase length. As is, it's acceptable for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an 8-parameter mutation tool with no output schema and no annotations, yet the description provides zero behavioral, prerequisite, or parameter context. It is far below the minimum viable description for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter semantics—it doesn't mention any of the 8 parameters. Custom fields, primary_mail, etc., are left unexplained, making it impossible for the agent to know what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (update) and resource (Asset), distinguishing it from create_asset, delete_asset, and archive_asset. However, it doesn't enumerate which fields are updatable, leaving the schema to carry that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_asset, delete_asset, or other asset-related operations. It doesn't mention prerequisites like whether the asset must exist or what conditions are required, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'update', which implies mutation, but does not state whether it is a partial or full replacement, whether it requires any permissions, what happens to omitted fields, or what the response looks like. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. However, it is under-specified, failing to include useful context that could be added without much verbosity. It is appropriately short for a simple update message but lacks necessary structural elements like sections or clarifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters and no output schema, the description is severely incomplete. It does not explain return values, error behavior, edge cases, or how parameters interact. The lack of annotations and schema descriptions leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 16 parameters with 0% description coverage, and the description adds no meaning beyond what the raw property names provide. It only mentions the required 'id', leaving the other 15 fields (e.g., id_number, parent_company_id, company_type) entirely unexplained. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the resource ('company'), and the identifier ('by ID'). It distinguishes from sibling tools like delete_company and create_company by specifying update semantics. However, it lacks detail on what specific fields or behaviors are involved, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as create_company, archive_company, or delete_company. It does not mention prerequisites, typical use cases, or excluded scenarios. The description implies usage but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It merely says 'Update a folder' without mentioning side effects, required fields, permission needs, or the result of the operation, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single short sentence. While it is front-loaded and wastes no words, it is under-specified for a tool with six parameters, making it less useful than it could be even at this length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (six parameters, no output schema, and no annotations), the description is far too sparse. It lacks any details about behavior, parameter semantics, or expected results, making it inadequate for an agent to use the tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the six parameters (id, icon, name, company_id, description, parent_folder_id). There is no added meaning beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'folder', making the core purpose understandable. It is distinct from sibling tools by naming the specific resource, though it doesn't elaborate on what updating entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_folder, get_folder, or delete_folder. The description simply states the operation without contextualizing its place in the folder lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior, but it only states 'update' which is already evident from the tool name. It does not explain effects on monitored status, field replacement semantics, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler or redundant text, making it highly concise and easy to parse. However, its brevity comes at the cost of omitting useful context, so it is not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is far too sparse to be complete. It fails to mention required parameters, optional fields, return values, or any operational context needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the 8 parameters. Since schema description coverage is 0%, the description fails to add any meaning beyond the property names in the schema, leaving parameter semantics entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a website, using the specific verb 'update' and the resource 'website'. It distinguishes from create/get/delete siblings, though the adjective 'monitored' adds a minor qualification that is not fully explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_website or delete_website. There is no mention of prerequisites, typical use cases, or conditions under which this update should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 'Update an existing IP address' without mentioning whether updates are partial or full, whether the IP must exist, validation rules, immutability of fields, or any side effects. This is a serious gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately concise in structure, though it sacrifices substantive information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no output schema, and no annotations, yet the description provides no additional context about the update semantics, field constraints, or return behavior. The agent would have no way to correctly invoke this tool beyond guessing from the parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with 0% description coverage, and the description names none of them (only the resource 'IP address'). The required 'id' and all optional fields lack any explanatory context, making it impossible for an agent to know what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and the resource 'IP address', clearly identifying the tool's action and target. It distinguishes itself from sibling tools like create_ip_address, delete_ip_address, get_ip_address, and list_ip_addresses by specifying the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites or exclusions. It only restates the function, leaving the agent to infer usage context from the tool name and schema without any explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. It gives no information about side effects, required permissions, return values, constraints, or what happens after creation, which is a significant gap for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words and is front-loaded with the purpose. It is extremely concise, though perhaps too minimal for a 5-parameter tool, but for conciseness itself it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, the description is incomplete. It does not explain the nuances of the parameters (e.g., company_id for global vs. company-specific articles), any return value, or post-creation behavior, making it insufficient for an agent to fully understand the tool's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 40% (2 of 5 parameters have descriptions), and the tool description adds no parameter context. Parameters like name, folder_id, and enable_sharing are left entirely without explanation, and the description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a Knowledge Base Article'), which is specific and distinguishes it from sibling article tools like update_article or list_articles. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_article or archive_article. It does not mention prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create a new Flag Type,' which essentially restates the tool name. It gives no information about side effects, permissions, uniqueness constraints, or return behavior, leaving the agent without critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence with no wasted words. It is front-loaded and easy to parse, which is good for conciseness. However, it is under-specified in other dimensions, but that is not penalized here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, the description is extremely sparse. It doesn't explain what a Flag Type is, what the return value looks like, or any constraints on creation. Given that there are no annotations and no output schema, the description is insufficient for an agent to fully understand the tool's purpose and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (name and color) with zero description coverage. The description doesn't mention these parameters at all, providing no additional meaning beyond the raw schema types and enum values. The agent gets no guidance on what 'name' or 'color' represent or how they should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (Flag Type), and it distinguishes from sibling operations like update_flag_type, delete_flag_type, and get_flag_type. However, it doesn't explain what a Flag Type is or how it relates to flags, so it's clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't mention when to use this tool, any prerequisites, or alternatives. It merely states the action without any 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for transparency. It discloses that the tool uploads a photo from a local path, but it does not mention what happens after upload, whether it overwrites existing photos, or any side effects like database record creation. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of redundant wording, but it is not well-structured to guide the user. It would benefit from a more explicit structure that lists key requirements (e.g., caption is required) and optional fields. It is concise but at the expense of needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 2 required, and no output schema or annotations, the description is far from complete. It only covers file_path and gives no information about the required caption, the return value, or how the photo relates to other resources via photoable fields. The description would need to be substantially expanded to be minimally viable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'local file path', which mirrors the schema description for file_path, adding no new meaning. It does not clarify the purpose or syntax for the required 'caption' parameter or the optional but likely important parameters like folder_id, company_id, photoable_id, photoable_type, and pinned. With schema coverage at only 57%, the description fails to compensate for these undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core function 'Upload a new Photo' with a clear verb and resource, and it adds the requirement of a local file path. However, it does not explicitly distinguish this from the sibling tool 'create_public_photo', so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is to provide a local file path, which is a prerequisite but not usage context. There is no mention of when to prefer this over alternatives or any exclusions, such as the public photo variant. No when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'Delete' without indicating whether the deletion is permanent, whether it requires permissions, or if there are side effects. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the verb 'Delete.' It is appropriately sized for the simplicity of the tool, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the presence of sibling tools like archive_asset_password and unarchive_asset_password makes the one-line description incomplete. It does not clarify that this is a permanent deletion as opposed to archiving, which is essential for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with no description (0% coverage). The description adds that the operation is 'by ID,' which is a minimal cue, but it does not explain what the ID refers to or any constraints, leaving the agent with little extra understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (Password) with a method (by ID). It is specific enough to distinguish from sibling tools like archive_asset_password, though it relies on the tool name for the 'asset' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of the distinction between delete and archive/unarchive, which are sibling tools, so the agent is left without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as side effects, required permissions, idempotency, or what 'starting' a procedure entails. The agent is left without critical information about the mutation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise as a single sentence, but it is under-specified. While it avoids fluff, it lacks essential details about the procedure, making it minimally adequate rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is insufficient for an agent to understand parameter semantics, expected return, or contextual prerequisites. The tool appears to be a mutation but provides no details about the process it triggers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes three parameters (id, name, asset_id) with 0% description coverage. The description does not explain the meaning or purpose of any parameter, leaving the agent unable to construct a valid invocation beyond knowing 'id' is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Start/kickoff' and clearly identifies the resource 'Procedure', distinguishing it from sibling tools like create_procedure, update_procedure, and list_procedures. The phrase 'from a company process' adds context and clarifies the intended action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as create_procedure, create_procedure_from_template, or duplicate_procedure. The description only states the action without exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. 'Retrieve' implies a non-destructive operation, but there is no mention of pagination, filtering behavior, authentication needs, or the structure of the returned items. The description adds minimal transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the basic purpose. It avoids redundancy and verbosity, but it is so terse that it borders on under-specification; still, as a concise summary, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, and no output schema, the description is highly incomplete. It does not explain what a Magic Dash Item is, how pagination works, or what type of data is returned, leaving significant gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains four parameters (page, title, page_size, company_id) with 0% schema description coverage, and the description does not mention any of them. It fails to explain how these parameters affect the result, leaving the agent without essential information about filtering or pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Retrieve') and a specific resource ('Magic Dash Items'), making the tool's primary purpose understandable. However, it lacks differentiation from sibling list tools beyond the unique entity name, and the term 'Magic Dash Items' is not defined, so the scope 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like list_lists or other list_* tools. The description merely states what it does without mentioning prerequisites, exclusions, or recommended usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It indicates a read-only list operation but fails to mention pagination behavior, default page sizes, ordering, or that 'all' may be limited by pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and is front-loaded with the verb and resource. It is appropriately concise, though it sacrifices useful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is incomplete. It does not describe the return structure, pagination semantics, or specifics about what relation data is returned, making it barely adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning for the two parameters. The names 'page' and 'page_size' are suggestive, but defaults, limits, and whether they are required or optional remain undocumented, leaving the agent without needed semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get a list') and the resource ('relations'), distinguishing it from sibling tools like create_relation and delete_relation. However, 'between entities' is vague and does not specify what kinds of relations or entity types are included, leaving some ambiguity about the tool's exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The pagination parameters (page, page_size) are present in the schema but the description does not explain how they affect usage or whether fetching 'all relations' requires pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action, but omits critical traits such as whether partial updates are allowed, if any fields are immutable, potential side effects, or required permissions. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, achieving high readability. However, it is under-specified for a tool with 6 parameters, so while concise, it could still benefit from additional structured detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and the presence of 6 parameters, this description is far from complete. It fails to explain return values, update semantics, or any special behavior, leaving the agent with insufficient context to use the tool correctly beyond the schema itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters or their semantics. With 6 parameters, the description must compensate for the schema's lack of explanations, but it adds zero value for understanding what each field does or how they should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing Procedure'), which distinguishes it from create/delete/get operations. However, it lacks scope by not specifying which fields or what kind of updates are possible, 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.
Usage Guidelines2/5
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 like create_procedure or update_procedure_task. No context, prerequisites, or exclusions are provided, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, whether fields are overwritten or merged, if archived can be set, or any constraints such as required fields or validation behavior. For a mutation tool, this lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—one sentence with no filler. It is front-loaded and clear. However, it may be under-specified, which is a trade-off: conciseness is good, but the description could earn its space by adding more useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no annotations or output schema, this description is underspecified. It does not explain return values, side effects, or parameter semantics. The completeness is adequate for a simple CRUD update, but the lack of any usage or behavior detail leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it names no parameters and provides no context about the meaning or usage of the six schema properties. The field names are self-explanatory, but the description adds no value beyond the schema. Without any parameter info, a baseline of 4 might apply, but the complete absence of elaboration in the description prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VLAN Zone' clearly states a verb ('Update') and resource ('VLAN Zone'). However, it does not distinguish this from sibling tools like create_vlan_zone or list_vlan_zones, and it lacks any detail about what updates are possible or the scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_vlan_zone or get_vlan_zone. The description does not mention prerequisites, typical use cases, or exclusions. It offers only the minimal statement of purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 ('Create') without any details on side effects, permissions, validation (e.g., DNS validation), or uniqueness requirements. This is a marginal improvement over a tautology but still lacks meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, which is appropriately concise for a simple create operation. However, it lacks any structured breakdown (e.g., parameters, examples) that would enhance utility, though this is not the primary issue given the extreme brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, 2 required, an enum, and no output schema. The description provides zero context about required fields, status meanings, or validation behavior. For a create tool with this complexity, the description is severely inadequate and leaves the agent without sufficient information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with 0% description coverage. The description provides no additional meaning for parameters like address, company_id, status, skip_dns_validation, etc. Since schema coverage is essentially nonexistent, the description fails entirely to compensate, leaving the agent without clarity on how to populate the fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('IP address record'), clearly distinguishing it from sibling tools like list_ip_addresses, get_ip_address, update_ip_address, and delete_ip_address. It unambiguously states 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.
Usage Guidelines2/5
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 any prerequisites or context. It does not mention, for example, when one would create an IP address vs. update an existing one, or whether certain fields are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. 'Create' implies a mutating operation, but the description does not mention permissions, idempotency, side effects, or return behavior. It's marginally more informative than nothing, but still a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded and easy to parse, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is too thin. It lacks essential context about prerequisites, side effects, return values, and edge cases, making it incomplete for an AI agent to invoke safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. Schema coverage is 50% (only list_items_attributes has a description); the 'name' parameter is self-explanatory but the description doesn't clarify it further. The phrase 'selectable List' hints at the purpose but does not map to the schema parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('new selectable List'). It distinguishes this tool from other create_* siblings by naming the specific entity type, though it doesn't elaborate on what 'selectable' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when creating a selectable list, but provides no context on when to prefer this over alternatives (e.g., update_list, list_lists). No exclusions, prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral transparency burden. It states 'Delete' which implies destructive action, but it does not disclose irreversibility, return values, permissions, error behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing only essential information ('Delete ... by ID'). There is no redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and minimal parameter explanation, the description is incomplete. It lacks guidance on usage, effects, and expected outcomes, leaving the agent to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'id' parameter. The description merely says 'by ID' without explaining the expected format, whether the ID must exist, or how non-existent IDs are handled. It adds essentially no meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('Magic Dash Item'), and the scope ('by ID'). It is specific and understandable, though it does not explicitly mention the sibling tool 'delete_magic_dash' or explain how the two differ.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'delete_magic_dash' or other Magic Dash tools. The description gives no context about prerequisites or situations where this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context beyond the basic list operation. It does not state that the operation is read-only, whether filters affect archived networks, or what response shape to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of filler. It is appropriately concise for a simple list tool, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, plus 9 undocumented parameters, this description is too thin to fully guide an agent. It only provides name-level purpose and leaves filtering behavior, scope, and return shape unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 9 parameters, and the description does not mention any of the parameters or their meanings. The description fails to compensate for the completely undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a list of networks,' which clearly identifies the operation (listing) and resource (networks). It implicitly distinguishes from get_network by using 'list,' but it does not specify scope such as whether all or only filtered networks are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to prefer this tool over get_network or other list_* tools, nor does it note any exclusions, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It only conveys a read operation ('Get a list') but does not describe pagination, default filters, archived handling, permissions, or response format, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately size-efficient, though its brevity leaves out substantive details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 9 optional parameters, no annotations, and no output schema, this description is severely incomplete. It fails to mention pagination behavior, filter interactions, or what the response contains, making it insufficient for an agent to invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44% (4 of 9 params have descriptions), and the description does not compensate. It merely says 'optional filtering' without explaining the meaning of page, archived, folder_id, page_size, or company_id. The description adds no parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('a list of Photos') and mentions optional filtering. It distinguishes from single-photo tools like get_photo, but does not explicitly differentiate from list_public_photos, a close sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_public_photos. The phrase 'optional filtering' hints at usage but gives no context on typical use cases, filter combinations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get a list' which implies a read operation, but gives no information about pagination, ordering, filtering behavior, permissions, or return format. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with no redundancy. It is a single grammatically complete sentence, but it sacrifices useful detail. It is appropriately concise for its minimal content, though not as comprehensive as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no schema descriptions, annotations, or output schema, the description is severely incomplete. It does not explain the returned data, available filters, or when to use this listing tool instead of individual retrieval tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage, and the description does not mention any of them. It fails to explain what height, max_width, min_width, company_id, etc. mean or how they affect the list. The description provides zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get/list) and resource (Rack Storages), distinguishing it from singular get_rack_storage and other rack storage operations. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it lists all storages or that parameters can filter results, nor does it contrast with list_rack_storage_items or get_rack_storage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Retrieve a list of users' without mentioning any behavior such as pagination, default sorting, archived filtering, auth requirements, or that it is a read-only operation. This leaves significant gaps for a 9-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core function. It wastes no words, but it may be under-specified for the tool's complexity. This is concise and front-loaded, though it sacrifices helpful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, the description is far from complete. It fails to explain pagination behavior, parameter semantics, or any typical usage context. The minimal information leaves the agent guessing about how to structure calls and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, and the description adds no parameter information. While parameter names like 'page' and 'email' are somewhat self-explanatory, ambiguous ones like 'portal_member_company_id' remain unexplained. With low coverage and no description compensation, this dimension has clear deficiencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of users, using a specific verb 'Retrieve' and resource 'users'. It distinguishes itself from singular 'get_user' by indicating plural 'list', though it lacks explicit scope clarification. This is clear enough but not as detailed as the high-caliber example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_user or other list_* tools. The description gives no context about typical use cases, filtering scenarios, or relationships with sibling tools, so the agent has no help choosing among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'update metadata.' It does not state whether it performs a partial or full update, whether any fields are immutable, or mention authentication or side effects. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is efficient, though extremely brief, which earns a high score for conciseness even if it under-delivers on content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, this one-sentence description is far from complete. It does not explain the effect on the photo, the meaning of input fields, or the expected response, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters beyond the vague term 'metadata.' It fails to add meaning to the seven schema properties, leaving the agent without semantic guidance for fields like pinned, caption, folder_id, or photoable_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update'), the resource ('Photo'), and the scope ('metadata') with a specific identifier ('by ID'). This distinguishes it from siblings like create_photo, get_photo, and update_public_photo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_photo or update_public_photo. The description implies it's for an existing Photo but gives no explicit prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'Update an existing Procedure Task,' which implies a mutation but does not disclose side effects, whether it performs a partial or full update, idempotency, permission requirements, or return values. This is a significant gap for a mutation tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It is concise and easy to parse. However, it is almost too sparse, providing only the bare minimum and lacking any additional context that could justify a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, and no annotations, the description is severely underspecified. It does not explain update semantics, optional fields, error behavior, or any other operational detail. The agent would need to guess or rely on external documentation to use it correctly, making the description inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description also fails to list or explain any parameters, leaving the agent to infer semantics from parameter names alone. Ten parameters exist, including ambiguous ones like 'position' and 'assigned_users,' and the description does nothing to clarify their meaning or the update behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing Procedure Task' clearly states the verb (update) and resource (Procedure Task), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like create_procedure_task and delete_procedure_task through the explicit action and resource. However, it lacks any additional scope or context that would elevate it to a 5, such as which fields can be updated or any special behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, related tools, or exclusions. The only implicit signal is the name itself, which suggests it is for updating existing tasks, but this is not explicitly stated as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create a Flag on a record' and does not mention permissions, side effects, or what happens if a flag already exists for the same record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence with no redundancy, making it very concise. However, it is terse to the point of omitting essential context, but the structure itself is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and minimal description. While the flagable_type enum offers some context, the description fails to explain the creation semantics, required relationships, or expected behavior of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the four parameters. It fails to clarify the meaning of flag_type_id, flagable_type, or flagable_id, or how they relate to the flag being created.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'Flag' and target 'record', clearly distinguishing this from siblings like update_flag, delete_flag, or get_flag. It states exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_flag_type or update_flag. There is no mention of prerequisites, such as needing a flag type to already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states the action without explaining whether the duplication is deep (copies tasks, files), whether the name is auto-modified, or what the return value is. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler or redundancy. It is front-loaded and concise, though it is under-specified as a trade-off.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, no output schema, and side-effect potential, the description is inadequate. It does not explain required fields, behavior, or use context, leaving the agent without enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate at all. The four parameters (id, name, company_id, description) are left undocumented in the description, offering no added meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Duplicate an existing Procedure' uses a specific verb (duplicate) and resource (Procedure), clearly distinguishing it from sibling tools like create_procedure, update_procedure, and delete_procedure. It is not a tautology and accurately states the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_procedure or create_procedure_from_template. There are no contextual hints, exclusions, or preconditions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that it retrieves metadata, but does not disclose the impact of the 'download' parameter (e.g., whether a download URL is included by default, or any error behavior). It fails to clarify what happens when the ID does not exist or whether additional permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values. It only says 'metadata' without specifying fields or the difference when 'download' is true. The interaction between the two parameters is not clarified, leaving the description incomplete for a tool with two parameters and no structured output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only 'download' having a description. The tool description adds no meaning to either parameter; it does not explain 'id' or elaborate on the 'download' behavior beyond the schema. Since the schema already covers half, the description needed to compensate for the other half but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get export metadata by ID.' It specifies the resource (export metadata) and the identifier (ID), making it easy to distinguish from list or create export tools. However, it does not explicitly differentiate from other get_* tools, though the resource is self-evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, the need for an existing export ID, or comparison to list_exports/create_export. It offers no contextual framework for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the basic action and omits details such as pagination behavior, read-only nature, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It communicates the core purpose efficiently, though it borders on under-specification by omitting important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, absent annotations, and no output schema, the description is too sparse. It lacks coverage of pagination, filtering options, and company scoping, making it incomplete for correct invocation and expectation-setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description does not explain any of them. The agent receives no guidance on how name, page, page_size, company_id, or in_company affect the results, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of KB article folders, using a specific verb and resource. The 'KB' qualifier differentiates it from other list tools like list_password_folders, establishing a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_folder for single-folder retrieval or list_password_folders for password folders. No exclusions or selection criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only states 'Update a Flag Type by ID' without explaining potential side effects, error behavior for non-existent IDs, or whether updates are partial or full replacements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It is concise and communicates the core action, though more detail could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and 0% schema description coverage, this sparse description leaves significant gaps. It does not explain the updateable fields, expected response, or how the tool behaves in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning for 'id' by indicating it is the lookup key, but it provides no explanation for 'name' or 'color.' Schema description coverage is 0%, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('Flag Type') with the method 'by ID.' This distinguishes it from sibling tools like create_flag_type, get_flag_type, and delete_flag_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, such as needing an existing flag type, or when create_flag_type 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the intended action without addressing side effects, permissions, template validation, copy behavior, or return values. This leaves significant behavioral ambiguity for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It is front-loaded and efficiently conveys the core action. However, it is so brief that it lacks needed detail, though this detracts more from completeness than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves creating a new instance from a template with four parameters, yet the description offers no insight into the process, optional parameter behavior, template requirements, or return format. The absence of output schema and annotations further compounds the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 25% coverage (id has a description), and the description does not mention any parameters. It does not clarify the role of name, company_id, or description (e.g., whether they override template values). The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new Procedure instance from an existing template.' It uses a specific verb ('create'), identifies the resource ('Procedure instance'), and specifies the source ('from an existing template'). This distinguishes it from siblings like create_procedure and duplicate_procedure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios (creating a procedure based on a template) and the name reinforces this, but there is no explicit guidance on when to use this tool versus alternatives like create_procedure or duplicate_procedure, nor any exclusions. It 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.
Behavior2/5
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 the action ('Add a website to monitor') but does not disclose side effects, permission requirements, what monitoring entails, or any other behavioral implications beyond the literal meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly conveys the tool's core purpose, exemplifying good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 output schema, and no annotations, the one-sentence description is severely under-specified. It lacks essential context about required inputs, optional flags, expected behavior, and possible return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (just 'name' is described). The tool description adds no parameter semantics, leaving notes, paused, disable_dns, disable_ssl, and disable_whois completely unexplained, so an agent cannot infer their meaning or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a clear resource 'website' and includes the purpose 'to monitor.' This distinguishes it from sibling tools like update_website, delete_website, and list_websites, making the intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites, exclusions, or when not to use it. The description only states the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action without mentioning side effects, irreversibility, cascade deletions, or required permissions. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the action and resource, making it extremely concise and efficient. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature (delete) and lack of annotations or output schema, the description is under-specified. It does not explain what happens to the folder's contents, whether the action can be undone, or what the expected outcome is. It also doesn't clarify the resource type relative to siblings. The simplicity of the tool doesn't excuse the missing safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with 0% description coverage, so the description must add meaning. Saying 'by ID' clarifies that the id parameter identifies the folder, which adds some context. However, it does not explain how to obtain the ID or any format details beyond the schema type. Minimal but adequate for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a folder by ID' clearly states the verb (delete) and resource (folder), and specifies the parameter. It distinguishes from sibling delete tools like delete_password_folder by targeting the generic 'folder' resource, though it doesn't explain what a folder is. Clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. The description does not specify prerequisites (e.g., folder must be empty), nor does it clarify which type of folder (general vs password folder). No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It fails to disclose whether deletion is permanent, whether there are cascading effects on related data, or what permissions are required. For a destructive operation, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb and clearly communicates the core function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter, the absence of annotations and output schema means the description should explain the return value, error handling, or irreversibility. None of these are covered, leaving an agent without critical behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one integer 'id' with zero description coverage. The description only adds that the id identifies the List to delete, which is minimal and largely redundant given the schema already calls it 'id'. It does not explain how to obtain the id or the type of List.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') and a clear target ('a List by ID'), which distinguishes it from sibling tools like get_list, update_list, and list_lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no mention of alternatives (e.g., archiving vs deleting). The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 mention that deletion is permanent, whether it requires special permissions, what consequences may occur (e.g., cascading deletes), or what the response will be. The description adds no behavioral insight beyond the verb 'delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information with no wasted 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simple interface, the description is incomplete for a destructive operation. It lacks details about side effects (e.g., whether related data is removed), return values, or prerequisites. With no output schema and no annotations, the agent is left without crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter (id) with 0% description coverage. The description says 'by ID', which connects the parameter to the website, but it does not elaborate on the nature of the ID, how to obtain it, or any format expectations. The description adds minimal meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a monitored website'), and specifies the mechanism ('by ID'). It unambiguously distinguishes this tool from siblings like get_website, update_website, and delete_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or alternative tools. It is simply a statement of the action, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only implies a read operation via 'Retrieve' but does not mention pagination behavior, output shape, or any constraints—leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, low on verbosity. It could include more useful details without becoming bloated, but as-is it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema or annotations, the description is extremely sparse. It fails to mention expected response format, pagination details, or any useful context, making it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 8 parameters. The description adds only 'optional filtering', which adds little beyond what the schema already conveys, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('activity logs'), making the tool's purpose clear. It does not explicitly differentiate this from sibling list_* tools, but the resource name is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 delete_activity_logs. The description only states what the tool does, with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It does disclose one behavioral trait: member lists exclude admins/super admins. However, it does not mention pagination, filtering, output structure, or any other behavioral nuances, leaving significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core action. It is succinct and well-structured, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters and no output schema, the description is incomplete. It fails to mention parameter usage, return format, filtering capabilities, or pagination behavior. The single behavioral trait about admins is not sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description provides no explanation of any parameters (name, page, search, default, page_size). This is a critical gap; the agent cannot infer what these parameters do or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of groups, using a specific verb and resource. The parenthetical 'member lists exclude admins/super admins' adds a scope nuance that helps differentiate it from a generic list operation, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention any context, prerequisites, or alternatives (e.g., when to use list_groups vs get_group or list_lists). This leaves the agent without guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the basic read operation ('List') but does not describe pagination, filtering, side effects, or response format. The addition of 'company mappings' provides minimal context but not sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word contributes to the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is too minimal. It does not mention pagination, filtering options, or what the response contains, leaving significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions only 'for a specific integration', which points to integration_id but does not explain any of the other six parameters (page, matched, sync_id, page_size, company_id, identifier). The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('integration matchers'), and clarifies the domain with 'company mappings'. It distinguishes from sibling list tools by specifying the integration scope, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like list_companies or get_company. It only implies that an integration_id is needed but does not mention any prerequisites, exclusions, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the basic action (updating a record association) but does not disclose side effects, whether the association is replaced or appended, required permissions, or what happens to the previous association. For a mutation tool, this is a significant lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, making it very concise. However, it is so terse that it omits critical context, which is a trade-off. It earns points for front-loading the core purpose but deducts for being slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and minimal parameter documentation. The description does not explain what record types are allowed, how the association is updated, or what the success/failure response looks like. Compared to similar tools, it leaves important gaps for a functional operation, making it incomplete for an agent to invoke correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the input schema has no descriptions for id, record_type, or record_id. The description vaguely implies that id refers to the public photo and record_type/record_id refer to the new association, but it does not explicitly explain the meaning or allowed values for record_type. With 0% coverage, the description must compensate, and it does not sufficiently do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a public photo's record association' clearly identifies the action (update), the resource (public photo), and the specific aspect (record association). It effectively distinguishes this tool from sibling 'update_photo', which likely updates photo attributes, and from other update tools. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_photo or create_public_photo. It does not mention scenarios where this tool is appropriate or where another tool should be used instead. There is no exclusion criteria or reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only says 'Archive a company by ID' without revealing whether the operation is reversible, what happens to related data, or if any permissions are required. This is a materially incomplete disclosure for a mutation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value, making it appropriately concise for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool mutates state and has no annotations or output schema, the description is too sparse. It does not explain the consequences of archiving (e.g., whether it hides the company, is reversible, or affects dependent resources). A single clause is insufficient for an agent to safely predict the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows a single required 'id' of type number. The description adds 'by ID', confirming that the parameter identifies the target company. Though sparse, this minimal addition is sufficient for the simple parameter; however, it does not go beyond the obvious meaning already implied by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Archive' with the resource 'company' and specifies the scope 'by ID'. This clearly differentiates from siblings like unarchive_company and delete_company, making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that archiving is likely a reversible alternative to deletion, nor does it explain when unarchive_company should be used. The context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get a list,' implying a read-only operation, but it does not disclose pagination behavior (page/page_size), the effect of the 'archived' parameter, or the response format. This lack of behavioral detail is a significant gap for a list operation with filtering options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely states the tool's core purpose without unnecessary filler. However, it omits useful parameter and behavioral details, so while it is efficient, it might be considered under-specified. The conciseness itself is not flawed, but the trade-off is lost context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description must explain return values and behavioral nuances. It does not mention pagination (page/page_size), the archived filter behavior, or what fields are returned. For a tool with four parameters and a filtered list use case, this one-sentence description is inadequate for an agent to invoke it correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter semantics beyond what the schema already shows. It does not explain the meaning of 'page,' 'page_size,' or 'archived,' nor does it clarify whether 'archived' defaults to false or returns both archived and non-archived assets. The sole value is the hint that 'company_id' links to the company, which is already evident from the parameter name and the description's 'specific to a Company.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a list of Assets specific to a Company.' The verb 'Get' and resource 'Assets' with the 'specific to a Company' qualifier distinguish it from sibling tools like list_assets (all assets) and get_asset (single asset). The name and description together unambiguously identify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need assets for a specific company) but does not explicitly specify when to prefer this tool over alternatives like list_assets or get_asset. There are no exclusions or alternative tool mentions, so the guidance is only implicit through the required company_id parameter and the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It only says 'Create' and mentions custom_fields usage, but does not explain side effects, permissions, or what the response will be. The creation action is implied by the name, but no additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core purpose and a key parameter hint without any filler. The description is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns and clarify required fields. It fails to do so, leaving ambiguity about the response and the role of asset_layout_id and other primary fields. The tool is too complex to be adequately covered by this terse description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (custom_fields). The description adds a hint about custom_fields ('Use custom_fields array for custom field values'), but does not clarify the meaning of primary_mail, primary_model, primary_serial, primary_manufacturer, or asset_layout_id. This is insufficient for an 8-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an Asset under a specific company,' providing a specific verb, resource, and scope. This distinguishes it from sibling tools like create_asset_layout or create_asset_password by naming the target resource. The additional note about custom_fields reinforces the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as update_asset or list_assets. The description only implies creation, but does not explicitly state exclusions or mention other asset tools, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Delete a company by ID' and fails to disclose irreversible side effects, cascading deletions, permissions needed, or return behavior—critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It conveys the essential action and resource directly, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, but the description still fails to provide sufficient context for a destructive operation. It omits details about success/failure responses, side effects, and any related constraints, making it incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it merely repeats 'by ID' without adding any detail about the parameter's nature, formatting, or constraints beyond what the schema already shows (a required numeric id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (company), with the identifier (ID). This unambiguously distinguishes it from sibling tools like get_company, update_company, and archive_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 archive_company, nor are any prerequisites or restrictions mentioned. The description only states the action, offering no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Delete' without mentioning consequences like irreversibility, required permissions, or what happens if the ID does not exist. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler. It is front-loaded with the action and resource, and every word serves a purpose for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one parameter, no output schema), the description omits important operational context for a delete operation, such as reversibility, error handling, or related tools to call first. The description is minimally adequate but lacks completeness for an AI agent to invoke it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds minimal value by saying 'by ID,' which merely restates the parameter name. It does not explain the format, origin, or meaning of the ID beyond what the schema property name implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Delete') with a specific resource ('IP address') and the key identifier ('by ID'). It unambiguously distinguishes this tool from sibling delete tools for other resources (e.g., delete_list, delete_article).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as update_ip_address or archive-related operations. There are no stated conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states a destructive action with no mention of potential side effects, such as whether contained passwords are also deleted, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning and no unrelated information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not explain the resource's relationship to passwords or folders, nor whether deletion has cascading effects, making it incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter description, and the phrase 'by ID' adds minimal meaning beyond the obvious integer id. It does not clarify what the ID refers to in practical terms, constraints, or relationships to other resources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the specific resource type (password folder), with an explicit parameter (by ID). It distinguishes from sibling tools like delete_folder and delete_asset_password by naming the unique resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 delete_folder or delete_asset_password. It lacks context about prerequisites, related operations, or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states 'delete', which implies destructiveness, but does not disclose permanence, effects on related data, permission requirements, or return behavior. This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded and free of any padding. It is appropriately compact for a simple delete-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and absence of annotations and output schema, the description should explain what end-user impact deletion has, whether it is reversible, and what the response looks like. It only covers the action and the parameter, leaving critical operational details missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer 'id' with 0% description coverage. The phrase 'by ID' adds minimal semantic meaning (the id is the photo identifier), but does not clarify how to obtain the ID, any constraints, or what the integer represents beyond the parameter name. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 (Photo), and the identifier (by ID). It is specific and distinguishes itself from siblings like get_photo, update_photo, or list_photos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any exclusions or prerequisites. The description only implies its use for deleting a photo by ID, which is insufficient for choosing among similar delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 revealing whether the deletion is permanent, reversible, requires specific permissions, or has side effects. The lack of such context is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the essential action and resource, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one parameter, no output schema), the description lacks critical context for a mutation tool. It does not mention whether the deletion is permanent, if there are any safeguards, or what happens to associated data. The absence of annotations makes this omission more severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It confirms that 'id' is the identifier of the upload, but this is already implicit from the tool name and schema. It adds no additional detail about the parameter's format, provenance, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and clearly identifies the resource ('an upload') and the required identifier ('by ID'). It distinguishes itself from sibling tools by specifying the target resource, 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.
Usage Guidelines2/5
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 does it mention any prerequisites or exclusions. For a delete operation, there is no indication of when deletion is appropriate or any warnings about consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information. It states the action but does not disclose whether the resource is returned, error handling, authentication requirements, or read-only guarantees. This is a minimal getter description with no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It perfectly balances brevity and clarity for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter getter, the description is adequate. However, with no output schema and no annotations, it does not mention return value, error conditions, or whether the resource is partial. It meets the minimum viable standard but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds 'by ID', which clarifies that the 'id' parameter is the lookup key, but this is largely implicit from the tool name. Minimal added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'website', with the method 'by ID'. It distinguishes it from list_websites (which retrieves multiple) and other get_* tools by resource type, but does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_websites or get_article. The description implies usage when an ID is available but gives no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral disclosure burden. It only says 'initiate' without explaining side effects, whether the operation is asynchronous, required S3 configuration, or what is returned, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the key verb and object. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values or follow-up actions, but it doesn't. It covers the basic trigger action but omits context like how to track the export or whether any setup is required. Still adequate for a 0-param tool, so a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers the parameter surface, and the description adds nothing needed. Per baseline for 0-param tools, it earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: initiate an S3 export of Hudu data, using a specific verb and resource. It distinguishes from siblings by specifying S3, but doesn't explicitly contrast with create_export, so it's not perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_export or get_export. There is no mention of prerequisites, exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that logs are deleted, but does not clarify irreversibility, permission requirements, the exact time range semantics ('from' could mean after or before), user/workspace scoping, or what happens to logs not matching the filter. The description is notably vague 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary action, and avoids redundant phrasing. It is appropriately concise without being under-specified, given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description does not explain critical context such as the exact semantics of 'from a specific datetime' (e.g., inclusive, before/after), potential side effects, or how this relates to list_activity_logs. For a destructive tool with minimal structured metadata, this description falls short of being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully (datetime as ISO 8601, delete_unassigned_logs as filtering null user_id). The description adds minimal value beyond restating the schema's flag behavior. Since schema coverage is 100%, a score of 3 is appropriate per the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete activity logs') and specifies a key scope ('from a specific datetime'), distinguishing it from siblings like list_activity_logs and other delete_* tools. The optional flag behavior is also mentioned, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as list_activity_logs, nor does it mention prerequisites, exclusions, or scenarios where deletion would be inappropriate. It only hints at a specific use case for the optional flag, which is insufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Delete', implying destructive action, but does not mention permanence, cascading effects, permission requirements, or return values. This is a significant gap for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the essential information without any wasted words. It is appropriately sized for the simplicity of the tool and is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is not complete enough. It omits critical details such as whether the deletion is permanent or reversible, whether it affects related data, and any prerequisites. For a destructive operation, this information is essential for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required integer 'id' with no description, and the description only says 'by ID'. This adds minimal meaning, confirming the ID is the identifier of the Procedure. While the parameter is simple and self-explanatory, the description does not compensate for the 0% schema coverage beyond this basic reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a Procedure') with the method ('by ID'). It effectively distinguishes this tool from siblings like get_procedure, update_procedure, and delete_procedure_task by clarifying the exact target is a Procedure, identified by its ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 delete_procedure_task or when a procedure should be archived instead. It only states the operation without any context on appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the action. It does not disclose whether deletion is permanent, irreversible, cascading, or requires specific permissions—important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the action front-loaded. It contains no unnecessary words and is fully concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description covers the basic purpose. However, it omits any caution about destructive behavior or edge cases, making it minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter with no description, and the tool description merely says 'by ID,' adding no extra meaning or constraints. It fails to compensate for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 (Rack Storage Item), and the method (by ID). It distinguishes this tool from siblings like delete_rack_storage or delete_asset, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any prerequisites or consequences. The description is purely functional with no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only the basic action ('Get') without disclosing any behavioral details such as what is returned, potential errors, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. Every word is necessary and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is very brief but lacks important context like return value expectations or any caveats. With no output schema or annotations, the description should at least mention what is returned, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one integer 'id' parameter with zero description coverage. The phrase 'by ID' provides some meaning, clarifying that the id parameter is the identifier of the password, but it does not explain the origin or format of this ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('Password') with a clear qualifier ('by ID'). It distinguishes from sibling tools like list_asset_passwords (which retrieves multiple) and create_asset_password (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While 'by ID' implies use when you know the ID, there is no mention of when to use list_asset_passwords or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description alone must convey behavior; it only states the action without disclosing read-only nature, error responses, or return value format. There is no mention of authentication or side effects, leaving the agent with incomplete information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence, 'Retrieve a password folder by ID,' is appropriately concise and front-loaded, with no redundant words. It conveys the core purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation with no output schema, the description covers the basic action but lacks detail on the return object, error handling, or any special constraints. Given the tool's simplicity, the minimal description is borderline adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description merely restates 'by ID' without adding format, source, or example for the id parameter. It adds little beyond the property name 'id' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and names the exact resource 'password folder' with an ID parameter, making the primary action clear. It distinguishes itself from sibling tools like list_password_folders or get_asset_password by specifying the resource type and retrieval mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided – the description does not state when to use this tool over alternatives like get_folder or list_password_folders, nor does it mention any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the lookup operation. It does not disclose whether the return includes full procedure details, error behavior, or any read-only safety guarantees. Beyond the implied read-only nature of 'Get', there is no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. It is efficiently communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description is minimal but omits information an AI agent would need without annotations or an output schema, such as the structure of the returned Procedure and any prerequisites or error cases. The existence of sibling tools like get_procedure_task suggests a richer context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description 'by ID' clarifies that the single 'id' parameter is the Procedure's identifier, compensating for the 0% schema description coverage. However, it provides no additional details about the ID format or constraints beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with resource 'Procedure' and scope 'by ID', clearly distinguishing it from list_procedures and other procedure-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like list_procedures or get_procedure_task. The description only states the operation, leaving the AI 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only says 'Get a VLAN Zone by ID.' It adds no context about read-only nature, error handling, response shape, pagination, permissions, or any side effects. The verb 'get' implies a read, but the description does not explicitly confirm or elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple getter and immediately conveys the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, this description is minimally sufficient for selection and invocation. However, it does not elaborate on the return object, required existence of the ID, or any exceptional cases. It is adequate but leaves gaps that a more detailed description could fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one integer parameter 'id' with 0% description coverage. The description says 'by ID,' which merely restates the parameter name without explaining what the ID refers to, how to obtain it, format constraints, or any linkage to other resources. It does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a VLAN Zone by ID' uses a specific verb ('Get') and a clear resource ('VLAN Zone'), and the qualifier 'by ID' distinguishes it from list_vlan_zones and other get_* tools. It is unambiguous and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 when to prefer it over get_vlan, list_vlan_zones, or other list/get tools. Usage context is only implied by the name and parameter, which is insufficient for a tool with many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. 'Archive' implies a state change, but there is no mention of whether it is reversible, what the response looks like, or any permissions required. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, so a minimal description might suffice. However, as a mutation-like operation, the lack of behavioral context (e.g., reversibility, effects) leaves the description only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'id' as a required integer, and the description says 'by ID', which confirms the parameter's role. However, with 0% schema_description_coverage, the description should add more detail about what the ID refers to (e.g., password asset ID), though it is somewhat obvious from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive a Password by ID' clearly states the verb (archive), the resource (Password), and the method (by ID), which distinguishes it from sibling tools like delete_asset_password, unarchive_asset_password, and get_asset_password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to alternatives such as delete_asset_password or unarchive_asset_password. The description simply states what it does without explaining the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It states the destructive action but does not disclose whether deletion is permanent, irreversible, or cascades to related data. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately conveys the tool's purpose. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 gives the core functionality. However, it lacks important context such as permanence of the deletion and when to prefer archiving, leaving it slightly incomplete for operational use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'id' parameter. The description's 'by ID' clarifies that the id references the article's identifier, but offers no further detail on format or source. This partially compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'Knowledge Base Article', with the method 'by ID'. It distinguishes this tool from sibling operations like get_article, update_article, archive_article, and unarchive_article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Specifically, it does not explain the difference between hard deletion and archiving (archive_article/unarchive_article exist as siblings), nor any prerequisites or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the operation is a deletion but offers no behavioral context such as whether it is a hard delete, if related data is affected, idempotency, or what happens if the ID 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter delete operation, the description is minimally adequate. It lacks any mention of return value, error handling, or side effects, but the simplicity of the operation and the clarity of the purpose partially compensate. Given no annotations or output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'id' parameter. The description adds that the ID refers to a Flag Type, which gives some semantic context. However, it does not explain the format, range, or how to obtain valid IDs beyond the resource name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 Flag Type), and the identifier (by ID). It is concise and distinguishes from sibling tools like delete_flag, since it specifically says 'Flag Type'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are many delete_* sibling tools, but the description does not mention any prerequisites, edge cases, or reasons to prefer this over delete_flag or other deletes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it states the core action, it does not reveal whether deletion is permanent, whether any cascading effects occur, or whether special permissions are required. The minimal wording omits these critical traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. It is front-loaded and easy to parse, which is appropriate for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required ID parameter, no output schema, no annotations), the description is largely sufficient. However, it does not note potential irreversibility or side effects, leaving a minor gap for an operation that is destructive by nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by ID' without adding detail about the ID's format, meaning beyond the schema, or any constraints. It essentially restates the schema's 'id' parameter, providing no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a network by ID' uses a specific verb ('Delete') and resource ('network'), making the tool's purpose unambiguous. It distinguishes itself from sibling delete tools (e.g., delete_list, delete_asset) by naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like update_network or create_network. There is no mention of prerequisites, limitations, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the operation without mentioning return format, error behavior, permissions, or side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial get-by-ID tool, the description is minimally adequate. However, it lacks information about the return value structure or error handling, and there is no output schema to compensate, leaving some gap for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the ID parameter's role (identifying the folder), adding some semantic context to the bare integer type in the schema. However, it does not elaborate on format or constraints, and the schema description coverage is 0%, so it insufficiently compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 (folder), and the identifier (by ID). It is distinct from sibling tools by explicitly targeting folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other folder-related tools like list_folders or search functionality. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 itself. It does not mention error handling (e.g., what happens if the ID is not found), return format, or any side effects. The description adds little beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 with no wasted words. It is appropriately sized for a simple get tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a minimal get tool with one parameter and no output schema or annotations. The description is sufficient to understand the core operation, but it omits any detail about the return value or behavior on missing IDs. The overall complexity is low, so the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'id' as a required integer, but the description does not provide additional meaning beyond 'by ID'. Given the 0% schema description coverage, the description should compensate by clarifying the parameter's purpose or constraints, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clear resource 'group' and identifies the selection criteria 'by ID'. It clearly distinguishes itself from the sibling tool 'list_groups', which retrieves multiple groups, by implying a single-entity lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the singular resource and 'by ID' phrasing. There is no explicit guidance on when to use this tool versus alternatives like list_groups, nor any exclusions or prerequisites. However, the simple get-by-ID pattern makes the primary use case reasonably evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only indicates the action is retrieval, but does not explain what the response contains (metadata vs file content), authentication requirements, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieve-by-ID tool with one parameter, the description is minimally viable. However, it lacks context about the return value, error conditions, or what an 'upload' refers to, which the agent may need for correct invocation and response handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but there is only one parameter (id). The description adds 'by ID', clarifying that the id identifies the upload. However, it does not specify expected format or any constraints beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'upload', with the qualifier 'by ID' making the scope explicit. It is unambiguous and distinguishes this from other get_* siblings by specifying the upload resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_uploads or delete_upload. The description does not mention prerequisites, exclusions, or context for prefering this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fails to mention whether the operation is read-only, what the return format is, or what happens if the user is not found. The bare 'Get a user by ID' offers no context about side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence: 'Get a user by ID.' It is appropriately sized for the tool's simple functionality and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a complete description would at least mention that it returns a user object and possibly note behavior for nonexistent IDs. The current description omits any return information or edge cases, relying entirely on the tool name for context. There is no output schema to fill this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer 'id' with 0% description coverage. The description merely repeats the concept of 'by ID' without adding meaning such as the ID's purpose, format, or range. It does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a user by ID' clearly states a specific action (get) on a specific resource (user) with a specific method (by ID). This distinguishes it from sibling tools like list_users, which retrieves multiple users, and other getters for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you have a user ID and need the corresponding user record. However, it provides no explicit guidance on alternatives or when not to use it, such as when you need to list all users or fetch a different resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only notes that matching field values are preserved. It does not disclose side effects, auth requirements, return format, or whether the operation is destructive, leaving the agent with limited behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, immediately states the action and key behavior; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse—it omits parameter details, error handling, and post-conditions, making it difficult for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description does not clarify the meaning of id or company_id beyond the parameter names, nor does it explain how the parameters relate to the move operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('Asset to a different Asset Layout'), clearly distinguishing this from update_asset or layout management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (relocating an asset between layouts) but does not explicitly mention alternatives or exclusions, such as using update_asset for field changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action without revealing side effects, permissions, idempotency, or what happens if the company is not currently archived.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low in complexity with one parameter, so the description is mostly adequate. However, the lack of annotations and output schema leaves some ambiguity about effects and prerequisites, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required id parameter of type number. The description adds 'by ID,' which confirms that the parameter is the company identifier, but it does not provide additional details beyond this. Given the single obvious parameter, this minimal clarification is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (unarchive), the resource (company), and the method (by ID). It distinguishes itself from sibling tools like archive_company and update_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or prerequisites. For example, it does not mention that the company must be archived first or that archive_company is the reverse operation. The usage context is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Create or update' and the matching key, but does not disclose behavioral details such as whether updates are partial or full, what happens if no match exists, idempotency, permissions, or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the action and key matching logic; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description is too sparse. It lacks information about creation vs update semantics, return values, error behavior, or permission requirements, which an agent would need for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, so the description needs to compensate. It clarifies that title and company_name serve as the match key, which adds meaning to those required parameters. However, it provides no guidance for the other six parameters (icon, message, image_url, content_link, etc.), leaving the agent to rely on names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (create or update) and the resource (Magic Dash Item) plus the matching criteria (title + company_name). This distinguishes it from sibling tools like list_magic_dash, delete_magic_dash, and update_magic_dash_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (creating/updating a magic dash item identified by title and company_name) but does not explicitly state when to use this versus alternatives, nor does it mention exclusions. Sibling tool names are visible but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action 'archive' without explaining the consequences (e.g., reversible? hidden from lists?), permission requirements, or any side effects. This is a significant transparency gap even for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys all the essential information without redundancy. It is front-loaded with the verb and resource, making it easily scannable and appropriately sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description states the core operation but omits behavioral context that would be useful, such as the reversible nature of archiving or prerequisites. It is minimally viable but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions 'by ID' which clarifies that 'id' is the article identifier, but adds no further meaning about the value format or source. The bare reference to ID is minimal and relies on the parameter name being self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive') and the resource ('a Knowledge Base Article') with the specific scope ('by ID'). It unambiguously distinguishes this from sibling tools like unarchive_article or delete_article by using the specific verb 'archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to archive an article, but provides no explicit guidance on when to choose this over delete_article or unarchive_article. There are no alternatives or exclusions mentioned, leaving the context to be inferred from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fails to mention whether the deletion is permanent, requires special permissions, or has cascading effects, leaving the agent to guess the consequences of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is perfectly front-loaded and communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description omits critical contextual information such as irreversibility, permissions, return value, or side effects. This leaves the agent under-informed about the operation's implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description's mention of 'by ID' clarifies that the 'id' parameter is the flag's identifier, adding meaning beyond the raw integer type. This partial compensation is adequate for the single-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a Flag by ID' uses a specific verb and resource, clearly indicating the action and target. It distinguishes itself from sibling delete tools like 'delete_flag_type' by explicitly naming the resource as a Flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites or context. It simply states the action without explaining when this deletion tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It simply says 'Delete' without disclosing whether deletion is permanent, what happens if no matching item exists, or whether special permissions are needed. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the verb and includes the essential identifying parameters, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description is minimal. It lacks usage guidance relative to the sibling delete_magic_dash_by_id, and does not disclose behavioral side effects. The only strength is purpose clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly names title and company_name as the identifiers for deletion, which adds meaning beyond the bare schema property names. However, with 0% schema coverage, more detail about how these values are used (e.g., exact match, uniqueness) would be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and target (Magic Dash Item) with the specific identifying keys (title and company_name). This distinguishes it from the sibling delete_magic_dash_by_id, which presumably uses an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 title and company_name to identify the item, but it doesn't explicitly contrast with delete_magic_dash_by_id or state when not to use it. No explicit alternatives are mentioned, so the 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.
Behavior2/5
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 merely states 'Delete' without mentioning permanence, irreversibility, required permissions, cascading effects, or response behavior. For a destructive operation, this missing context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the action ('Delete') and resource ('Procedure Task'). There is no verbose or irrelevant content, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is minimally viable: it states the action and target. However, it omits important behavioral nuances (e.g., permanence, side effects) and relies entirely on the schema for parameter meaning, leaving the description just adequate but not enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines 'id' as a required integer. The description adds only 'by ID,' which largely restates the parameter's purpose without providing additional meaning—no format, source, or special considerations. With 0% schema description coverage, the lack of compensation lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a Procedure Task by ID' uses a specific verb ('Delete') and resource ('Procedure Task'), clearly distinguishing it from sibling tools like get_procedure_task, update_procedure_task, and list_procedure_tasks. It also specifies the scope ('by ID'), making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to delete a procedure task) but does not explicitly state when to use it versus alternatives or mention any exclusions. It lacks guidance on prerequisites or when not to use, falling short of clear usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the destructive action ('Delete') but does not mention whether deletion is permanent, cascades to related items, or requires specific permissions. This is minimal transparency, only stating the obvious action without contextual detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It earns its place by stating the action and target immediately, making it appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description is minimally viable. However, it lacks context about success/failure behavior, permanence, or effects on dependent data. For such a basic operation, the description is adequate but not complete enough to fully inform the agent about consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description must compensate. It adds 'by ID', which clarifies that the 'id' parameter is the identifier of the rack storage, but this is nearly self-evident from the schema and tool name. No additional format, constraints, or usage details are provided, so it only marginally fulfills the compensation role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a Rack Storage by ID' uses a specific verb ('Delete') and resource ('Rack Storage'), clearly distinguishing this from sibling tools like get_rack_storage or update_rack_storage. It precisely states the operation and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: use when you need to delete a rack storage. However, no explicit guidance is provided about when not to use it or alternatives (e.g., update_rack_storage for modifications). It meets the 'implied usage' level but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It simply restates the operation without disclosing behavioral traits such as error handling, required permissions, or return format. The description adds no value beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of six words. It is perfectly concise and every word earns its place, especially for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is sufficient for an agent to select and invoke it. The resource 'Asset Layout' is explicit, differentiating it from 'Asset'. However, it lacks any notes about return values or error conditions, which would be helpful but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with zero description coverage. The description says 'by ID', which clarifies that the parameter is the asset layout's identifier. However, it adds no additional semantics beyond the property name, and no format or validation details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'Asset Layout', and the scope 'by ID'. This distinguishes it from sibling tools like list_asset_layouts (plural) and get_asset (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention alternatives, when to use this tool versus list_asset_layouts or get_asset, or any exclusion criteria. Sibling tools exist but no context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 restates the action 'Get' and does not specify return values, error handling, permissions, or side effects. The term 'Get' implies a read-only operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It directly states the essential purpose, making efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one parameter, no nested objects), the absence of an output schema and annotations means the description should explain the return value or at least note that it returns the flag object. It also does not address potential errors or prerequisites. For a read operation, more contextual detail would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'id' parameter with no description (0% coverage). The description clarifies that 'id' refers to the Flag's ID, which adds meaning beyond the schema. However, it does not specify the ID format, required type, or any constraints beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get'), the resource ('Flag'), and the scope ('by ID'), which clearly communicates the tool's purpose. It distinguishes this from sibling getters like get_flag_type and list_flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific flag ID is known, but it does not explicitly mention alternatives (e.g., list_flags for searching) or when not to use this tool. It provides minimal but clear context for straightforward retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'get a single IP address by ID' and does not mention the return format, error handling on non-existent IDs, or any authorization requirements. This is a minimal description for a read operation, but still lacks useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded and easily parsed, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should ideally explain what the response looks like or any side effects. It does neither, and while the tool is simple, the description alone doesn't fully equip an agent to anticipate the result. This creates a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' integer with no description, and schema description coverage is 0%. The description's phrase 'by ID' clarifies that the parameter is the IP address's unique identifier, which adds some meaning beyond the raw schema, but it doesn't elaborate on format or constraints. This is sufficient for a simple ID parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (get) and resource (IP address), and the qualifier 'single' and 'by ID' distinguish it from list/create/update/delete siblings. This is a textbook high-clarity purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a specific IP address when its ID is known, but it does not explicitly mention when to prefer this over list_ip_addresses or other filtering tools. It gives no exclusions or alternatives, falling at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get a specific List by ID', which reveals no behavioral traits beyond the obvious read nature. It does not disclose return format, error behavior, permissions, or any side effects, leaving the agent without essential context for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words or repetition of the tool name. It is front-loaded with the action and resource, making it easy to scan and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required integer parameter, no output schema, no annotations), but the description itself is minimal. It does not specify what the return value contains (e.g., full list object, list items) or handle edge cases. While sufficient for a trivial getter, it leaves some ambiguity about the broader context of what a 'List' is in this API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for the schema's lack of descriptive detail. It only mentions 'by ID', which adds minimal meaning beyond the parameter name and type already in the schema. The description fails to clarify the domain or format of the ID or any related constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific List by ID' clearly states the action (Get), the resource (List), and the scope (specific, by ID). It distinguishes itself from sibling tools like list_lists, create_list, update_list, and delete_list by indicating a targeted retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need a single List identified by its ID, but it does not explicitly state when to use it versus alternatives or mention any exclusions or prerequisites. The usage context is inherent but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Get... by ID,' implying a read operation, but does not disclose behavior such as error responses, required authentication, or return representation. No additional context beyond the operation itself is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that uses all words effectively. It is front-loaded with 'Get' and states the resource and key parameter. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-ID operation with only one parameter, so the description is largely sufficient. However, the absence of an output schema means the description could clarify return value expectations or error scenarios, though these are likely obvious for this CRUD pattern. Overall, it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the single 'id' parameter to the concept of a rack storage ID, which the schema does not explain. Even with 0% schema description coverage, this minimal addition adequately compensates for a single integer parameter, though it does not provide details like where to find the ID or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a Rack Storage by ID' clearly states the operation (get), resource (rack storage), and lookup method (by ID), distinguishing it from list_rack_storages. However, it does not explicitly differentiate from get_rack_storage_item, leaving some potential for confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a known ID to retrieve a single rack storage, but it provides no explicit guidance on when to use it vs alternatives like list_rack_storages or get_rack_storage_item. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It clearly states the tool returns a redirect URL, which implies a read-only navigation action. However, it does not disclose any potential side effects, authentication requirements, or behavior in error cases, though the operation appears straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action ('Get a redirect URL') and adds a concise qualifier ('matched by integration details'). There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description only provides a high-level purpose and does not explain return format, parameter interactions, prerequisites, or edge cases. Given the moderate complexity, this is insufficient for an agent to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds only the high-level context that parameters are 'integration details' used for matching, but does not explain the relationship or distinction between integration_id and integration_identifier, leaving the schema descriptions to do the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'redirect URL' with the purpose of jumping to an asset/record matched by integration details. It is specific about the outcome but does not explicitly distinguish itself from sibling tool 'jump_to_company'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have integration details and need a redirect URL, but it provides no explicit guidance on when to use this tool over alternatives like 'jump_to_company' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the return value (a redirect URL) but does not explicitly confirm whether it is a read-only operation, mention any side effects, or describe error behavior. The 'Get' wording implies safety, but it is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 result. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema, no annotations). The description adequately explains the purpose and return value for this complexity, though it could be more complete by addressing usage context and potential edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since the single parameter has a description. The tool description says 'integration details' instead of the exact parameter name, which is vaguer than the schema. It 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a redirect URL to jump directly to a company, with a specific verb ('Get') and resource ('redirect URL'). It implicitly distinguishes from sibling tools like jump_to_card by focusing on 'company', but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention any prerequisites, exclusions, or compare with sibling tools such as get_company or jump_to_card.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only states the action without disclosing prerequisites (e.g., article must be archived), side effects, or response behavior. Minimal disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and no output schema, so the description should compensate by explaining return values or edge cases. It only covers the basic action, leaving important contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'by ID' to clarify the id parameter, but does not go beyond that. Schema coverage is 0%, yet the single 'id' parameter is self-explanatory, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unarchive') and the resource ('Knowledge Base Article') with the identifier method ('by ID'). This distinguishes it from sibling tools like archive_article and unarchive_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need to unarchive a Knowledge Base Article. However, there are no explicit alternatives, prerequisites, or exclusions, so the guidance is basic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Unarchive a Password by ID' and does not describe the effect on the password, reversibility, permissions, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and immediately communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is minimal. It does not explain the state change (e.g., making the password appear in regular lists again) or any side effects, which limits the agent's understanding of what actually happens.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'id' parameter (0% coverage). The description's phrase 'by ID' clarifies that the id refers to a password ID, providing minimal compensation, but it lacks detail on how the id is used or where it comes from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (unarchive), the resource (a Password), and the scope (by ID). It clearly distinguishes from sibling tools like archive_asset_password, delete_asset_password, and get_asset_password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is self-evident, but the description provides no explicit guidance on when to use this tool versus alternatives, no preconditions, and no mention of when not to use it. The usage is implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says the tool deletes the matcher, but does not disclose whether deletion is permanent, requires special permissions, or impacts related data. For a destructive operation, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly conveys the action and target. It is concise and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 is minimal but does not address the permanence or side effects of deletion. With no annotations and no output schema, a more complete description should at least warn about the destructive nature or note that the action is irreversible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single integer 'id' with no description, and schema coverage is 0%. The phrase 'by ID' clarifies that the parameter identifies which matcher to delete, adding minimal meaning. However, it does not provide format constraints or additional context beyond the schema, so compensation is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with a clear resource ('integration matcher') and states deletion occurs by ID. This clearly distinguishes it from sibling tools like update_matcher and list_matchers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for removing a matcher, but it does not explicitly state when to use it versus alternatives or mention any prerequisites or consequences. The resource is named, so the intent is clear, but no explicit usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavior disclosure. The description only states 'Delete a Relation by ID' and does not reveal whether the deletion is permanent, whether any permissions are required, whether there are cascading effects, or what the response will be. For a mutation tool, this is a significant lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that delivers the essential information with no filler. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too minimal to be contextually complete. It lacks behavioral details such as irreversibility, permission requirements, or side effects. For a delete operation, this is a clear gap that could lead to incorrect use or unexpected consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer parameter, 'id', with 0% description coverage. The description's 'by ID' adds only a minimal confirmation that the parameter is the identifier of the relation, which is already implied by the parameter name. It does not explain how to find or validate the ID, nor any constraints, so it fails to compensate for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a Relation by ID.' It specifies the verb (delete), the resource (Relation), and the identifier (ID), which distinguishes it from sibling tools like list_relations or create_relation. This is a concise, unambiguous statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description does not explicitly mention when to use this tool versus alternatives, the purpose is self-evident from the name and description. Since there is no alternative delete_relation tool among siblings, the context is clear. However, it does not provide explicit exclusions or prerequisites (e.g., the relation must exist), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the basic action. It does not mention whether deletion is permanent, irreversible, cascades to associated resources, or requires special permissions. The destructive nature is implied but no additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise, and front-loaded with the action. No extraneous words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is minimally adequate. It covers the purpose and parameter, but lacks information on return values, error conditions, or the permanent nature of the deletion. A more complete description would mention these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one integer 'id' with no description and 0% coverage, so the description must compensate. The phrase 'by ID' clarifies that the parameter is the VLAN identifier, adding minimal meaning beyond the raw schema. It is sufficient but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('VLAN'), and the identifier ('by ID'). It unambiguously distinguishes this from sibling tools like create_vlan, update_vlan, or get_vlan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb and resource: delete a VLAN. However, there is no explicit guidance on when not to use it, prerequisites (e.g., VLAN must exist), or alternatives. It meets the minimum but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Delete' without mentioning irreversibility, cascading effects, or required permissions. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information. There is no wasted text or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description is technically adequate but minimally complete. The absence of annotations and lack of behavioral details (e.g., permanence, side effects) leave the agent without important context. It meets the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'id' as an integer, and the description adds that it is the ID of the VLAN Zone being deleted. This adds some meaning beyond the raw schema, but does not explain how to obtain the ID or any constraints. With 0% schema coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Delete'), the resource ('a VLAN Zone'), and the method ('by ID'). This clearly distinguishes it from siblings like get_vlan_zone, update_vlan_zone, and list_vlan_zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the verb 'Delete' and the resource name, but there is no explicit guidance on when to choose this over alternatives (e.g., update_vlan_zone) or any exclusions/preconditions. It's minimally viable but lacks clear 'use when' or 'when not' language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. 'Get' implies a read-only operation with no side effects, but the description adds no further detail such as error handling, required permissions, or what happens if the ID does not exist. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of seven words, front-loaded with the key information: 'Get a Procedure Task by ID.' There is no wasted wording, and it is immediately scannable and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 state what the return value looks like or whether an error is raised on a missing record. Without annotations or an output schema, this leaves some ambiguity for an agent, but the minimal purpose is still clear. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, id, with no description. The tool description reinforces by saying 'by ID' but does not explain the nature of the ID beyond that. Since the parameter is self-explanatory and the description links it to the retrieval action, it is adequate but does not compensate significantly for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a Procedure Task by ID' clearly identifies the action (get), the resource (Procedure Task), and the method (by ID). It distinguishes this from sibling tools like get_procedure (which calls on a procedure, not a task) and list_procedure_tasks (which lists, not fetches a single task by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that this tool is for fetching a single task by ID while list_procedure_tasks is for listing all tasks, nor does it provide any context or exclusions. The agent must infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It only says 'Retrieve a list' without disclosing pagination, archived asset handling, search behavior, or what happens with 11 parameters. No mention of output format or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It immediately states the action and scope, making it concise and appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no annotations, and no output schema, the description is too sparse. It does not explain pagination, filtering capabilities beyond company, or how it differs from list_company_assets, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies the company_id parameter via 'filtered by company.' The other 10 parameters (page, page_size, search, archived, slug, etc.) receive no semantic explanation in the description, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('assets'), and explicitly states scope ('across all companies or filtered by company'). This distinguishes it from siblings like list_company_assets by clarifying the all-company option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to list assets with an optional company filter. However, it does not explicitly name alternatives or provide when-not-to-use guidance, such as pointing to list_company_assets for single-company listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It discloses that the tool retrieves expirations (read-only implied) and lists example types, but does not mention pagination, archived filtering, or other behavioral details that the parameters suggest (e.g., page, archived).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 states the tool's purpose and provides supporting examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too sparse. It lacks information about response format, pagination behavior, filtering capabilities, or how parameters interact, leaving significant gaps for an 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 14% (1 of 7 params described). The description adds meaning for expiration_type by listing examples, but does not explain page, archived, page_size, company_id, resource_id, or resource_type. Given the low coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' with the resource 'expirations' and clearly scopes to 'the account'. It lists example types (domains, SSL certs, warranties, asset fields) which distinguishes it from sibling tools like update_expiration and delete_expiration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs expiration data but does not explicitly say when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 core action and does not mention return format, pagination, ordering, scope limitations, or any side effects. While it is not misleading, it adds minimal behavioral context beyond the obvious read-only nature of listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function. There is no fluff, and the key information is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is minimally viable. However, it does not explain what the returned list contains (e.g., file upload objects) or whether 'all' means across the entire system or a filtered context. This lack of detail leaves some ambiguity, but the tool's simplicity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and there is nothing to document. The baseline of 4 applies because the description does not need to compensate for missing parameter information. The description adds no parameter semantics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get a list') and the resource ('file uploads'), and the word 'all' specifies the scope. It naturally distinguishes itself from sibling tools like 'get_upload' (which fetches a single upload) and 'delete_upload' (which removes an upload).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 exclusions, prerequisites, or use cases, leaving the agent without explicit context beyond the name. For instance, it does not explain how it differs from 'list_assets' or when to prefer it over 'get_upload'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavioral traits. It only mentions the requirement to include field id for existing fields, but does not explain critical behaviors such as whether the entire fields array is replaced, whether omitted parameters are left unchanged, or any side effects. The agent is left guessing about the update semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no filler. The first sentence states the core purpose, and the second provides a practical instruction about field updates. Every word earns its place, making it highly concise while still conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and no output schema, the description is woefully incomplete. It lacks context on how the fields array behaves (add, remove, replace?), whether updates are partial or full, and any prerequisites or consequences. An agent would need substantial inference to use this tool correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only mentions 'fields' and 'field id', leaving the other 9 parameters (icon, name, color, active, icon_color, include_files, etc.) unexplained. The parameter names are somewhat self-explanatory, but the description adds minimal semantic value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: updating an Asset Layout including its fields. The verb 'update' and resource 'Asset Layout' are specific and unambiguous. It distinguishes itself from sibling tools like 'create_asset_layout' and 'move_asset_layout' through the explicit use of 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear, specific instruction for updating existing fields: 'Include field id to update existing fields.' This gives actionable guidance on handling fields within the update, which goes beyond a generic update description. However, it does not explicitly mention when to use this over alternatives like create_asset_layout, though the context of an update operation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'update' without explaining side effects, permissions, reversibility, or what 'archived' actually means (e.g., hiding the expiration from lists). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the action. Every word is meaningful, no redundancy, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter update with no output schema and no annotations, the description covers the core action but lacks behavioral details and usage guidance. It is minimally viable but has clear gaps in transparency and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies 'archived status' as the focus, clarifying the 'archived' parameter, but does not explain the 'id' parameter or the meaning of true/false values. Adds some value but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an expiration's archived status, which is a specific verb+resource+scope. It distinguishes from sibling tools like list_expirations and delete_expiration by specifying the exact field being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: one would use this tool to archive or unarchive an expiration. However, there is no explicit guidance on when to use it versus alternatives like delete_expiration, nor any context about when archiving is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It reveals that the tool can update existing items and remove items via a _destroy flag, which goes beyond the simple 'Update' in the name. However, it omits potential side effects, permission requirements, or what happens if id is omitted for items. It's a minimally transparent description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: 'Update a List. Include item id to update existing items; set _destroy: true to remove items.' Every word earns its place, and the most important verb ('Update') is front-loaded. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with only 3 parameters, the description covers the core behaviors: renaming a list and managing its items via id and _destroy. However, it doesn't fully explain the structure of list_items_attributes (e.g., whether omitting id creates new items, or if _destroy requires an id) or any prerequisites. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of list_items_attributes by describing the use of item id and _destroy, which adds value beyond the raw schema. However, it does not clarify the 'name' parameter's purpose (likely the list name), leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update a List', which is a clear verb-resource pairing. It also mentions item-specific operations, distinguishing it from create_list and delete_list siblings. However, it doesn't explicitly contrast with alternatives, so it just misses a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct guidance on how to handle list items: include item id for updates and set _destroy: true for removal. This implies the tool is used for partial updates, but it doesn't state when to prefer update_list over create_list or delete_list. There are no explicit exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It states the action (updating positions) but omits important behavioral details such as whether all positions are overwritten, how unlisted items are handled, idempotency, or any side effects. The mutation nature is implied but not deeply disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy or filler. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the schema covers inputs well, but with no output schema and no annotations, the description does not clarify return values or provide caveats about the reordering behavior. It is adequate for basic invocation but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 company_id and positions in detail. The description adds minimal context ('multiple' and 'for a company') but does not enhance understanding of the parameter structure beyond what the schema already provides, which 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Reorder' and clearly identifies the resource (Magic Dash Items) and scope (for a company). It distinguishes itself from sibling tools like upsert and delete by focusing on position updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (reordering positions) but does not explicitly state when to use this tool versus alternatives like upsert_magic_dash or delete_magic_dash, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly says 'permanently delete,' which implies irreversibility, but it does not mention error behavior, permissions, or side effects on related resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no waste. It front-loads 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.
Completeness4/5
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 covers the essential context: what is deleted and by which identifier. It lacks explicit details on failure outcomes, but 'permanently' conveys the irreversible nature, making it adequate for this simple delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter, and the description mentions 'by ID,' which clarifies that the ID identifies the expiration. However, it adds minimal meaning beyond the schema and tool name, providing no constraints or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('delete'), resource ('expiration'), and method ('by ID'). It clearly distinguishes from sibling tools like update_expiration and list_expirations by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 only states what it does, with no mention of exclusions or alternate tools for partial deletion or archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the core action (upload and attach) and the local file requirement, but does not disclose side effects such as whether the record can have multiple public photos, whether the operation replaces existing photos, permission requirements, or what the return value is. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and the key input requirement. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 fully described parameters, no nested objects, no output schema), the description covers the essential 'what' and 'how', but lacks information about the outcome of the operation (e.g., return value, confirmation) and any edge cases like handling duplicate attachments. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description adds minimal semantic value: it reiterates the need for a local file path and the attach behavior, but does not provide additional syntax, formatting, or relationship details beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload'), the resource ('a new public photo'), and the key additional behavior ('attach it to a record'). This specific verb+resource+scope distinguishes it from sibling tools like 'create_photo' (which may not attach) or 'update_public_photo' (which updates an existing photo).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you want to upload a new public photo and associate it with a specific record. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear for an agent to decide. A more explicit comparison to 'create_photo' would elevate to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get a single network by ID', which adds no behavioral detail beyond the function name. It doesn't mention read-only nature, potential errors, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear, front-loaded sentence with no extra words. It is appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is mostly complete but doesn't describe return values or error behavior. It's adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'id' is the network's ID, but this is minimally helpful since the schema already names the parameter 'id'. The description adds just enough to confirm the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a specific resource 'a single network' and the scope 'by ID', which clearly distinguishes it from sibling tools like list_networks and create_network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a network ID and need one specific network, which is clear context. However, it doesn't explicitly mention alternatives or when not to use it, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must reveal behavioral context. It only states the operation, not details like error handling, required permissions, or the shape of the returned article. This is a minimal transparency disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. It is concise and directly states the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, no nested objects—the description covers the essential purpose. It doesn't elaborate on return format, but the lack of an output schema reduces the need for that detail. However, a brief note about possible 'not found' behavior would have improved completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer 'id' with no description. The description mentions 'by ID', which provides the meaning of the parameter and connects it to the operation. Since there is only one simple parameter, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 as 'Knowledge Base Article' and the access path 'by ID'. This clearly differentiates it from sibling tools like list_articles, create_article, and update_article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single article when the ID is known, but it does not explicitly mention when to prefer this over list_articles or provide exclusion criteria. The context is implied by the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' indicates a read-only operation, which is the primary behavioral trait. However, with no annotations provided, the description does not disclose potential error behavior, permissions, or the format of the response, leaving some transparency burden unmet for a tool with no 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.
Conciseness5/5
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. It contains no superfluous words and communicates the essential purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one required parameter, no output schema, and no annotations—the description is sufficiently complete for an agent to understand its basic purpose. It could optionally mention the return value, but the low complexity makes the current description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'by ID', which gives semantic meaning to the required 'id' parameter beyond the schema's simple integer type. However, with 0% schema description coverage, the description only minimally compensates by confirming the parameter's role, without explaining the ID's source or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with the resource 'VLAN' and scope 'by ID', clearly distinguishing it from sibling tools such as list_vlans or create_vlan. It unambiguously states that it fetches a single VLAN based on its identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the tool should be used when a specific VLAN identifier is known, but it does not explicitly mention alternatives like list_vlans or provide when-not-to-use guidance. The usage context is implied rather than clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying safety and behavior. 'Get' implies a read-only operation, and the time window is a useful behavioral detail. However, it does not explicitly confirm read-only status or describe the output format/contents, which is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the verb and resource. No fluff or redundancy. It earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool with no output schema, the description is mostly complete: it tells what it returns (exports) and the time frame (last 24 hours). It could be more explicit about the return format, but the simplicity of the tool makes this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100% coverage). The baseline for 0 params is 4. The description adds no parameter-specific meaning because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 resource ('exports'), and adds a specific scope ('from the last 24 hours'). This distinguishes it from sibling tools like get_export (single export) and create_export (creating exports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. There is no mention of alternatives such as get_export or create_export, nor any exclusions. The description only states the basic function 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.
Behavior2/5
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 'Get a list', implying a read-only operation, but it does not disclose any additional behavioral traits such as pagination, default ordering, authentication requirements, or whether the result is limited to selectable lists beyond the described intent. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded, direct, and contains no unnecessary words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a complete parameter schema and no output schema, the description adequately conveys the purpose and scope. It does not mention response format or pagination, but those are not critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'name' and 'query' have clear descriptions. The tool description adds little over the schema, but since the schema is complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (get a list) and the specific resource (selectable Lists used in asset fields). It distinguishes itself from sibling tools like get_list, create_list, and update_list by focusing on the 'list' operation and the 'selectable for asset fields' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear context: use this when you need the selectable Lists for asset fields. It does not explicitly mention alternatives or when not to use it, but the context is sufficiently specific to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The verb 'Get' indicates a read-only operation, but it does not disclose error behaviors (e.g., 404 for unknown ID), permission requirements, or return format. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with every word earning its place. It is front-loaded with the action and resource, and there is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema, no annotations). The description covers the core function and parameter, but leaves out response details, error scenarios, and any special behavioral context. For a simple getter, this is minimally viable but not a fully rich description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does by explicitly stating 'by ID', which clarifies that the 'id' parameter is the unique identifier of the Flag Type. This adds meaning beyond the raw schema, though it doesn't explain values or edge cases. For a single-parameter tool, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific Flag Type by ID' clearly states the verb (Get), the resource (Flag Type), and the scope (by ID). It distinguishes this tool from siblings like list_flag_types (for listing) and get_flag (a different resource). This is a precise and specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or when-not-to-use guidance. The phrase 'specific... by ID' implies use when the agent has one known ID and needs that Flag Type's data, but it does not contrast with alternatives like list_flag_types or explain prerequisites. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It reveals that setting download=true returns a download URL, which is useful. However, it doesn't disclose response format, authentication, or any side effects, leaving gaps for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose, and the secondary behavior in one clause. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with only two params and no output schema, the description provides the core purpose and download behavior, but doesn't specify the default return format (e.g., photo metadata vs. binary data). For a get operation, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies 'download' as a switch for returning a download URL and contextually identifies 'id' as the photo identifier. Still, it lacks details on default response or parameter constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a specific Photo by ID' with a clear verb and resource, distinguishing it from list_photos and photo mutation tools. It also explains the download parameter's effect, adding scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when you have a photo ID and need its details or download URL. It doesn't explicitly exclude alternatives like get_public_photo, but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation (get), implying non-destructive behavior, but it does not disclose return format, error handling, or permissions. For a simple get-by-ID, the transparency is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is concise and front-loaded, immediately stating the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a very simple tool with one required parameter, no output schema, and no annotations. The description plus the schema provide enough to invoke the tool correctly. It lacks detail about the response, but for a low-complexity get operation, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'by ID' but adds no meaning beyond the schema, which already defines the 'id' integer parameter. With schema description coverage at 0%, the description barely compensates by naming the parameter's role, but it offers no extra semantic detail like format, examples, or what the ID refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a Rack Storage Item by ID' uses a specific verb ('Get'), identifies the resource ('Rack Storage Item'), and specifies the retrieval method ('by ID'). It clearly distinguishes from sibling tools like list/create/update/delete operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' makes the usage context clear: this tool is for retrieving a single item when you have its ID. It doesn't explicitly mention alternatives, but the simplicity of the operation and the naming convention imply when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' conveys a read-only operation, but the description does not disclose potential error behavior (e.g., 404 when not found), authentication requirements, or whether nested asset details are included. It is adequate but sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of eight words with no filler. Every word contributes meaning, and it is immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter getter with no output schema, the description covers the essential contract (what it retrieves and by what keys). It does not explain return format or edge cases, but these are less critical given the tool's minimal complexity and the explicit 'Get a single Asset' wording.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the description names both parameters and their purpose ('by company_id and asset id'), directly conveying that they are identifiers. This adds meaning beyond the bare type definitions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('Asset') with clear scoping ('single') and identifies the exact lookup keys (company_id and asset id). This clearly distinguishes it from sibling tools like list_assets, create_asset, update_asset, and get_asset_password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a direct single-record retrieval tool, and the sibling set includes list_assets and list_company_assets for broader queries. However, it does not explicitly state when to prefer this over list tools or mention any exclusions, leaving the guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly indicates a read operation but does not disclose behavior for missing IDs, auth requirements, or response format. For a simple get-by-ID tool, the transparency is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, immediately front-loading the action and resource. Every word is necessary and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description is sufficient. It states what is retrieved and how to identify it. It could mention return value or error behavior, but these are not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the parameter. 'by ID' confirms that the 'id' parameter is the company identifier, but adds no further detail beyond the schema's type. It is adequate for a single self-explanatory parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('company') with the method ('by ID'), clearly distinguishing it from list_companies and other sibling tools. It is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single company when the ID is known. While it does not explicitly mention list_companies as an alternative for listing all companies, the 'specific company by ID' phrasing provides clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 behavior of the `download` parameter (returns a download URL) but does not state whether the operation is read-only, what the default response looks like, or any potential side effects. Since it is a 'get' operation, the risk is low, but the description could add more context about the response content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main purpose. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with no output schema, the description is mostly complete. It tells the caller how to get a download URL, which is a key distinction. It could mention the default response (e.g., photo metadata) to be fully complete, but the tool's simplicity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains the `download` parameter with 'Set download=true to get a download URL'. The `id` parameter is self-explanatory from the tool purpose and name, so no further explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a public photo by ID', which is specific with a verb and resource. It differentiates from the sibling 'get_photo' by specifying 'public'. The additional detail about the `download` parameter also clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this for public photos by ID. The instruction 'Set download=true to get a download URL' provides a specific use case. However, it does not explicitly exclude using other tools like 'get_photo' for non-public photos, so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. The verb 'Retrieve' clearly signals a non-destructive read operation, and there are no apparent side effects to disclose. It does not explicitly label itself as read-only, but the semantics are unambiguous for a zero-parameter info endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the tool's purpose efficiently, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately specifies what will be returned (version and date). The only minor ambiguity is the exact nature of 'date,' but this is not significant enough to lower the score given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema coverage is trivially 100%. The description adds no parameter details because none are needed; this aligns with the baseline for 0-parameter tools where no additional semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource: Hudu instance version and date. It is distinct from all sibling tools, which focus on specific entities like assets, companies, flags, etc., so there is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool or alternatives. Its use is implied—one would call it when needing version or date information—but there is no stated context, exclusions, or mention of alternative tools. Given the unique purpose, this is acceptable but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hudu-mcp MCP server](https://glama.ai/mcp/servers/Allied-Business-Solutions/hudu-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Allied-Business-Solutions/hudu-mcp)

Score Badge

Copy to your README.md:

[![hudu-mcp MCP server](https://glama.ai/mcp/servers/Allied-Business-Solutions/hudu-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Allied-Business-Solutions/hudu-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Allied-Business-Solutions/hudu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server