Mediagraph MCP

Official

by mediagraph-io

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.7.2
Disambiguation2/5
With 276 tools, many have overlapping or subtly different purposes (e.g., list_shares vs list_share_links, ignore_asset_unidentified_faces vs ignore_asset_face_toggle, get_recent_tag_events vs get_tag_events), making misselection likely. The detailed descriptions help, but the sheer volume and near-duplicate operations create significant ambiguity.
Naming Consistency4/5
The overwhelming majority follow a consistent verb_noun snake_case pattern (list_*, get_*, create_*, update_*, delete_*), which is predictable and readable. Minor deviations like whoami, reauthorize, can_upload, and explain_asset_search are few and do not undermine the overall pattern.
Tool Count1/5
276 tools is an extreme number for any MCP server, far exceeding the 50+ threshold. Even for a comprehensive DAM system, this is an unwieldy and poorly scoped tool surface that would overwhelm agents and require excessive context.
Completeness3/5
Many domains have solid CRUD coverage (assets, collections, lightboxes, tags, workflows, comments, webhooks), but notable gaps exist: storage folders have no update/delete, rights packages have no update/delete, crop presets lack update/delete, invites have no delete/revoke, and meta imports/ingestions are read-only. Workflow steps also lack a reject action, and notifications have no mark-as-read.
Average 3.3/5 across 276 of 276 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on June 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
With no annotations available, the description carries full responsibility for disclosing behavioral traits. It only states 'Submit an access request' and gives no information about side effects, required permissions, state changes, notifications, or other consequences of the 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 short (four words) but under-specified rather than genuinely concise. It omits essential semantic information and simply echoes the tool name, failing to contribute meaningful 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?
The tool has only one parameter and no output schema, but it belongs to a large family of access request tools. The description fails to explain the tool's role in the access request lifecycle, its relationship to create_access_request, or what 'submit' means in this context, making it inadequate.
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 description coverage is 100%, with the only parameter 'id' described as 'ID of the resource', so the baseline is 3. However, the description adds no additional meaning beyond the schema, leaving ambiguity about whether this is an access request ID or a resource ID.
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 'Submit an access request' is a verbatim restatement of the tool name. It does not specify what 'submit' entails, what type of resource is involved, or how it differs from sibling tools like create_access_request or finalize_access_request.
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 usage guidance is provided. There is no indication of when to use this tool over alternatives such as create_access_request, update_access_request, or agree_to_access_request, all of which appear in the sibling list.
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 'Create a new storage folder' and does not mention side effects, requiring permissions, what happens on duplicate names, or how the folder integrates with the folder tree.
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 appropriate conciseness. It provides no value beyond the tool name itself.
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 3 parameters, no annotations, and no output schema, the description is severely incomplete. It lacks any explanation of parameter usage, return value, or creation context, leaving the agent with insufficient 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 mention any of the three parameters (name, parent_id, description). The meaning of 'parent_id' and how 'description' is used are entirely undocumented.
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 storage folder' is a direct restatement of the tool name 'create_storage_folder' and provides no additional information. It does not distinguish this tool from sibling create tools like create_collection or create_lightbox.
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, prerequisites, or alternatives. The description simply states the action without any context about hierarchy, permissions, or when to choose this over other folder-related 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 must disclose behavioral traits such as whether updates are partial, what happens to omitted fields, or any required permissions. The description states nothing beyond the action, leaving the agent entirely uninformed.
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 concise. It omits essential details, making it minimally useful beyond the tool's 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 the lack of annotations, output schema, and minimal schema descriptions, the description does not provide enough context for the agent to correctly invoke the tool. It is completely inadequate for distinguishing the operation in a large API surface.
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 33%, with only the id parameter having a generic description. The tool description fails to explain the meaning or constraints of the name and description parameters, providing no compensation for the schema's gaps.
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 collection" is a direct restatement of the tool name, adding no additional specificity. It does not distinguish this update operation from sibling tools like update_asset or update_lightbox.
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 alternative update operations. The description provides no context for prerequisites, scope, or distinctions among the many 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 provided, the description carries full responsibility for behavioral disclosure. 'Update a membership' reveals nothing about whether the operation is destructive, what fields are changed, permission requirements, or side effects. It is completely lacking in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and not verbose, but it is under-specified to the point of being a restatement of the tool name. It does not offer any valuable information that would justify its existence as a standalone 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?
Despite having only two parameters and no output schema, the tool still requires basic operational context such as what fields can be modified, what the role values signify, and whether the update is partial or full. The description is wholly incomplete even for a minimal update operation.
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 declares id (required) and role (enum), but the role parameter has no description, and the enum values alone provide limited meaning. The description adds no explanation of how role affects membership or what other fields might be updated. With schema coverage at 50%, the description fails to compensate for the gap.
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 membership' is a tautological restatement of the tool name. It does not specify what aspects of the membership can be updated (e.g., role), nor does it differentiate from sibling tools like update_membership_status which also update membership-related attributes.
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 context for when to use this tool versus alternatives. It does not mention any prerequisites, typical use cases, or exclusions. Sibling tools like update_membership_status exist, but the description gives no guidance on choosing between them.
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?
The description implies a mutation (update) but does not disclose any behavioral traits such as field semantics, idempotency, permissions, or effects on dependent resources. With no annotations to lean on, this lack of disclosure 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 extremely concise to the point of being under-specifying. While brevity is good, this one-sentence description fails to provide the minimum information needed for correct tool usage, so it cannot be considered 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?
The tool has 4 parameters, no annotations, and no output schema, yet the description provides no context about what updating a workflow entails, return values, or constraints. This is completely 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 coverage is only 25% (only id has a description). The tool description does not mention any of the updatable fields (name, enabled, description) or their meanings. The description adds no value beyond the schema, which is already sparse.
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 workflow.' is a near-verbatim restatement of the tool name 'update_workflow'. It communicates the basic action but adds no specificity about the resource type, fields, or distinguishing characteristics from related tools like create_workflow or delete_workflow. This is tautological rather than genuinely clarifying.
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 provided. The description does not mention when to use this tool, prerequisites, or alternatives. With sibling tools like create_workflow, list_workflows, and update_workflow_step, the agent receives no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get popular assets' and reveals nothing about side effects, ordering, pagination behavior, authentication requirements, or what constitutes 'popular.' This is a significant transparency gap for any 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 phrase, but this is under-specification rather than concision. It saves words by providing almost no information, so it does not meet the requirement that every sentence earn its place with useful 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 the minimal description, no annotations, and no output schema, the tool is severely under-specified. The meaning of 'popular' is undefined, pagination behavior is left entirely to the schema, and there is no clarity on returned data structure or relationship to other asset tools. This is inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both 'page' and 'per_page' have descriptions. The description itself adds no additional meaning beyond the schema, but baseline for high coverage is 3, so this score reflects that the schema carries the weight.
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 popular assets' is essentially a restatement of the tool name itself, providing no additional specificity about what 'popular' means or how this tool differs from the many sibling tools like search_assets or get_asset. It is a tautology rather than a meaningful purpose statement.
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 doesn't mention criteria like trending, most viewed, or any other definition of popularity, nor does it exclude other asset-listing tools. There is no context for when this would be the appropriate choice.
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 behaviors like pagination, return structure, and scope. It only states 'List share links,' providing zero behavioral information about what the operation does beyond the literal words.
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 that simply restates the tool name. While short, it under-specifies and fails to provide useful information, meaning the sentence does not earn 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?
This is a list operation with no output schema or annotations, yet the description does not explain what a share link is, how pagination works, or how it differs from similar tools like 'list_shares'. The minimal description leaves crucial gaps for an agent.
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 provides descriptions for all three parameters ('q', 'page', 'per_page'), achieving 100% schema description coverage. The description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List share links' is a direct restatement of the tool name, making it a tautology. It does not clarify what constitutes a share link or distinguish this from the sibling tool 'list_shares'.
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 instead of other listing tools like 'list_shares' or 'list_access_requests'. No context is provided about use cases or alternatives.
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 full burden for behavioral disclosure. It only restates the name and fails to mention pagination, return format, sorting, scope, or any side effects. This is effectively a tautology with zero added 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but not appropriately sized because it is under-specified, not concise. A single word-for-word restatement of the name does not communicate any useful information, so it fails to earn 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 no output schema and no annotations, the description should explain what the tool returns and any pagination or filtering context. It provides none of this, making it incomplete for even a simple list 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?
Schema description coverage is 100% for the two parameters (page, per_page) with descriptions like 'Page number' and 'Results per page (max 100)'. The tool description adds no further parameter meaning, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List workflows' is a verbatim restatement of the tool name 'list_workflows', providing no additional specificity about scope, filtering, or output. It does not differentiate from siblings like 'list_workflow_steps' or 'get_workflow'.
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 'get_workflow' for a single workflow or 'list_workflow_steps' for steps. There is no mention of pagination behavior or typical use cases.
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 full responsibility for disclosing behavior. It only states the action without any details on side effects, required permissions, reversibility, or return format. This is a significant gap for a tool with no other 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but under-specified. It is not a matter of efficient wording; it misses critical information about the tool's operation. This is under-specification rather than conciseness, so a lower score is 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 absence of annotations, output schema, and rich parameter descriptions, the description is extremely incomplete. It does not explain what a crop preset is, the units of width/height, or any constraints. It fails to provide the minimal context needed 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 0% description coverage, and the description does not explain any parameter meaning. The schema lists name, width, and height, but the description adds no value beyond the field names. The tool description fails to 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.
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 (crop preset), which is specific enough to know what the tool does. However, it does not distinguish itself from sibling tools like create_rename_preset, which are also create operations for presets, so it lacks 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context for crop presets, or exclusions. The description simply repeats the tool name without offering any decision-making support.
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 explaining behavioral traits. It only restates the action without disclosing side effects, permissions, idempotency, or what happens on creation. This offers no behavioral transparency 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but this is under-specification rather than conciseness. It provides no structure or additional information, and the brevity doesn't serve 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?
Given the tool has 9 parameters, no annotations, and no output schema, the description is completely inadequate. It fails to explain return values, validation rules, or the purpose of the field 'type', making it impossible to use correctly without external knowledge.
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 0%, and the description does not mention any parameters or their meanings. It fails to compensate for the lack of schema documentation, leaving the agent to guess which of the 9 parameters are essential or how they relate to each other.
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 a custom metadata field' with a specific verb and resource. It distinguishes itself from sibling tools like list_custom_meta_fields and get_custom_meta_field by indicating creation, though it doesn't clarify the context (e.g., asset metadata) or why one would create a field.
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 doesn't mention relevant prerequisites (e.g., existing taxonomies or metadata schemas) or contrast with set_asset_custom_meta, which applies values to assets. The usage context is completely 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Update' which implies mutation, but does not explain side effects, whether partial updates are supported, required permissions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, but this is under-specification rather than effective conciseness. It has no structure or additional sentences that could provide context; it is brief but not useful.
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 (13 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain what metadata fields are involved, what response the agent can expect, or any constraints. The description is nowhere near sufficient 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 only 8%, with only the 'id' parameter having a generic description ('ID of the resource'). The description itself adds no parameter semantics whatsoever, not even hinting at the types of metadata fields (city, title, etc.) that are updatable. It utterly fails to compensate for the sparse schema descriptions.
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 asset metadata' identifies a clear verb and resource, but 'metadata' is very broad and does not distinguish this tool from more specific siblings like update_asset_description or set_asset_custom_meta. It is not a tautology, but it lacks specificity about what aspects of metadata are 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or mention related tools, leaving the agent to guess which of the many asset-related update tools is 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?
The description is a bare verb+resource with no behavioral detail. It does not disclose side effects, permissions, reversibility, or return format. With no annotations to compensate, the agent gets no transparency beyond the fact that it performs an update.
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 short and front-loaded, which is concise. However, it is under-specified rather than efficiently informative, so while it is not bloated, it also does not earn its place by adding meaningful value.
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 is a mutation with no annotations, no output schema, and very limited schema descriptions. The description is insufficient for an agent to understand what the update does, what fields are relevant, or what the response will be. More context is needed even for a simple CRUD 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?
The description adds no parameter information. Schema coverage is only 20% (only 'id' has a generic 'ID of the resource' description), and the other four parameters are undocumented in both schema and description. 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 resource (rename preset), and distinguishes it from sibling tools like list_rename_presets or delete_rename_preset. However, it provides no extra context about what 'update' entails or what fields are involved, so it stops short of a top 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 given on when to use this tool versus alternatives. There is no mention of prerequisites, when an update is appropriate, or any exclusions. The tool family is clear, but the description offers 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 must carry the full behavioral burden. It only says 'Update' without disclosing side effects, permissions, idempotency, or what happens to the tag-import job. For a mutation tool, this is severely lacking.
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, front-loaded sentence that is not verbose. However, it is under-specified for a tool with four parameters and complex behavior, so while concise, it feels inadequate rather than appropriately sized.
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 (4 parameters, no annotations, no output schema, and a rich set of sibling tools), the description is extremely incomplete. It fails to explain what 'updating a tag-import job' involves, the meaning of the parameters, or any relevant 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 coverage is only 25% (only 'id' has a generic description), and the description does not mention any parameters. The fields 'note', 'columns', and 'name_column' are entirely undocumented, and the description adds no 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 'Update a tag-import job' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_tag_import, delete_tag_import, start_tag_import, and update_tag_import_mapping. It is concise and unambiguous about the operation, though it lacks detail on what 'update' 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. There are closely related tools like update_tag_import_mapping and start_tag_import that could be confused, but the description gives no context or exclusions, 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.
Behavior1/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 states the action without revealing side effects, whether it modifies only provided fields, permission requirements, or any consequences. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but conciseness is not the issue; it is under-specified. A single sentence is fine, but it omits essential information, making it more of a bare summary than a useful definition.
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 output schema and annotations, the description should explain the update behavior, fields, and side effects. It does none of that, so the tool definition is incomplete for a tool with four parameters.
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 'id' is documented), and the description adds no parameter details. Parameter names like name, position, and preserve_subfolders are left entirely unexplained, so the agent cannot determine valid values or effects.
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 a workflow step.' clearly identifies the verb (update) and resource (workflow step). It distinguishes from siblings like create_workflow_step or approve_workflow_step, but does not elaborate on scope or specific fields, so it lacks the specificity to fully differentiate from other update operations such as update_workflow.
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 like create_workflow_step, delete_workflow_step, or approve_workflow_step. The description gives no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says 'Get trashed assets' but does not explain whether it returns a paginated list, what 'trashed' means in this context, or any other behavioral characteristics. It adds no value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, consisting of a single sentence. While it is compact, it does not earn its place because it merely restates the tool name and provides no additional information. It is under-specified rather than effectively 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?
For a list tool with pagination and no output schema, the description is inadequate. It does not explain return values, pagination behavior, or the concept of 'trashed' assets. The tool is relatively simple, but the description leaves too many important details unstated.
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 describes both parameters ('page' and 'per_page') with helpful descriptions, achieving 100% schema description coverage. The description itself adds no parameter information, but the schema already covers the semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get trashed assets' essentially restates the tool name 'get_trashed_assets' with spaces, making it a tautology. It does not add any new information or distinguish the tool from siblings like 'get_asset' or 'restore_asset', and lacks a clear scope (e.g., listing all trashed assets).
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 any conditions for use, exclusions, or related tools such as 'restore_asset' or 'search_assets'. The description simply states what it does without 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 must fully disclose behavior, but it only states the action without revealing pagination semantics, response format, ordering, or any side effects. The agent is left without information about how the listing behaves.
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 and front-loaded, but it is under-specified. It does not provide enough informative content to be considered efficient; it merely echoes the tool name without elaborating on purpose or behavior.
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 no output schema and no annotations, the description should explain what is returned (e.g., a paginated list of bulk jobs), how pagination works, and any relevant context. None of this is provided, leaving the description incomplete for a tool with only two optional parameters.
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% with descriptions for both 'page' and 'per_page', so the schema carries the parameter semantics. The description adds no additional meaning beyond what is already in the schema, warranting the baseline score of 3.
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 'List bulk jobs' is a direct restatement of the tool name 'list_bulk_jobs', adding no additional specificity or context. It does not clarify what constitutes a bulk job, the scope of listing, or how it relates to sibling tools like 'get_bulk_job'.
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_bulk_job, create_bulk_job, or cancel_bulk_job. There is no mention of prerequisites, expected 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?
No annotations are provided, so the description carries the full burden. It only says 'Update a contribution portal' without disclosing side effects, required permissions, reversibility, or return behavior, which 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 very short and not verbose, but it is under-specified, adding little beyond the tool name. It fails to convey necessary information, so while concise in length, it is not appropriately sized.
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 6 parameters, no annotations, and no output schema, the description is far too minimal. It does not explain the impact of updates, what fields are supported, or any prerequisites, making it contextually incomplete.
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 17% (only 'id' is described). The description does not explain any parameters such as name, enabled, message, require_login, or allow_anonymous, leaving most fields without semantic 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 'Update' and the resource 'contribution portal', identifying the tool's purpose. It distinguishes from siblings by the verb 'update', though it does not elaborate on specific fields.
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 create_contribution or delete_contribution. It only implies usage through the verb 'update' with no context about prerequisites or alternatives.
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 full responsibility for behavioral disclosure. It merely restates the action without any context about permissions, side effects, required fields, or response behavior. The description adds no value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the action, but it is under-specified. It lacks any structured breakdown of parameters or use cases. It is not bloated, but it is too minimal to be considered 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?
This is a create operation with 3 parameters, no output schema, and no annotations. The description provides no context about what a collection is, whether parent_id creates a hierarchy, or what the response contains. It is completely inadequate for successful 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?
With 0% schema description coverage and no parameter descriptions in the text, the description fails to explain the meaning of 'name', 'parent_id', or 'description'. It does not compensate for the schema's lack of detail, leaving the agent without guidance on how to populate these 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 'Create a new collection' uses a specific verb (create) and resource (collection), clearly distinguishing it from sibling tools like update_collection, delete_collection, and list_collections. It unambiguously states the tool's 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. It does not mention prerequisites, whether it should be used before add_asset_to_collection, or how it differs from create_lightbox. There is 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits, but it only states 'Create a new lightbox'—no information about permissions, side effects, or constraints. Important details like whether parent_id is optional or how duplicate names are handled are 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 extremely brief, using only five words to state the operation. While it is front-loaded and contains no filler, its brevity borders on under-specification rather than efficient 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 three parameters and no output schema, the description is insufficient for an agent to understand parameter roles or the tool's place in the workflow. No mention of parent_id, description, or relevant context like lightbox organization is given.
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?
With 0% schema description coverage, the description fails to explain the meaning or purpose of any of the three parameters (name, parent_id, description). It adds no semantic value beyond the bare schema field 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 uses the specific verb 'Create' and the resource 'lightbox', clearly indicating the operation. It distinguishes from sibling tools like update_lightbox and delete_lightbox by the action verb, though it lacks any additional scope or 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?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states the action without context, making it unclear when a lightbox should be created versus using other collection 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 says 'Create a personal access token' with no mention of side effects, permissions, token lifecycle, or any behavioral implications. 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 a single short sentence, which is concise, but it essentially restates the tool name without adding substantive information. This is under-specification rather than effective conciseness, as it lacks necessary 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 create operation with two parameters and no output schema, the description is incomplete. It fails to explain the purpose of scopes, the meaning of name, or any expectations about the created token. Combined with no parameter descriptions, the tool is insufficiently documented 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 compensate by explaining the 'name' and 'scopes' parameters. It adds no meaning beyond the bare schema property names/types, leaving agents without clarity on what values to provide.
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 (personal access token). It effectively distinguishes itself from sibling tools like list_personal_access_tokens, delete_personal_access_token, and enable/disable_personal_access_token by using the verb 'create'.
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 simply states 'Create a personal access token' without referencing related operations or providing context for when creation is appropriate. No exclusions or alternative tool mentions are present.
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 implies a mutation (creation) but does not disclose side effects, permission requirements, reversibility, or what the response might be. This is a significant gap for a write operation.
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. It is effectively structured and front-loaded with the purpose, though it is under-specified. This is efficient but lacks necessary detail.
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 creation tool with 4 parameters, no output schema, and no annotations, this description is completely inadequate. It does not explain how to use the parameters, what the resulting preset does, or any behavioral context. The description is just a fragment that adds no value beyond the tool name.
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% parameter description coverage, with only 'template' described. The description adds no parameter information whatsoever, failing to compensate for the low schema coverage. It does not clarify the meaning of 'name', 'enabled', 'position', or 'template'.
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 ('Create') and resource ('rename preset'), which distinguishes it from sibling tools like update_rename_preset and delete_rename_preset. However, it does not explain what a rename preset is or any scope, so it is clear but not fully informative.
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. It does not mention any context, prerequisites, or conditions. The description is purely a statement of action without 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?
No annotations are provided, so the description must convey behavioral traits. While 'get' implies read-only, the description does not state what the tool returns, how it handles missing IDs, or any potential errors. This is insufficient for an agent to understand the tool's behavior.
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, which avoids fluff, but it is under-specified and borders on tautology. It merely restates the tool's name without adding meaningful content, so it fails to be effectively 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 explain what 'details' means and how this tool differs from similar tools. It does not, leaving significant gaps in context for an agent to invoke it 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%, and the 'id' parameter is described as 'ID of the resource', which is clear. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get share link details' clearly indicates a read operation on a share link, but 'details' is vague and does not specify what information is returned. It also does not distinguish this tool from siblings like list_share_links or get_share, so the purpose is only partially 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools such as list_share_links, create_share_link, delete_share_link, and get_share, the lack of any context or exclusions leaves the agent without 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 merely restates the tool name without revealing any behavioral traits. It does not mention return format, permissions, possible errors, or whether it is read-only, so the agent gains no additional insight 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words) but is essentially a tautology of the tool name, offering no real information. While brevity is present, the content is under-specified and does not earn its place as a useful 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 tool has no output schema and no annotations, so the description must supply context about what 'workflow details' entails, potential variations, or usage notes. It provides none, leaving the agent without sufficient information for a tool that is simple but not self-explanatory.
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 parameter 'id' with a description 'ID of the resource', providing 100% schema coverage. The description adds no extra meaning about the parameter, but per the baseline rule for high schema coverage, a score 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 'Get workflow details' clearly specifies the verb 'Get' and the resource 'workflow', distinguishing it from sibling tools like list_workflows (which lists) and get_workflow_step (which targets a step). The word 'details' is a bit vague, but the intent 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?
The description provides no guidance on when to use this tool versus alternatives such as list_workflows or get_workflow_step. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage solely from the tool name and sibling 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 must carry the full burden of disclosing behavioral traits. It only states the basic action and does not mention permissions, side effects, return values, idempotency, or error conditions. This is no more informative than the tool name itself, offering zero insight into what happens when the tool is invoked.
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 concise, consisting of a single clear sentence. It is front-loaded with the action and resource, avoiding any fluff. However, its brevity borders on under-specification, though that is addressed in other dimensions; for what it contains, it is 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 mutation tool with two parameters, no output schema, and no annotations, the description provides no context about the tool's role in the system, the meaning of a taxonomy, required inputs, or expected outcomes. This is completely inadequate for an agent to understand the tool's place among the many sibling 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 description mentions neither of the two parameters ('name', 'description') nor their semantics. Since the schema description coverage is 0%, the description must compensate but instead provides no parameter-level guidance. It does not explain that 'name' is required, what 'description' is for, or any constraints like uniqueness.
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 new taxonomy'), which is explicit and unambiguous. Unlike siblings such as 'update_taxonomy', 'delete_taxonomy', or 'list_taxonomies', the verb and resource combination makes the tool's purpose immediately distinct.
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 doesn't mention any prerequisites, such as whether a taxonomy should be created before adding tags, nor does it reference related tools like 'create_taxonomy_tag' or 'add_tag_to_taxonomy'. This leaves the agent without context for making a proper selection.
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 disclosing behavioral traits, but it only states the action without any context on side effects, permissions, reversibility, or what happens on duplicate names or invalid taxonomy IDs. It adds no transparency 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 concise sentence, which is structurally clean. However, it is under-specified to the point of being nearly a restatement of the tool name, lacking detail that would make the sentence informative.
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 this is a mutation tool with no annotations, no output schema, and low schema coverage, the description is incomplete. It does not clarify the role of parent_id, the requirement for an existing taxonomy, or how this tag creation interacts with other tag-related 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?
Schema description coverage is only 33%, and even that description ('ID of the resource') is generic and unhelpful. The tool description does not explain the meaning of name, parent_id, or taxonomy_id, nor the relationships between them, so it 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a tag within a taxonomy' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_tag (generic tag) and add_tag_to_taxonomy (add an existing tag to a taxonomy). It effectively communicates the core 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 provides no guidance on when to use this tool versus alternatives like create_tag or add_tag_to_taxonomy. It does not mention prerequisites, exclusions, or context for choosing this over other tag-related 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 the full burden of disclosing behavioral traits. It only says 'Create a user group' and provides no information about side effects, idempotency, error behavior, or return values. This is a mutation tool with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence with no wasted words, but it is under-specified. It functions more as a title than a full description. While it is not verbose, the lack of structured information (e.g., usage scenarios or parameter context) makes it only minimally adequate.
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 with only two parameters and no output schema, the description is insufficient. It does not explain expected return values, potential errors, or any constraints. The tool lacks annotations and output schema, so the description should compensate but fails to provide essential 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?
Schema description coverage is 0%, and the description adds no meaning beyond the bare parameter names 'name' and 'description'. It does not explain the purpose of these parameters, constraints, uniqueness requirements, or how they relate to the creation process.
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 user group' clearly states the action (create) and the resource (user group). It distinguishes from sibling tools like list_user_groups, get_user_group, update_user_group, and delete_user_group, which are all different 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 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 specify when to use this tool versus alternatives, any prerequisites, or context such as required permissions. It is a bare description with no guidance on appropriate invocation scenarios.
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 behavioral disclosure burden. 'Create a new workflow.' only states the basic action, but does not disclose any side effects, required permissions, default values (e.g., whether the workflow is enabled by default), or reversibility. The description offers minimal transparency beyond the inherent mutating nature of 'create.'
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 excessively short, consisting of only one sentence that restates the tool name. While it is technically concise, it under-specifies the tool's behavior and parameters. It does not front-load any helpful information beyond the literal action, making it more under-specification than effective 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 3 parameters, no annotations, and no output schema, the description is wholly inadequate. It does not explain what a workflow is, what the parameters mean, or any constraints. The reliance on sibling tool names for context is insufficient because the description itself adds no value, leaving the agent with no understanding of how 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 provides no information about the three parameters (name, enabled, description). The description does not compensate for the lack of schema descriptions, leaving the agent without any guidance on how to fill these fields correctly. This is a significant 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 clearly states a specific verb and resource: 'Create a new workflow.' This uniquely identifies the operation as the create counterpart to sibling tools like update_workflow, delete_workflow, and get_workflow. The purpose is unambiguous and distinguishes the tool from its siblings by the action it performs.
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. It does not mention that this should be used to create a new workflow, while update_workflow is for modifying existing ones, or that it may be a prerequisite for workflow steps. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates a privileged action ('grant free CAI budget') but does not disclose whether this is additive, whether it has irreversible effects, or what permissions are needed beyond 'Super-admin'. The behavioral impact is vague.
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 short and front-loaded with the role and action, which is efficient. However, it is under-specified for the complexity of the tool, lacking essential details while being brief. It reads as a terse label rather than a complete 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?
For a privileged mutation tool with 3 parameters and no annotations or output schema, the description is critically incomplete. It does not explain return values, side effects, parameter meanings, or prerequisites. The agent would be guessing about most aspects of 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 33% (only 'id' has a generic description 'ID of the resource'). The description does not clarify that 'id' is the organization ID, what 'amount' represents, or what 'description' is for. Some inference is possible from the tool name, but the description adds no meaningful parameter guidance.
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 ('grant free CAI budget') and the target ('to an organization'), with a role restriction ('Super-admin'). It effectively distinguishes from generic tools but does not differentiate from the sibling 'add_organization_cai_budget', which appears to perform a similar 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 explicit guidance on when to use this tool versus alternatives such as 'add_organization_cai_budget' or 'extend_organization_trial'. The only context is the 'Super-admin' role, which implies restricted usage, but no scenarios or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 restates the tool name without mentioning whether tags are appended, whether duplicate tags are handled, what permissions are needed, or any other side effects. This is essentially tautological and provides 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it does little beyond restating the tool's name. It is under-specified rather than efficiently written, as it lacks the informative content that would make the sentence earn 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?
For a simple mutation tool with no annotations and no output schema, the description should provide behavioral details such as whether tags are additive and how existing tags are affected. It only says 'Add tags to an asset', which is insufficient for an agent to understand side effects or prerequisites, leaving a significant gap in 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 input schema fully describes both parameters (id and tags) with 100% coverage, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides, but since the schema covers everything, this is acceptable.
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 'Add tags to an asset' clearly states the action (add) and the resource (tags to an asset). It implies a single-asset operation, distinguishing it from siblings like bulk_add_tags_to_assets, though it does not explicitly call out alternatives. It is specific enough for basic selection.
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 bulk_add_tags_to_assets or auto_tag_asset. The description only states what the tool does, not when to prefer it over other tag-related operations.
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 convey behavioral traits. It only says 'Create' without disclosing side effects, asynchronicity, permissions, or return behavior. This lacks the transparency needed 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 short and free of fluff, which is good. However, it is under-specified for the complexity of the operation, making it less effective than a more balanced description that includes essential 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?
The tool creates a batch download, but the description lacks any mention of response format, job lifecycle, or conditions. With no output schema and no annotations, this leaves the agent under-informed about what to expect.
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 describes 'size' (including default) but not 'asset_ids'. The description does not compensate for the undocumented parameter, merely hinting at 'multiple assets' without adding real semantic value. Since schema coverage is only 50%, this is a noticeable 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 states a clear action ('Create') and a specific resource ('batch download for multiple assets'), which is helpful. However, it does not distinguish this tool from the similarly named sibling 'bulk_download_assets', so it lacks 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 alternatives like 'bulk_download_assets' or 'get_download'. The description gives no context for selection or prerequisites, leaving the agent without 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, but it only restates the function without disclosing read-only nature, permission requirements, or response format. This is essentially a tautology of the tool name, offering no additional 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 concise sentence with no wasted words. However, it is so minimal that it borders on under-specification, providing no additional context beyond the tool name and failing to add value for the agent.
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, and the description does not explain what 'details' entails, such as which fields are returned or any access control constraints. Given the simple one-parameter input, a bit more context would be expected, but it remains a basic get-by-id 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?
Schema coverage is 100% with the 'id' parameter described as 'ID of the resource', so the schema carries the parameter meaning. The description adds no parameter specifics, but high coverage justifies the baseline score of 3.
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 access request details' clearly states the tool retrieves details for a single access request, using a specific verb and resource. It distinguishes from sibling tools like list_access_requests and create_access_request, though it lacks explicit mention of the ID parameter or any unique constraints.
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 find_access_request or list_access_requests. There is no mention of prerequisites, exclusions, or typical use cases, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals almost nothing. It does not state whether the operation is read-only, what the response structure is, whether counts are grouped, or any side effects (e.g., performance implications).
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 redundancy, and it front-loads the core purpose ('Get asset counts'). It is efficient in length, though it sacrifices 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?
For a tool with 3 optional parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the returned counts look like, how the filters interact, or why an agent would choose this over other asset-related 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?
Schema description coverage is 0%, so the description must compensate, but it merely says 'optional filters' without elaborating on tags, collection_id, or storage_folder_id. The parameter names in the schema are self-explanatory to some extent, but the description adds no meaningful semantics or usage details.
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 verb 'get' with 'asset counts' clearly identifies a counting operation on assets, and it is distinct from sibling tools like get_asset or search_assets. However, it lacks explicit scope (e.g., total count vs. grouped counts) and does not mention what the counts represent, so it is not fully specific.
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 search_assets or get_asset. The description only says 'optional filters' without explaining contexts that call for this tool, 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 behavioral disclosure, but it only states that it returns 'download status and URL'. It does not indicate whether the operation is read-only, whether the status may be pending, or what happens if the download is not ready. Lack of such details leaves behavior opaque.
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 or repetition. It efficiently states the tool's core function, though it is quite telegraphic and could benefit from a bit more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is insufficiently complete. It does not explain what the token refers to, how the status and URL are returned, or how this tool fits into the broader download workflow. Given the presence of related siblings, more contextual detail is needed.
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 one parameter 'token' with no description, and the tool description does not mention the token at all. With 0% schema description coverage and no compensating explanation in the description, the parameter's meaning and format remain entirely unclear.
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 'Get' and identifies the resource as 'download status and URL', which clearly states the tool's function. However, it does not distinguish itself from the sibling tool 'get_asset_download', which likely has a similar purpose, so it falls short of full 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 guidance is provided on when to use this tool versus alternatives like 'create_download' or 'get_asset_download'. The description does not mention any prerequisites, such as needing a token from a previously created download, nor does it suggest polling behavior.
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 present, so the description must carry the full burden of behavioral disclosure. It only restates the function name and offers no information about read-only nature, security requirements, rate limits, return format, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words, but it is under-specified. It is not overly long, but it lacks structure or elaboration that would help an agent understand the tool's purpose beyond the 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?
With no output schema and no annotations, the description leaves ambiguity about what 'search query details' actually includes (e.g., saved criteria, results, metadata). It is too minimal to be considered complete for agent 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 input schema fully documents the 'id' parameter as 'ID of the resource' with 100% coverage. The description adds no additional context beyond the schema, 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 clear 'Get' verb and identifies the resource as 'search query details', which indicates a retrieval operation. It distinguishes from sibling tools like list_search_queries, create_search_query, and update_search_query by implying a single-resource fetch, though it does not explicitly state '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?
No guidance is provided on when to use this tool versus alternatives. The description simply states the action without mentioning prerequisites, exceptions, or when to prefer list_search_queries for enumeration.
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 full burden for behavioral disclosure. 'Get tag details' is purely a restatement of the tool's name and does not disclose any side effects, error behavior, or return format characteristics.
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 short, which might be seen as concise, but it lacks substance. It is under-specified and does not add value beyond the tool name, so it is more a minimal placeholder than effective concise writing.
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 'details' are returned, but it does not. The tool's simplicity (one required parameter) reduces the burden, but the lack of any return-value information leaves a significant 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?
The input schema fully documents the 'id' parameter with a type and description, so the schema covers semantics. The description adds no additional meaning about the parameter, but with 100% schema coverage, a 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 'Get tag details' uses a clear verb and resource, making it evident this is a retrieval operation for a tag. It distinguishes from siblings like list_tags and update_tag, though it does not specify what 'details' includes.
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 list_tags or get_tag_events. There is no mention of context, prerequisites, or exclusions, leaving the agent to guess when this is the best 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, but it only implies a read operation without stating return format, error behavior, or scope (e.g., whether it includes tags). No additional behavioral traits are disclosed beyond what the 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 with no wasted words. It is efficiently structured, though it is minimal to the point of vagueness, which is more a completeness issue than a conciseness flaw.
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 appears in a large family of taxonomy-related sibling tools, yet the description does not clarify what 'details' means or how this retrieval differs from list_taxonomies or get_taxonomy_tags_tree. With no output schema or annotations, the description should provide more context to be self-sufficient.
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 100% coverage for the single 'id' parameter with the description 'ID of the resource.' The tool description adds no extra semantic context for the parameter, so the baseline score of 3 is appropriate since the schema already documents it.
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 includes a specific verb ('Get') and resource ('taxonomy'), but 'details' is vague and does not specify exactly what is returned or distinguish it from sibling tools like list_taxonomies or get_taxonomy_tags_tree. It is a clear but generic 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?
The description provides no guidance on when to use this tool versus alternatives such as list_taxonomies or get_taxonomy_tags_tree. There are no exclusions, context signals, or mentions of alternative tools, leaving the agent without any usage 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?
With no annotations provided, the description carries the full burden. It merely says 'list' without disclosing pagination behavior, whether both requests and grants are returned, or any other behavioral details such as authentication or result structure.
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, making it concise, but it is under-specified for a tool with 5 parameters and no annotations. It is not verbose, but it lacks necessary details, so it earns only a mid-level score for structure.
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, no output schema, and no annotations, the description is incomplete. It does not explain the difference between requests and grants, default sorting/pagination, or how filters like 'type' and 'aasm_state' interact.
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 parameter-level meaning. The schema covers 60% of parameters with descriptions, but the tool description does not provide any additional context for 'q', 'page', 'type', 'per_page', or 'aasm_state', leaving moderate coverage uncompensated.
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 ('List') and resource ('access requests and grants'), but it does not differentiate from the sibling tool 'list_access_grants' and may even conflate the two. A clear verb and resource are present, but sibling differentiation is lacking.
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 explain when to use this tool versus alternatives like 'list_access_grants' or 'get_access_request', nor does it mention any filters or limitations.
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 carries the full burden of disclosing behavior. It only says 'List' without indicating read-only nature, pagination behavior, return format, or any permissions. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it is under-specified—it could include guidance on filters or output without losing conciseness. It is not fully earning its place given the missing 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?
For a simple list tool with no annotations and no output schema, the description is insufficient. It does not explain what a 'creator/photographer tag' is, how the response is structured, or how this relates to sibling tools like 'list_tags'. The agent lacks essential 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?
Schema description coverage is 67% (page and per_page are described, but 'q' is not). The description adds no parameter information, failing to explain what 'q' filters or how page/per_page affect results. It does not compensate for the undocumented 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 clearly states the verb 'List' and the resource 'creator/photographer tags', which distinguishes it from the sibling tool 'list_tags'. While 'creator/photographer tags' is somewhat specific, it could be more explicit about the tag type, but it is not vague or tautological.
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 'list_tags' or 'create_creator_tag'. There is no mention of exclusions, prerequisites, or typical use cases, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Update an in-progress access request,' which implies mutation but doesn't disclose permissions, whether the update is partial or full, how custom_meta behaves, or the response. The 'in-progress' constraint is useful but insufficient for safe invocation.
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 fluff and front-loads the verb and resource. It is appropriately concise, though it omits necessary detail. Still, it earns its place by providing the core purpose and a scope constraint.
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 three parameters (one nested object) and no annotations or output schema, the description is far from complete. It doesn't explain update semantics, allowed fields, status constraints, or return value. The sibling context suggests many related tools, but this description doesn't contextualize how it fits among them.
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 33% (only 'id' has a description, which is generic). The description itself does not mention purpose or custom_meta at all, so it fails to compensate for the low coverage. The agent is left with minimal semantic information about 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 ('Update') and the resource ('access request'), and adds the scope constraint 'in-progress.' This distinguishes it from create/delete/finalize/revoke tools, though it doesn't explicitly differentiate from the more specialized set_access_request_custom_meta. Overall, the main purpose is 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 gives no guidance on when to use this tool versus alternatives like set_access_request_custom_meta or finalize_access_request. It implies usage for updating an in-progress request, but doesn't state exclusions or what happens if the request isn't in-progress. There is no explicit context for choosing this tool over others.
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 merely restates the tool name ('Update a lightbox') and adds no information about permissions, side effects, partial updates, or response behavior.
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 brief, which aids conciseness but sacrifices informativeness. It is a single sentence that essentially repeats the tool name, providing minimal structured 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 simple update tool, the description is incomplete: it does not state which fields can be updated, whether updates are partial or full, or what the response contains. Since there is no output schema, the description should have explained return behavior.
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 does not elaborate on any parameters. The schema only describes the 'id' parameter as 'ID of the resource', while 'name' and 'description' have no descriptions. The parameter names are somewhat self-explanatory, but the description adds no value 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 identifies the verb 'Update' and the resource 'lightbox', making the basic purpose clear. However, it does not specify which fields can be updated or distinguish it from other update tools, though the schema partially fills that gap.
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 create_lightbox, delete_lightbox, or get_lightbox. No context, preconditions, or exclusion criteria 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?
No annotations are provided, so the description carries the full burden of explaining behavior. It only says 'update' without disclosing side effects, permission requirements, reversibility, or impact on related entities like faces or tags. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It is appropriately sized for a simple update action, though it lacks some 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 mutation tool with no annotations and no output schema, this description is incomplete. It fails to explain return values, error cases, or required context (e.g., whether the tag must already exist in the specified taxonomy). The agent is left with insufficient information to predict 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?
Schema description coverage is only 50%, and the description adds no parameter insights. The schema's descriptions for id and taxonomy_id are generic ('ID of the resource'), while name and parent_id have no descriptions at all. The tool description does not compensate for this 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 'Update a tag inside a taxonomy' clearly states the action (update) and the resource (tag within a taxonomy), providing a specific scope. It is distinguishable from sibling tools like update_tag and update_taxonomy by the 'inside a taxonomy' qualifier, though it does not explicitly call out 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?
The description offers no guidance on when to use this tool instead of alternatives such as update_tag or create_taxonomy_tag. There are no contextual cues, exclusions, or examples to help the agent decide.
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 but only states the high-level operation. It does not mention whether the operation is atomic, what permissions are required, whether setting the list replaces existing values, or what happens on partial failure. The phrase 'single change' hints at one uniform operation, but side effects and reversibility are undisclosed, matching the low-transparency example of update_drive.
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 immediately conveys the core action and uses a parenthetical to list the operation variants. Every word earns its place, making it concise and 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?
For a bulk mutation tool with 4 parameters, no annotations, no output schema, and 0% parameter descriptions, the description is severely under-specified. It omits how to specify the taxonomy for attach/detach, does not explain the effect of set list, and provides no information about return values, errors, or the scope of tag_ids. An agent would struggle to correctly invoke this tool based solely on the given information.
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, but it only vaguely maps 'set list' and 'attach/detach taxonomy' to the parameters. It does not explain tag_ids explicitly, nor does it address the absence of a taxonomy identifier parameter – a critical gap because attach/detach taxonomy implies a taxonomy target, yet no such parameter exists. The enum values for list are left to the schema, but the relationships between add_taxonomy and remove_taxonomy are unclear.
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 action ('Apply a single change') on a specific resource ('many tags'), with the parenthetical enumerating the change types (set list, attach/detach taxonomy). It distinguishes from sibling tools like bulk_delete_tags or bulk_find_tags by indicating an update operation. However, it does not explicitly contrast with single-tag update tools like update_tag or merge_tags, 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?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or when a different tool (e.g., update_tag for single tags, add_tag_to_taxonomy for one tag) would be more appropriate. The only implied context is the 'many tags' bulk nature, which is not explicit enough for high scores.
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 carries the full burden of behavioral disclosure. It simply states 'Create a new rights package' without revealing mutation effects, required permissions, side effects, or return values, leaving the agent with minimal insight.
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 filler, making it concise and front-loaded. However, it is under-specified to the point of providing minimal utility, lacking any elaboration that would make the conciseness valuable.
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 5 parameters, no annotations, and no output schema, this description is inadequate. It does not explain the domain of rights classes, expiration behavior, or what happens upon successful creation, leaving critical gaps for an agent.
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 parameter meaning. The rights_class enum values (e.g., 'owned', 'some', 'library') are undefined, and fields like expires and expires_at are left entirely to the schema's bare names.
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' with the resource 'rights package', clearly distinguishing it from sibling operations like list_rights_packages or get_rights_package. There is no ambiguity about 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?
The description provides no guidance on when to use this tool versus alternatives such as bulk_set_asset_rights_package or list_rights_packages. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description merely paraphrases the tool name. It fails to disclose any behavioral traits such as irreversibility, permissions, side effects, or relationship to related tools like revoke_access_request.
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, clear sentence. It is front-loaded and concise, though it adds little beyond the 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 delete (mutation) tool with no annotations or output schema, the description is too thin. It doesn't clarify what the 'id' refers to (access grant ID vs resource ID), the consequences of deletion, or how this differs from related revocation tools.
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 already documents the single parameter 'id' with description. Tool description adds no extra parameter meaning, but schema coverage is 100%, so baseline 3 applies.
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 resource 'access grant', clearly distinguishing this tool from other delete/revoke operations in the sibling list.
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 on when to use this tool, no alternatives, no exclusions. The description only restates the action without 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 provided, the description must disclose behavior fully. It does not explain what 'export' entails: whether it returns a file, triggers a download, is synchronous or asynchronous, or has side effects. No details about permissions, rate limits, or data handling are given. This leaves significant ambiguity about the tool's runtime behavior.
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 conveys the core purpose efficiently. However, it is terse to the point of under-specification, so it is not a perfect 5, but it earns high marks for clarity of structure and economy of 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?
Given the tool has one parameter, no output schema, and no annotations, the description carries a heavy burden to explain what the tool does and what the caller can expect. It fails to describe the output format, any side effects, whether the export is a download or in-response data, or any operational context. The minimal description leaves too many gaps for an agent to safely invoke the tool.
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, and the description only adds that export is 'by ID', implying the 'ids' array refers to custom meta field IDs. It does not clarify constraints (e.g., maximum number of IDs, whether IDs are required valid at call time, or what a numeric ID represents beyond the tool name). The parameter name is self-explanatory but lacks depth.
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 ('bulk export') and the resource ('custom meta fields'), and the 'by ID' qualifier specifies the input scope. It distinguishes from sibling tools like list_custom_meta_fields and get_custom_meta_field, but the term 'export' is somewhat generic without specifying the output format.
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. There is no mention of when bulk export is appropriate, how it differs from listing or fetching individual fields, or any prerequisites or exclusions. The description only states the tool's own purpose without contextualizing its use.
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 what the tool returns on success or failure, whether it is read-only, or any side effects. The description simply states the action without any 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 unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 minimal but lacks return value details, error handling, or differentiation from the similarly named 'get_contribution'. It does not fully equip an agent to understand the tool's complete behavior.
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 indicates that 'slug' is the identifier used for lookup, which adds meaning beyond the schema's plain string type. However, it does not describe expected slug format or provide examples, leaving some ambiguity.
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 ('Find'), resource ('contribution'), and method ('by slug'), which clearly communicates the action. It distinguishes from list/create operations but does not explicitly differentiate from the sibling 'get_contribution' tool.
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_contribution' or 'list_contributions'. The one-line description gives no context for selection 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 provided, so the description carries the full burden. It only says 'detailed information' without disclosing what details are included, the effect of include_meta/include_renditions, or any access requirements. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is appropriately sized, though extremely brief; it gets straight to the point without 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?
Given the tool has 3 parameters, no output schema, no annotations, and many competing sibling tools, this minimal description is inadequate. It lacks information about return structure, parameter effects, and how it differs from other asset getters.
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% (only id has a description). The description does not explain the include_meta and include_renditions booleans, failing to compensate for the low schema coverage. 'Detailed information' does not clarify what these flags control.
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 'Get detailed information about a specific asset', using a specific verb and resource. However, it does not differentiate from sibling tools like get_asset_content or get_asset_meta, leaving scope slightly ambiguous.
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. With many sibling get_asset_* tools, the absence of usage context leaves the agent uncertain about which tool to select.
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 for behavioral disclosure. It only says 'Get contribution details' and provides no information about permissions, return format, error conditions, or whether the operation is read-only. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundancy. It efficiently communicates the core action, though it is extremely terse and lacks supporting 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?
This is a simple one-parameter getter, but without an output schema or behavioral annotations, the description is too thin for an agent to fully understand what 'contribution details' entail or how this tool relates to other getters. The minimal context makes correct selection and invocation less certain.
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 for the single parameter 'id', described as 'ID of the resource'. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 the resource ('contribution details'), clearly indicating a read operation on a contribution. However, it does not differentiate from sibling tools like get_asset or get_membership, which also follow this pattern.
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. It does not mention contexts such as retrieving a specific contribution after listing contributions, nor does it distinguish contributions from other related resources.
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. While 'list' implies a read-only operation, it does not mention pagination behavior, whether it lists all folders recursively or only top-level ones, ordering, or the meaning of parent_id. The description adds no behavioral context beyond what the schema already offers.
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 very concise at three words, with no redundant sentences or filler. It is front-loaded and easy to parse, though it is somewhat under-specified. The brevity is effective for a simple list operation, but it lacks important details found in better descriptions.
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 has three optional parameters, no output schema, and no annotations, the description is inadequate for correct invocation. It does not explain return values, pagination defaults, hierarchy behavior, or how it relates to the similar get_storage_folders_tree tool. This is a clear gap for a tool with moderate 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?
The description adds no information about the parameters (page, per_page, parent_id). Schema coverage is 67%, with parent_id lacking a description, and the tool description does not compensate for this gap or clarify the role of each 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 'List storage folders' states a clear action ('list') and resource ('storage folders'), effectively conveying the tool's basic purpose. However, it does not distinguish it from the sibling tool 'get_storage_folders_tree', leaving ambiguity about whether it returns a flat list or handles hierarchy.
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 get_storage_folders_tree or create_storage_folder. It does not mention any specific context, prerequisites, or exclusions, 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 provided, the description carries the full burden of behavioral disclosure. It only states the action, with no mention of side effects, permissions, uniqueness constraints, or what happens on duplicate names. This is a minimal, non-informative 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, short sentence that is front-loaded with the verb and resource. It contains zero wasted words, though it errs on the side of under-specification rather than 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?
For a simple one-parameter create tool, the description might be minimally adequate, but it lacks any context about naming constraints, uniqueness, or related tools. The absence of annotations and output schema makes this description feel incomplete for an agent trying to use it 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 schema has one parameter 'name' with no description, and the schema description coverage is 0%. The description adds no additional meaning about the parameter, though the param name is somewhat self-explanatory. It does not compensate for the missing 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 'Create a new creator tag' clearly states the action (create) and resource (creator tag). It is distinct from sibling tools like 'create_tag' by specifying the resource type, though it doesn't clarify what a creator tag is or how it differs from a regular tag.
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_tag' or 'bulk_set_asset_creator_tag'. The description gives no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'Delete/dismiss' without mentioning permanence, side effects on assets, permissions, or reversibility. The tool's destructive nature is implied but not elaborated.
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 brief, which is concise, but it borders on under-specification. It lacks structure and context, making it less useful than a fully concise two-sentence description that includes key 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 tool with a simple signature and no output schema or annotations, the description should at least clarify the scope of deletion versus removal. The presence of 'remove_asset_auto_tag' among siblings makes this ambiguity a significant gap. The description is incomplete for effective tool selection.
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 covers the single parameter 'id' with a generic description 'ID of the resource'. The description adds no further parameter semantics, so the schema's high coverage (100%) earns the baseline score of 3.
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/dismiss an auto tag' clearly identifies the action (delete/dismiss) and the resource (auto tag). However, the slash introduces ambiguity (delete vs dismiss) and does not distinguish this tool from the similarly named sibling 'remove_asset_auto_tag', so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'remove_asset_auto_tag'. The description does not specify whether it deletes the auto tag definition globally or removes it from a specific asset, leaving the agent without clear context for selection.
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 and a destructive action, the description carries the full burden of behavioral disclosure, but it reveals nothing about permanence, side effects on assets, permissions, or reversibility. This is a significant transparency gap for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is so minimal that it borders on under-specification. It lacks critical details expected for a delete tool, making it less useful despite being 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?
For a destructive operation with one parameter and no annotations or output schema, the description is highly incomplete. It fails to mention the irreversibility, the effect on contained assets, or any special conditions, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the lone parameter 'id' as 'ID of the resource' (100% coverage), so the baseline is 3. The description adds no additional meaning about what kind of resource or any constraints, but it doesn't need to compensate given the 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 'Delete a collection' uses a specific verb and resource, clearly distinguishing it from sibling tools like delete_lightbox or delete_tag. 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 exclusions. The description only states the action without context such as ownership requirements or whether the collection must be empty.
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 'Get a tag-import job' without mentioning read-only nature, idempotency, possible errors, or return format—essentially providing no additional transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with no wasted words. It is appropriately front-loaded, though it could arguably be expanded with useful information without becoming verbose.
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 get tool with no output schema, the description is minimally viable: it states what it does but omits return payload details and any contextual guidance. This meets the bare minimum but leaves 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 100%, so the baseline is 3. The description does add a tiny bit of context by naming the resource as 'tag-import job', but it does not elaborate on the id parameter's meaning or constraints beyond what the schema already says.
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) and resource (tag-import job), making the purpose unambiguous. It does not explicitly differentiate from sibling tools like list_tag_imports or get_meta_import, but the resource name is specific 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. It does not mention that this retrieves a single job by ID or contrast with list_tag_imports, 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 disclosing behavioral traits. 'List' implies read-only but does not mention pagination behavior, ordering, response structure, or any authentication requirements. The description adds minimal value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, but it is under-specified and essentially restates the tool name with spaces. While it is not verbose, it lacks any structured additional information (e.g., pagination or usage notes), 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.
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 should provide more context about the behavior and results of listing crop presets. It does not mention what a crop preset is, whether pagination is applicable, or any error conditions. For a simple list tool, this is incomplete.
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% parameter description coverage for 'page' and 'per_page', so the schema already explains the parameters. The description does not add any additional meaning or context for the parameters, which is consistent with the baseline score of 3 for high 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 'List crop presets' clearly states a specific verb ('List') and resource ('crop presets'), distinguishing it from sibling operations like 'create_crop_preset' and 'list_rename_presets'. However, it is minimal and does not add scope or context (e.g., whose presets), which keeps it slightly below 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, no prerequisites, and no exclusions. As a listing operation, it is implicitly suitable for retrieving presets, but there is no explicit context or comparison to other list 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 available, the description carries the full burden of behavioral disclosure. It only says 'List' and does not mention that this is a read-only operation, whether pagination is needed for large result sets, how results are ordered, or what fields are returned.
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 unnecessary words, but it is under-specified. It could include useful context without becoming verbose, such as noting that it returns a paginated list or that the query parameter searches by name/description.
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 (optional search and pagination) and the presence of sibling tools like get_custom_meta_field and export_custom_meta_fields, the description is incomplete. It does not explain the scope of the listing, the response format, or how it relates to other metadata field tools.
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 covers all three parameters (q, page, per_page) with descriptions, so schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, such as how the search query interacts with pagination or the default behavior when parameters are omitted.
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 (list) and resource (custom metadata fields), which is specific and distinguishes it from get_custom_meta_field (singular). However, it does not specify the scope (e.g., all fields) or mention the search/pagination options, leaving some ambiguity about the tool's full capabilities.
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 indicate when to use this tool versus alternatives like get_custom_meta_field or export_custom_meta_fields, nor does it mention any prerequisites or typical scenarios.
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 'List ingestion jobs' with no mention of pagination, scope, safety, response format, or any behavioral traits beyond the verb. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (three words), which is concise but under-specified. It lacks sentence structure and contextual framing. While there is no wasted text, it is not a model of well-structured documentation.
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 annotations, no output schema, and a large set of sibling tools, a three-word description is insufficient. It does not explain what ingestion jobs are, the return value shape, or when to choose this over related list tools.
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%: both page and per_page have descriptions. The tool description adds no additional parameter meaning, but the schema already documents the parameters adequately, 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 states a clear action ('List') and resource ('ingestion jobs'), providing basic purpose. It does not explicitly distinguish from sibling list tools like list_bulk_jobs or list_meta_imports, but 'ingestion' identifies a distinct 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?
There is no guidance on when to use this tool versus alternatives, no context on prerequisites, and no exclusions. The description simply names the operation without any usage 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only indicates 'List', implying a read-only operation, but fails to mention scope (organization or user-level), pagination, ordering, or any side effects. This is minimal and lacks necessary 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, grammatically valid sentence, which is concise. However, it is under-specified for a tool that supports filtering and pagination; it could be more informative without being verbose. It is not as effective as a well-structured description that includes usage 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?
The tool has no output schema, no annotations, and multiple sibling tools. The description is too brief to cover usage scope, return format, or how it differs from related tools like 'list_my_invites'. This inadequacy makes it hard for an agent to invoke the tool correctly in 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 input schema fully describes all three parameters (q, page, per_page) with a coverage of 100%, so the baseline is 3. The description adds no extra semantic context about how these parameters behave beyond the schema, so no additional credit is warranted.
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 ('List') and the resource ('pending invites'), making the core purpose evident. However, it does not differentiate itself from the sibling tool 'list_my_invites', which likely has a different scope (organization-wide vs. user-specific invites).
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 instead of alternatives like 'list_my_invites' or 'find_invite'. The description simply states the action without any contextual hints, 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 provided, the description carries the full burden of behavioral disclosure. It only states 'List metadata import jobs', implying a read-only operation but offering no details about pagination, filtering, response shape, or any side effects. This is minimal and does not go beyond what the name already suggests.
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 is front-loaded and not verbose. However, it is essentially a paraphrase of the tool name and adds little value, so while it is appropriately sized, the substance is lacking.
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 is incomplete. It does not explain what metadata import jobs are, what the returned data looks like, or how the parameters affect the results. For a list tool with minimal context, this is not sufficient to fully guide an agent.
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 for all three parameters (q, page, per_page) with descriptions, so the baseline is 3. The description itself adds no parameter information beyond what the schema provides, so it neither enhances nor detracts from the schema's 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 'List metadata import jobs' uses the specific verb 'List' and names the resource 'metadata import jobs', clearly stating the tool's purpose. However, it does not differentiate from sibling tools like get_meta_import or list_tag_imports, so it doesn't fully distinguish 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. There is no mention of differences from get_meta_import (single import) or list_tag_imports (tag imports), 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 must disclose behavior, but it only states the action without mentioning pagination, return format, or whether it lists sessions for the current user or organization. The presence of optional pagination parameters hints at behavior, but the description itself adds no transparency.
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 short and front-loaded, which is good for a simple tool. But it is under-specified: the single phrase 'List upload sessions' provides no additional context or detail, making it less helpful for an agent.
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 is simple, but with no output schema and no behavioral details, the description leaves the agent without knowledge of what the response looks like or any filtering/sorting options. For a list operation, this is a noticeable 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 coverage is 100% for both parameters (page, per_page), so the description does not need to repeat them. However, the description adds no extra meaning about parameter usage or how they affect the results, so it sticks to the baseline.
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 clear verb+resource pattern: 'List upload sessions' tells the agent exactly what the tool does. However, it does not distinguish this from other list_* siblings, nor does it define what constitutes an upload session, so it lacks the specificity to fully stand apart.
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 or when to prefer alternatives like create_upload_session or set_upload_done. The description gives no context about typical workflows or prerequisites, 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 full behavioral disclosure burden. It only says 'Add an asset to a collection', without revealing side effects, idempotency, permissions, or error behavior. This is insufficient for a mutation operation.
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 zero wasted words. It is concise, but the extreme brevity leaves out important details, so it earns a 4 rather than a 5.
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 is a mutation with no annotations and no output schema. The one-sentence description does not cover expected outcomes, prerequisites, or contextual information needed to invoke correctly. Similar tools like update_collection provide more context, making this under-specified.
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%, but the descriptions are generic ('ID of the resource'). The parameter names collection_id and asset_id are self-explanatory, so the tool description adds no additional meaning. The baseline of 3 applies because the schema exists and names are clear, though the descriptions are low-quality.
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: adding an asset to a collection, with specific verb and resources. It does not explicitly differentiate from similar tools like add_asset_to_lightbox, but the resource types are distinct, 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 usage context is provided. It does not mention when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply restates the action without guiding 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 of behavioral disclosure. It only says 'Create a new filter group' without mentioning permissions, side effects, required ownership, or any consequences. This is minimal for a create operation, especially given the lack of annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key verb and object. It is appropriately brief, though it arguably lacks useful detail; however, the short length is not 'wasteful' but rather '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?
Given the tool has 2 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain what a filter group is, return values, expected input format for filter_order, or any behavior beyond creation. This is insufficient for an agent to invoke the tool reliably.
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 2 parameters with 50% description coverage (filter_order has a schema description, name does not). The description adds no explicit meaning about 'name' or 'filter_order'; 'saved filter configurations' is a vague allusion and doesn't clarify parameter semantics. More detail is needed to compensate for the schema 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 clearly states a specific action ('Create a new filter group') and resource ('filter group'), distinguishing it from sibling tools like list_filter_groups, get_filter_group, update_filter_group, and delete_filter_group. The verb and object are 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_filter_group or list_filter_groups. It doesn't state any prerequisites, exclusions, or typical scenarios, 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?
There are no annotations, so this description is the only source of behavioral context. 'Transfer assets / a group to a user' implies a mutation but does not disclose whether assets change ownership, what permissions are needed, or if the action is reversible. The reference to external docs avoids describing the actual behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence plus a docs reference, which is concise and front-loaded. The first sentence captures the purpose efficiently, though the second sentence is somewhat vague but not wasteful.
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 tool with no annotations and no output schema, the description is insufficiently complete. It fails to address any behavioral details, usage context, or parameter semantics, leaving the agent to rely on external documentation. Sibling tools like create_share_link and create_asset_group_invite introduce ambiguity that is not resolved.
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%, so the description must explain the parameters. It implies that asset_ids or asset_group_id select the items to transfer, but does not define email, message, expires_at, or how asset_ids and asset_group_id interact. The statement about body fields supported by the org is a pointer to documentation rather than 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 'Create' with resource 'a share' and clarifies it means transferring assets or an asset group to a user. This clearly distinguishes it from sibling tools like create_share_link (which likely creates a link) and create_asset_group_invite (which invites to a group). 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 given for when to use this tool instead of create_share_link or create_asset_group_invite. The sentence about Mediagraph docs addresses supported body fields, not usage context. There is no mention of prerequisites, 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It simply says 'Delete a contribution portal' but does not disclose whether deletion is permanent, whether it cascades to related resources, or what permissions are required. For a destructive operation, this is insufficient.
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 concise sentence that is front-loaded with the verb and resource. It contains no fluff or redundant information. It could be slightly more informative while still being concise, but it is 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter, no output schema, and no annotations, so the description must fully contextualize the operation. It fails to mention irreversibility, required permissions, potential side effects, or return behavior. This is a significant gap for a destructive action, making the description incomplete.
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 parameter 'id' with a generic description 'ID of the resource', and the schema description coverage is 100%. The tool description adds only the context that the resource is a 'contribution portal', not specific details about the id format. Baseline 3 applies because the schema already documents the parameter, even if minimally.
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 action ('Delete') and the resource ('contribution portal'), which clearly distinguishes it from sibling tools like get_contribution, create_contribution, and update_contribution. However, the term 'portal' is slightly ambiguous and may not match the exact resource type, so it is not a perfect 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 versus alternatives, no prerequisites, and no warning about irreversibility. It only states the action without context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral traits. It does not mention consequences of deletion, permission requirements, or whether the action is reversible, leaving an agent without critical safety information 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words, allowing an agent to grasp the core purpose quickly. However, it is minimalistic and could be considered under-specified, but it does not waste 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 delete operation with no annotations and no output schema, the description is too sparse. It fails to mention irreversibility, effect on access, or any error conditions, which are important for safe invocation. The tool's simplicity does not excuse missing critical 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 100% with a single 'id' parameter described as 'ID of the resource.' The description adds no additional parameter context, but the schema already fully documents the parameter, meeting the baseline expectation.
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 the resource (share link), making the tool's purpose unambiguous. It does not explicitly distinguish from sibling tools like delete_share, but the specific resource name prevents confusion with other deletion 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 is provided on when to use this tool, prerequisites, or alternatives. The description merely restates the action without contextual cues such as 'use get_share_link first to confirm the ID' or 'this is irreversible'.
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 indicates a destructive 'delete' operation but does not explain whether it permanently removes the tag from the taxonomy or only the association, nor does it mention side effects, reversibility, or permissions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is front-loaded and clearly communicates the core action without wasting words, achieving maximum 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?
For a mutation tool with no annotations or output schema, the description is too sparse. It fails to clarify the exact effect on the tag (global deletion vs. untagging from a taxonomy), and does not address distinctions from closely related siblings. This leaves significant context gaps for an agent assessing side effects and alternatives.
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 100% parameter descriptions, but they are generic ('ID of the resource') and unhelpful. The tool description adds no parameter-specific meaning; however, the parameter names (taxonomy_id, id) and the tool's purpose loosely imply roles. Per the baseline for high schema coverage, a 3 is appropriate, though the schema descriptions themselves are weak.
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 specific action ('Delete a tag from a taxonomy') with a clear verb and resource. However, it does not explicitly differentiate from sibling tools like 'delete_tag' or 'remove_tag_taxonomies', leaving some ambiguity about whether it deletes the tag globally or just the association.
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. There is no mention of exclusions, prerequisites, or comparisons to sibling tools like 'delete_tag' or 'remove_tag_taxonomies', so the agent would have to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 restates the action ('Get') and the resource. It does not disclose behavior on missing IDs, authorization requirements, or what 'details' includes.
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 very concise and front-loaded, with no filler. However, it is so terse that it misses opportunities to add helpful context while remaining short.
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 is minimally viable: the agent knows what to call and what argument to provide. But it lacks return-value context and usage/alternative info, leaving noticeable 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 fully documents the single 'id' parameter (100% coverage), so the description need not add much. It adds no extra semantics beyond the tool's name, but the schema is sufficient.
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 clear verb ('Get') and resource ('auto tag details'), indicating a single-item lookup. It is implicitly distinct from siblings like list_auto_tags or get_asset_auto_tags, but it does not explicitly state that 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 similar siblings (e.g., list_auto_tags for enumeration, get_asset_auto_tags for asset-specific tags). There are 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.
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. 'Get' implies a read-only operation, but it doesn't state what happens if the collection is not found, whether authentication is required, or what the response format is. The description adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of a single clear sentence. It wastes no words, though it could be slightly more detailed without becoming verbose.
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, the description is minimally viable. It implies a return value ('details') but doesn't specify what those details include. With no output schema and no annotations, the description could be more complete, but given the low complexity, it remains 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?
Schema description coverage is 100% for the single 'id' parameter, which is described as 'ID of the resource'. The description adds no additional meaning beyond the schema, 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 the specific verb 'Get' with the resource 'collection details', clearly distinguishing it from sibling tools like list_collections (list) and get_collections_tree (tree). However, 'details' is somewhat vague and could be more explicit about what is returned (e.g., metadata, assets).
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 doesn't mention that list_collections should be used for listing all collections or that create_collection/update_collection are for mutations. No context or exclusions 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?
With no annotations, the description carries the full burden. It does not disclose any behavioral traits such as return format, error behavior (e.g., 404 if not found), permission requirements, or whether the operation is read-only. It merely paraphrases 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.
Conciseness4/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 immediately clear and front-loaded. However, it is so brief that it misses opportunities to include helpful context or usage notes, though it earns high marks for 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?
The tool is simple (one parameter, no output schema, no annotations), but the description is still incomplete. It does not explain what a filter group is, what 'details' includes, whether the tool returns the full resource or a partial representation, or any relationship to sibling tools like list_filter_groups. The description is too thin for a meaningful API call.
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 parameter 'id' with 100% schema description coverage, so the schema already documents the parameter. The tool description adds the context that 'id' refers to a filter group, but does not provide additional semantic details beyond what the schema and tool name already imply. Baseline 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 "Get filter group details" clearly states a get operation on a filter group resource. It distinguishes from list_filter_groups (which lists all) by implying a single resource lookup, but "details" is vague about the specific returned fields.
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 use this tool versus alternatives like list_filter_groups or identify any prerequisites or context. The sentence simply restates the tool's purpose without exclusions or alternative tool references.
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 responsibility for behavioral disclosure. It only restates the function without mentioning read-only nature, permission requirements, potential errors, response format, or what 'details' encompass. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 sized for a simple getter, though it borders on being too sparse and does not add much 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?
With no output schema and one parameter, the description should at least summarize what 'details' are returned or any important behaviors, but it does not. It also fails to connect to sibling tools like list_meta_imports, leaving the agent without context on what a metadata import job is or what fields to expect.
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% for the single 'id' parameter, so the schema already documents its meaning. The description adds no extra semantic information about the parameter, and 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 ('Get') and identifies the resource ('metadata import job'), making it clear this tool retrieves details of a single import job. It does not explicitly differentiate from sibling list_meta_imports, but the singular 'details' implies one specific job.
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 alternatives like list_meta_imports or get_meta_download_columns. The description implies it is for an individual job but does not state prerequisites, exclusions, or context in which other tools should 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 the full burden but only restates the purpose. It does not disclose expected behavior such as error handling, required permissions, or return structure, offering no additional transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, using four words to convey the core purpose. While brief, it avoids redundancy but arguably sacrifices useful context, earning a moderate 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 no annotations, no output schema, and minimal description, the documentation is incomplete. It fails to specify what 'details' are included, how to identify a rights package, or any prerequisites, leaving the agent under-informed for correct invocation.
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 fully documents the single 'id' parameter with a description ('ID of the resource'), and the description adds no extra meaning. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get rights package details' clearly indicates the action (get) and resource (rights package), distinguishing it from siblings like list_rights_packages and create_rights_package by implying a single-item fetch. It is specific and uses a proper verb+resource structure.
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 list_rights_packages for listing or create_rights_package for creation, leaving the agent without contextual cues 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?
No annotations exist, so the description carries the full burden of behavioral disclosure. It only implies a read-only operation via 'Get' but does not disclose pagination behavior, sorting, response content, or error handling, 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, front-loaded sentence with zero wasted words. It is efficient, though it could include more context without losing 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?
For a tool with no output schema and no annotations, the description under-specifies resource identification and pagination behavior. The id parameter is ambiguous, and no return details are provided, making the description insufficient for reliable invocation.
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 already describes all three parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter meaning; in particular, it does not clarify that 'id' means 'webhook ID'.
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?
Description states a specific verb 'Get' and resource 'webhook delivery logs', clearly differentiating from sibling get_webhook, which returns webhook configuration. However, it does not explicitly state that the id parameter refers to the webhook, leaving slight ambiguity about 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 on when to use this tool versus alternatives like get_webhook or list_webhooks. There is no mention of 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, the description carries the full burden of behavioral disclosure, but it only repeats the name's implication of listing. It does not mention pagination, filtering semantics, return structure, nesting behavior, or any side effects or permissions needed.
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 of five words. It is front-loaded with the action and resource, with no wasted words. 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?
For a list tool with no output schema and no annotations, the description is too minimal. It does not explain what a 'collection' represents in this context, how pagination works, whether nested collections are included, or what the response looks like. The basic purpose is stated, but nothing else.
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 covers 75% of parameters, but the description adds nothing beyond the schema. The parent_id parameter is undocumented in both the schema and description, and the description provides no context for how q, page, per_page behave in relation to listing collections.
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 'List' with the resource 'collections' and the scope 'organization'. This clearly distinguishes it from sibling list tools for lightboxes, storage folders, and tags, 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 like get_collections_tree or get_collection. There are no exclusions, prerequisites, or context hints to help an agent choose the correct 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 must carry the full burden of behavioral disclosure. It implies a read-only listing operation but does not state behavior such as pagination defaults, sorting, or response format. This is a minimal disclosure that lacks important context about what the tool actually does.
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 extremely concise—four words—with no filler or redundant content. It is front-loaded with the action verb and clearly communicates the tool's purpose in a single sentence.
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 list tool with no output schema, so the description should provide basic context about return values, pagination behavior, or what a filter group is. The current description is too sparse to fully guide an agent; it does not mention the response structure or any operational details.
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 covers both parameters (page, per_page) with descriptions, so schema coverage is 100%. The description adds no additional meaning about the parameters or their usage, but the baseline of 3 is appropriate since the schema already documents 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 action (List) and the resource (saved filter groups), distinguishing it from sibling tools like get_filter_group or create_filter_group through the verb 'list'. However, it lacks explicit scope details (e.g., 'all') and could be more specific about what constitutes a filter group.
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_filter_group or search-based tools. The description does not mention pagination, filtering capabilities, or prerequisites, leaving users to infer the intended use case.
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 behavioral disclosure. 'List' implies a read-only operation, but the description does not mention whether it returns all memberships or only the current organization's, any required permissions, or pagination behavior. This is a significant gap for a tool with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and free of filler. However, it is extremely sparse; while concise, it does not take advantage of the opportunity to add value in other dimensions. Still, for the dimension itself, it does not waste 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?
Despite the simplicity of the tool, the description lacks context about what a 'membership' refers to, whether it is scoped to the current organization, and the return shape. With no output schema and minimal description, the agent would likely need additional information to use the tool reliably.
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 includes two parameters (page and per_page), both with brief descriptions, giving 100% schema coverage. The tool description adds no additional parameter context, but per the baseline rule, with high schema coverage, this is acceptable at a score of 3.
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 'List organization memberships' uses a clear verb ('List') and a specific resource ('organization memberships'), which distinguishes it from sibling tools like get_membership (singular) and search_memberships. It is concise and unambiguous, though it could be slightly more explicit about scope (e.g., 'all' memberships).
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 find_membership or search_memberships. There is no mention of filtering, pagination, or the typical use case, leaving the agent without context for choosing the right 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?
There are no annotations, and the description does not disclose pagination behavior, return format, ordering, or whether this is a safe read operation. The only hint of behavior comes from the parameter schema (page/per_page), which is not part of the description 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 extremely concise with zero wasted words, but it is a fragment rather than a complete sentence. It is front-loaded and easy to parse, though it lacks the structural completeness that would make it a 5.
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 there is no output schema and no annotations, the description must compensate by explaining what notifications are, how they are returned, or how they relate to other notification features. It fails to do so, leaving the tool's behavior underspecified for an agent.
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 provides descriptions for both parameters (page and per_page) with 100% coverage. The description adds no additional semantic value beyond what the schema states, so the baseline of 3 applies.
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 "List notifications" uses a specific verb and resource, clearly indicating a read-only listing operation. It is distinguishable from the sibling tool get_notification_count, which counts rather than lists, though it does not explicitly differentiate itself from other list_* 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?
No guidance is provided about when to use this tool versus alternatives, nor are any prerequisites or context given. The description simply states the action without explaining scenarios where listing notifications would be appropriate or how it relates to notification count.
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 provided, and the description does not disclose return format, pagination behavior, or whether it includes only regular tags. It merely states the action without behavioral details.
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 concise and to the point.
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 no output schema and no annotations, the description is too sparse. It lacks information about response structure, default page size, and relationship to other tag listing tools, which is important for correct invocation.
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 descriptions cover 100% of parameters (q, page, per_page, tag_import_id), so the tool description does not need to repeat them. However, it adds no extra semantic context about how these parameters interact with the listing.
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 'List' with resource 'tags' and scope 'organization', clearly indicating a read operation. It distinguishes from singular get_tag but doesn't differentiate from list_auto_tags or list_taxonomy_tags among 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 on when to use this tool vs alternatives. The description does not mention any context, exclusions, or alternatives despite many tag-related list tools in 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 provided, the description carries the full burden of behavioral disclosure, but it discloses nothing beyond the basic operation. It does not mention pagination behavior, whether it returns only groups the user belongs to, permissions required, or any side effects. Given that this is a read operation, this gap is notable.
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 concise at four words, and every word earns its place. There is no verbosity or unnecessary detail. However, it is arguably under-specified, which prevents a perfect score, but for a simple list operation it is appropriately sized.
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 output schema and annotations, the description should explain what the tool returns (e.g., a paginated list of user groups) and any important behavioral context. It does not, leaving the agent without enough information to fully understand the tool's output or edge cases. The schema covers parameters, but not the overall result shape.
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 no additional meaning to the parameters (q, page, per_page) beyond what the schema already provides. It does not compensate for any missing parameter context, but no compensation is needed given full 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 the verb 'list' and resource 'user groups' clearly, making the tool's function immediately understandable. However, it does not differentiate this tool from siblings like get_user_group beyond the plural form, which is already in the 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, such as get_user_group for a single group or list_memberships for memberships. The description simply states what it does without any context on prerequisites, 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 available, the description carries the full burden of behavioral disclosure. It only states the removal action without specifying whether it is permanent, reversible, requires permissions, or affects associated assets, leaving significant uncertainty for a mutating operation.
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, focused sentence with no unnecessary words, demonstrating excellent concision. Its brevity is appropriate for the simple operation, though it might border on under-specification.
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 too terse. It fails to explain the concept of 'user-membership association' or how to identify the target, leaving the agent without enough context to confidently invoke the tool, especially with limited parameter clarification.
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 100% coverage for the single parameter 'id' with the description 'ID of the resource,' and the tool description adds no additional meaning. This meets the baseline, though it misses an opportunity to clarify which resource the id refers to (e.g., tag, face, or membership).
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 clear verb ('Remove') and identifies the target resource ('user-membership association from a person tag'). It distinguishes from sibling tools by specifying the removal direction, though the meaning of 'user-membership' could be more explicit.
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 this is the inverse of set_tag_face_membership or clarify when to prefer remove_tag_face_creator_tag.
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 mentions that the cropped frame is indexed into Rekognition, which implies persistence and side effects, but it does not explain whether this operation is reversible, what permissions are needed, or any failure modes. The description is too sparse to fully inform the agent of the tool's behavioral 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, concise sentence that front-loads the primary action ('Manually tag a face track in a video') and then adds a relevant detail (indexing into Rekognition). Every word earns its place, and there is no redundancy or fluff, making it highly 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?
For a mutation tool with 4 parameters and no output schema or annotations, the description is incomplete. It does not explain the return value, whether the operation is idempotent, how duplicate or existing tags are handled, or any prerequisites beyond the person_index. The mention of Rekognition indexing adds some context, but significant gaps remain 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 provides 100% coverage of parameter descriptions, so the baseline is 3. The description does not add meaningful information beyond the schema—it only restates that tagging is manual, which does not clarify parameter semantics further. The person_index parameter is already documented in the schema as coming from face detection.
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 specific action ('manually tag a face track in a video') and identifies the resource (face track in a video). It also mentions indexing into Rekognition, adding clarity on what the tagging accomplishes. However, it does not explicitly distinguish itself from the sibling tool 'tag_asset_face', though 'video' and 'face track' provide some 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?
No guidance is provided on when to use this tool versus alternatives. There are no explicit when-to-use or when-not-to-use instructions, nor are any alternative tools mentioned. The usage context is only implied by the description's wording, which is insufficient for an agent to decide between this and similar face-tagging 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 disclosing mutation behavior, but it only says 'Update a filter group.' It fails to mention partial vs. full update, effects on existing data, required authorization, error conditions (e.g., nonexistent id), or return value. 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 concise sentence with no filler words. It clearly conveys the core action and resource in four words, which is appropriately sized for a simple update tool. It is not overly verbose, 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?
Despite being a simple update, the tool has three parameters, no output schema, and no annotations. The description provides no information about prerequisites, side effects, or what fields are updatable. For a mutation tool, this level of under-specification leaves the agent without enough context to invoke it correctly, especially regarding required permissions or return payload.
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 covers 67% of parameters with descriptions (id and filter_order), leaving only 'name' undocumented but self-explanatory. The description adds no semantic detail about parameters, but the schema already conveys much of the meaning, so the description does not need to compensate heavily. The baseline of 3 applies due to substantial 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 ('a filter group'), making it distinct from create, get, list, and delete siblings. However, it does not specify what aspects can be updated (e.g., name, filter order), so it lacks the specificity to fully distinguish from related updates like update_filter_group_visibility.
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 this is for existing filter groups, nor does it exclude cases like updating visibility. The description offers no context for selection among the many filter group and update tools in the sibling list.
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. 'Set the column mapping' simply states the action without revealing side effects (e.g., overwrites existing mappings), requirements (e.g., job state), or what happens on success/failure. This is minimal transparency 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.
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 verb and resource, making it easy to scan. 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 tool has a nested object parameter and no output schema or annotations, the description is too sparse. It doesn't explain what constitutes a valid column mapping, when in the tag-import lifecycle this should be called, or what the client can expect back. The agent is left without enough context to use the tool correctly in a multi-step workflow.
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 no parameter-specific meaning beyond what the schema provides. The schema already documents 'id' and 'column' at a basic level, but the nested properties (name, mapping) within 'column' lack detailed descriptions. Since schema coverage is high (100%), the baseline is 3, but the description does not enhance 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 uses a specific verb ('Set') and identifies the resource ('column mapping for a tag-import job'), which clearly distinguishes it from related tools like update_tag_import or start_tag_import. It is not entirely precise about what 'column mapping' entails, but the core purpose is 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?
There is no guidance on when to use this tool versus alternatives, prerequisites, or how it fits into the tag-import workflow. No exclusions or alternative tool names are mentioned, leaving the agent to infer usage from the name and 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 provided, the description carries full burden for behavioral disclosure. 'Update' implies mutation but doesn't explain what happens to existing fields if omitted, whether the update is partial or full replacement, auth requirements, or side effects on dependent resources. It mentions only 'name, description, etc.' without elaborating on behavior beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, efficient and to the point. It front-loads the verb and resource. However, the 'etc.' is ambiguous and could be replaced with more concrete fields, but given the simplicity, it remains 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?
This is an update (mutation) tool with no annotations and no output schema. The description only minimally identifies the action and fields. For a tool with 3 parameters, it lacks guidance on required versus optional parameters, partial update semantics, and potential errors. It is a minimal viable description but clear gaps exist.
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 description coverage is only 33% (only the 'id' param is described). The description adds that 'name' and 'description' are updatable taxonomy fields, providing some context beyond the schema's bare property names. However, it doesn't clarify whether 'id' is a numeric ID or string slug, nor any constraints on name/description (e.g., uniqueness, length). The 'etc.' is vague. Overall, it partially compensates but leaves gaps.
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 taxonomy and lists example fields (name, description). It uses a specific verb+resource and distinguishes from sibling tools like create_taxonomy, delete_taxonomy, and update_taxonomy_tag, though it doesn't explicitly differentiate those.
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. It lacks context about prerequisites (e.g., taxonomy must exist), typical use cases, or why one might choose update_taxonomy over update_taxonomy_tag or bulk_update_tags.
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 the operation is an update and lists updatable fields, but does not disclose permissions, idempotency, partial update behavior, reversibility, or return values. 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 sentence with no filler. It is front-loaded with the action and resource, and the parenthetical efficiently conveys the scope. This is appropriately concise for a simple CRUD operation, even though more detail would be useful.
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 no annotations, no output schema, and only partial schema descriptions, the description is incomplete. It lacks usage guidelines, behavioral details (permissions, side effects, error handling), and return value expectations. For a mutation tool, this is insufficient context for an agent to safely and correctly invoke it.
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 low (33%), but the description adds meaning by identifying 'name' and 'description' as updatable fields, which partially compensates for the missing schema descriptions. However, it does not explain the semantics of these fields (e.g., what 'description' means in context) or any constraints beyond what the schema already states.
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 ('user group'), with a parenthetical listing updatable fields ('name, description, etc.'). This is a clear verb+resource statement, though it lacks explicit differentiation from sibling update tools (e.g., update_membership, update_lightbox) and the 'etc.' is 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?
The description provides no guidance on when to use this tool versus alternatives, such as create_user_group or delete_user_group, nor any prerequisites like requiring an existing user group ID. There is no mention of context, 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 present, so the description carries full responsibility for behavioral disclosure. It states the action (send invoice) but does not explain consequences (e.g., whether budget is added immediately, if payment is collected, or if it creates a charge). For a financial mutation, this lack of side-effect disclosure 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, front-loaded sentence with no filler. It efficiently communicates the actor, action, and object, 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 tool's financial nature, no output schema, and minimal annotations, the description is too sparse. It leaves critical unknowns: what happens after sending the invoice, whether the budget is immediately added, and any return values. It provides only basic context and does not fully enable an agent to understand the tool's place in a workflow.
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 67% schema description coverage, the schema already explains 'id' and 'amount'. The description adds minimal parameter context: it implies 'id' is an organization and 'amount' is the top-up value, but it does not clarify the ambiguous 'description' parameter or any required relationships. It does not compensate for the missing description of the third 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 uses a specific verb ('send') and resource ('Stripe invoice for a CAI budget top-up'), making the core action clear. It also adds a role qualifier ('Super-admin'). However, it does not explicitly distinguish itself from the sibling 'grant_organization_cai_budget', which likely has a similar 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 states the intended actor ('Super-admin') but provides no guidance on when to use this tool versus alternatives like 'grant_organization_cai_budget' or 'mark_organization_cai_invoice_paid'. It implies usage for top-up invoicing but does not mention exclusions or alternative choices.
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, but it only states the basic create action. It does not mention side effects, required permissions, whether it is idempotent, or what response to expect. This is a significant 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.
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 wasted words. It clearly and concisely conveys the tool's core purpose without unnecessary 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?
The tool has 9 parameters and no output schema, but the description provides minimal context. It does not explain the role of webhooks, how the event list works, or what happens after creation, leaving significant gaps that the schema alone cannot fill.
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 covers all 9 parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score 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 tool creates a webhook, with the specific purpose of receiving event notifications. This distinguishes it from sibling tools like list_webhooks, get_webhook, and delete_webhook, which are operationally different.
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 does not provide any explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or alternatives. It implies usage via the action 'create a webhook', but offers no context beyond that.
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 restates the tool's name with a generic verb and adds no context about permanence, side effects, authorization requirements, or consequences of deleting a tag.
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. It contains no unnecessary words or repetition, making it highly 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?
For a destructive tool with no annotations or output schema, the description is too sparse. It does not disclose whether deletion is permanent, whether it cascades to associated assets, or if special permissions are required. A minimal context of 'Permanently deletes' or 'This cannot be undone' 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 includes a description for the only parameter, 'id', as 'ID of the resource', which is generic but provides some baseline meaning. The tool description does not add tag-specific parameter context. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a tag' uses a specific verb (delete) and resource (tag), clearly distinguishing it from sibling tools like create_tag, update_tag, and get_tag. It precisely 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 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 bulk_delete_tags or delete_tagging. It does not mention any specific context, prerequisites, or situations where another tool 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 provided, the description carries the full burden. It only restates the tool name and gives no information about pagination defaults, ordering, filtering, what kinds of jobs are included (e.g., all statuses), or any permissions required. The word 'list' implies read-only, but nothing else is disclosed.
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 short (four words), which is concise, but it essentially repeats the tool name and contributes no extra information. It is not verbose, but it also does not earn its place by adding value, landing at a middle 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?
Given the tool has no annotations and no output schema, the description alone is insufficient. It does not explain what a 'tag-import job' is, what data the list returns, or any caveats. For a simple listing endpoint, more detail would be expected to make it usable.
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% for both parameters (page and per_page), so the schema already documents their meaning. The description adds no additional context about how these parameters affect the listing, staying at the baseline 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 'List tag-import jobs' is specific: verb 'list' plus resource 'tag-import jobs'. It clearly distinguishes from singular get_tag_import and mutation tools like create/update/delete in the sibling list.
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. It does not mention that this is for enumerating tag imports, nor does it contrast with get_tag_import or list_meta_imports. No exclusions or contextual triggers 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 must disclose behavior. It only states 'List', which implies a read operation, but gives no detail on pagination, hierarchy handling, or response format. The presence of a parent_id parameter suggests hierarchical behavior that is not mentioned.
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, directly front-loaded with the action and resource. It contains no filler and is appropriately 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?
For a tool with 4 parameters and no output schema, the description is too sparse. It omits pagination behavior, the role of parent_id, and how it relates to taxonomy tree tools like get_taxonomy_tags_tree, leaving agent understanding incomplete.
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 75% (page, per_page, taxonomy_id have descriptions; parent_id does not). The description adds no parameter information, leaving the undocumented parent_id without contextual clues.
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 'List tags within a taxonomy' uses a specific verb and clearly indicates the resource and scope. It distinguishes from sibling list_tags by explicitly scoping to a taxonomy, though it doesn't 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing tags within a taxonomy, but provides no explicit guidance on when to use this tool versus alternatives like list_tags or get_taxonomy_tags_tree.
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 without disclosing side effects, permissions, idempotency, or result details. The term 'taxonomy_tag' is left undefined, leaving ambiguity about what the operation actually does.
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 redundant information. It is well-structured and to the point.
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 and no annotations, and the description does not explain what a 'taxonomy_tag' is, what happens after the operation, or any prerequisites. This leaves significant gaps for an agent attempting to use 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 50%, with 'id' described generically as 'ID of the resource' and 'taxonomy_id' lacking a description. The description implies that 'id' refers to the tag and 'taxonomy_id' to the taxonomy, but this is implicit and not clearly articulated.
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 and resource: 'Add an existing tag to a taxonomy as a taxonomy_tag.' It clearly distinguishes from sibling tools like create_taxonomy_tag by specifying 'existing tag' and 'to a taxonomy.'
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 is provided on when to use this tool versus alternatives. The description implies a usage scenario but does not state exclusions or compare with related tools like create_taxonomy_tag.
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 behavioral disclosure. It does not mention that this action likely sends an email, creates a pending invite record, or requires specific permissions. The description simply restates the action without revealing side effects, reversibility, or the state of the created invite. This is a significant 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, short sentence, which is concise, but it is also under-specified, relying almost entirely on the tool name and schema for meaning. It is not poorly structured, but it does not earn its place by adding unique information. It is acceptable but not exemplary.
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 no output schema and no annotations, the description should provide more context about the invite lifecycle, return value, and restrictions. It does not mention that multiple email addresses can be invited at once, that role_level must be an available role, or that the invite will need acceptance. For a tool with 3 parameters and no output schema, this is incomplete.
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 description coverage is 67%, covering email and note but leaving role_level (an enum with no description) unexplained. The description adds no parameter-level meaning; it does not clarify role_level values, the comma/semicolon multi-email format, or the optional note's purpose. Since the description does not compensate for the uncovered parameter, it fails to provide value 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 'Invite a user to the organization' clearly states the action (invite), the target resource (user), and the scoping context (organization). It distinguishes from sibling tools like create_asset_group_invite (which invites to an asset group) and accept_invite (which accepts an invitation). This is a specific verb+resource construction that leaves no ambiguity.
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 usage for creating an invite, but provides no explicit guidance on when to use it versus alternatives such as list_invites, resend_invite, or check_invite_email. There are no prerequisites, exclusions, or alternative tool mentions. The usage context is implied but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It does not disclose whether the job is asynchronous, what side effects occur, whether permissions are required, or what the response contains. It only explains that a job is created and the file reference format.
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 long, with the purpose front-loaded and a concise elaboration on the main parameter. No 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?
Given that this is a create operation with no output schema and no annotations, the description is too sparse. It does not explain job semantics, required permissions, or the interplay between `columns` and `name_column`. The missing `note` description is also unaddressed.
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 description clarifies the `file` parameter as a CSV/XLS reference with S3 key or upload id, which goes beyond the schema's 'Uploaded file reference'. However, it does not address the `note` parameter, which has no schema description, and only minimally reuses schema descriptions for `columns` and `name_column`.
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 'Create a tag-import job' with a specific verb and resource. It distinguishes from single-tag creation tools like create_tag by referencing the import job concept, though it 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 such as create_tag or start_tag_import. The only contextual hint is the file parameter description, but no explicit usage scenarios or exclusions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and typical attachments, without mentioning required permissions, side effects, idempotency, or 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, which is front-loaded, but it is under-specified for a tool with five parameters and no other documentation. It could be improved with additional details without losing 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?
For a mutation tool with no annotations, no output schema, and low parameter coverage, the description is incomplete. It does not explain when to use the tool, what permissions are needed, what the return value looks like, or the meaning of half the parameters.
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 five parameters with zero descriptions, so the description must compensate. It implicitly mentions workflow and asset_group but leaves name, position, and preserve_subfolders undefined. This is inadequate given 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 uses a specific verb ('Create') and resource ('workflow step'), and the parenthetical clarifies the typical attachments to workflow and asset_group. This clearly distinguishes it from sibling tools like update_workflow_step, delete_workflow_step, and get_workflow_step.
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 no explicit guidance on when to use this tool versus alternatives such as update_workflow_step, though the verb 'create' implies it is for new steps. It mentions typical attachments but lacks prerequisites or exclusion criteria, leaving usage context largely implicit.
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 burden of disclosing behavior. It only says 'get extracted text content' and does not clarify that this is a read-only operation, what permissions are needed, or what the return format is. Minimal 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?
The description is a single, concise sentence that front-loads the action and resource, with no wasted 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 tool with one parameter and no output schema, the description gives the core information but lacks disambiguation from the similar get_asset_ocr_content tool. It also does not specify the format or limitations of the returned text, making it adequate but not comprehensive.
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 fully describes the single 'id' parameter (100% coverage), so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already states.
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 goal: retrieving extracted text from document assets. It names the resource type (PDF/DOCX) and the action, but it does not explicitly differentiate from similar tools like get_asset_ocr_content.
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 merely states what it does, without mentioning 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 carries the full burden for behavioral disclosure. It only says 'Get face taggings' without describing return format, pagination, permissions, or any side effects. The 'get' implies read-only, but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no extraneous words. It is front-loaded and directly conveys the purpose, earning the maximum score for conciseness and structure.
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 a single-parameter getter with no output schema, the description is minimally adequate. However, it lacks behavioral context and does not explain what a 'tagging' is or what the response contains, leaving some 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 100% with a single 'id' parameter described as 'ID of the resource'. The tool description adds some clarity by indicating the resource is an asset, but it does not provide further details about the ID format or usage beyond what the schema already implies. Baseline 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 clearly states the action ('Get') and the resource ('face taggings' for an 'asset'), which is specific enough to distinguish from related tools like get_asset_auto_tags or get_asset_content. However, it does not explicitly name alternatives or elaborate on scope, 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. Sibling tools include various face-related and asset-related operations, but the description provides no context about when this should be preferred or what prerequisites 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 must carry the full burden of behavioral disclosure. 'Get lightbox details' implies a read-only operation, but it does not clarify what 'details' entail, whether any authorization is needed, or what happens for invalid IDs. The lack of any behavioral context makes this insufficient.
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 filler words, making it appropriately sized for a simple getter. However, it is so minimal that it might under-specify the tool's behavior, preventing a perfect 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 tool is simple (one parameter, no output schema, no annotations), but the description is too sparse to be considered complete. It does not explain what a lightbox is, what details are returned, or any usage context, leaving gaps that the agent must guess.
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 provides 100% coverage for the single 'id' parameter, describing it as 'ID of the resource'. The description adds no additional parameter semantics, but given the simplicity and clear schema, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 clear resource 'lightbox', making it evident that this tool retrieves a single lightbox. It distinguishes itself from siblings like list_lightboxes (which lists) and create/update/delete_lightbox (which mutate).
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 list_lightboxes or get_lightboxes_tree. There is no mention of prerequisites, 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?
No annotations are present, so the description must disclose behavior. It states 'Get membership details' which implies a read-only operation, but it does not explicitly confirm safety, describe the return payload, error conditions, 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 with no redundant content or unnecessary details.
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 fully-specified parameter, but the description lacks details about the return value and does not disambiguate from other membership-related tools. Given no output schema, the description is adequate but minimal.
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 fully describes the 'id' parameter ('ID of the resource'), and the description adds only 'by ID', which is redundant. No additional meaning is provided 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 'Get membership details by ID' clearly identifies a read operation targeting a single membership resource. However, it does not explicitly differentiate from sibling tools like find_membership or search_memberships, which may perform similar lookups.
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, filtering, or cases where list_memberships or find_membership 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?
No annotations are provided, so the description carries the full burden. It simply restates the operation without disclosing that it is read-only, what the return value contains, or any error behavior. This adds minimal transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence containing the resource and key qualifier. It is appropriately sized for a simple getter, though it errs on the side of terse rather than informative.
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 many sibling tools sharing the 'share' concept, the description is incomplete. It does not clarify what a 'share' is, what fields are returned, or how it relates to tools like get_share_status or list_shares. With no output schema, this lack of context hampers correct tool selection.
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% and the id parameter is already described. The description's 'by id' adds little beyond the schema, satisfying the baseline but not enriching the parameter 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 clearly states the tool retrieves a share by its id, using a specific verb and resource. However, it does not differentiate from sibling tools like get_share_status or get_share_html, so it loses the fifth point for lack of explicit distinction.
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: call this tool with a share id to get the share object. But it provides no explicit guidance on when to choose this over related tools (e.g., get_share_status) 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.
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 mentions that both pending and accepted invites are returned, but it does not explain the scope (e.g., whether these are all invites in the organization or just the current user's), required permissions, or the response format. This lack of detail is a significant gap for a 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 a single concise sentence of 12 words, clearly front-loaded with the verb and resource. It conserves space while conveying the essential purpose. There is no redundancy or filler.
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 list tool with no output schema and only two optional pagination parameters. The description tells what it lists but does not state the scope (e.g., organizational vs. personal), pagination behavior, or return structure. It is minimally adequate but lacks context that an agent would benefit from.
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 provides descriptions for both page and per_page, giving 100% schema coverage. The description adds no additional meaning about these parameters, so it does not go beyond what the schema already communicates. A baseline of 3 is appropriate when the schema handles parameter 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 clearly states the verb 'List' and the resource as invitations to collections, lightboxes, and storage folders, with a scope of pending and accepted statuses. This distinguishes it from sibling tools like list_invites or list_my_invites by specifying the target types, though it does not explicitly name a direct 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 provides no guidance on when to use this tool versus alternatives. It does not mention any context such as filtering, prerequisites, or exclusions. The only implication is that you use it when you need to list these invites, but that is directly inferred from the purpose statement.
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 only the operation and scope, but does not describe return format, pagination, read-only behavior (though 'list' implies it), or how the scope is determined given the empty parameter schema.
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?
One short sentence, front-loaded with the verb and object. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 no output schema and no annotations. It doesn't explain what constitutes a contribution, what the response contains, or how the scope is applied. Given the large sibling set, more context is needed.
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?
There are zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter semantics and doesn't explain how the agent specifies a particular collection/lightbox/folder, but since there are no params, there is nothing to document.
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 list operation on contributions scoped to a collection/lightbox/folder. This distinguishes it from broader list_contributions and more specific list_lightbox_contributions, though it doesn't explicitly name these 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 on when to use this tool vs. alternatives. The description provides no context, prerequisites, or exclusions, leaving the agent to infer usage from the name and scope.
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. The description only restates the tool's function and adds no information about return format, pagination, ordering, permissions, or whether this is a read-only operation. It is too minimal to be transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no filler or redundancy. It is front-loaded and appropriately sized for a tool with no parameters.
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 low complexity, the description is ambiguous about what 'contributions tied to lightboxes' actually means—does it list all contributions in any lightbox, or contributions of lightbox members? With no output schema and no parameter to specify a lightbox, the agent cannot infer request/response semantics. Sibling tools with similar names (list_contributions, list_group_contributions) further confuse the context.
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 input schema has zero parameters with 100% schema description coverage. The baseline for 0 parameters is 4. The description adds no parameter details, but none are needed since there are no parameters. It does clarify the scope ('tied to lightboxes'), which is the only semantic possible.
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 ('List') and resource ('contributions') with a clear scope ('tied to lightboxes'). It is clear and not a tautology, but it does not explicitly distinguish itself from sibling tools like list_contributions, list_featured_contributions, or list_group_contributions, so it misses the top 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?
There is no guidance on when to use this tool instead of alternatives. With many sibling list tools, the absence of any context about filtering, prerequisites, or alternative tools leaves the agent without direction. 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?
No annotations are provided, so the description carries the full burden. It mentions 'background' and 'List', hinting at async jobs, but does not disclose response format, pagination behavior, or access requirements. It does not explicitly state that the operation is read-only, though listing implies it.
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, front-loaded with 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 list tool, the purpose and basic parameters are covered. However, without annotations or an output schema, more detail would be valuable—such as what fields a job includes, whether results are paginated (implicit via per_page), and any behavioral notes.
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 75% (page, dates, per_page documented). The description adds no parameter context beyond what the schema provides. The undocumented user_id parameter is not compensated for in 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 uses a specific verb 'List' and resource 'background metadata-export jobs', clearly indicating the operation. It distinguishes this from sibling tools like list_meta_imports (imports vs exports), though it 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?
There is no guidance on when to use this tool versus alternatives such as list_meta_imports or get_meta_download_columns. The description does not mention filtering, pagination, or whether it lists all jobs or only the caller's.
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, but it only states 'List rename presets.' It does not mention pagination, filtering, return format, or whether it is read-only. While 'list' implies a read operation, no explicit behavioral details are given.
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 wasted words, front-loading the verb and resource. However, it is too spare to be considered exceptional, but it earns points for efficiency and clarity.
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 and the description does not explain what rename presets are, how pagination works, or how it relates to other rename preset tools. For a simple list tool, the description is still too sparse to give the agent a complete picture.
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% for all three parameters (page, enabled, per_page), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, so it neither enhances nor detracts.
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 'List rename presets' clearly states the verb (list) and resource (rename presets), distinguishing it from siblings like get_rename_preset and list_crop_presets. 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 such as get_rename_preset or list_crop_presets. The description does not mention any context, prerequisites, or exclusions, leaving the agent without decision-making 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 only states 'List saved search queries' and provides no details on pagination behavior, return format, ordering, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It efficiently states the action but omits potentially useful context, making it slightly under-specified for its 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 lack of output schema and annotations, the description is incomplete. It does not specify what the response contains, whether results are ordered, or any filters beyond pagination. For a listing tool, essential return-value context is missing.
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 complete coverage of both parameters (page and per_page) with descriptions. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('saved search queries'), clearly indicating the action and object. It distinguishes from sibling tools like create/update/delete/get_search_query by implying a read-only collection 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. It does not mention distinctions from similar listing tools like list_filter_groups or explain under what circumstances this should be called.
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?
The description adds no behavioral context beyond the basic 'List' action. It doesn't disclose pagination behavior, permissions, read-only status, or return format. Since no annotations are provided, the description carries full responsibility and falls short.
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, front-loaded, with no unnecessary words. Every word contributes to the meaning.
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 two optional pagination parameters and no output schema, the description conveys core purpose. However, it omits any details about return structure or pagination behavior, which leaves some gaps but is acceptable for a minimal list 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 input schema has 100% coverage for both parameters ('page' and 'per_page') with clear descriptions, so the tool description doesn't need to add param info. Baseline 3 is appropriate as the schema does 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 states a clear verb ('List') and resource ('taxonomies'), with a clarifying parenthetical ('controlled vocabularies'). This distinguishes it from sibling tools like 'list_tags' or 'list_collections', 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. It doesn't mention any exclusion criteria, prerequisites, or contexts 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?
No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits beyond the implied mutation: no mention of side effects (e.g., invitation status changes), auth requirements, or potential errors. The description essentially restates the tool name without adding transparent details.
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. It efficiently states the action, resource, and parameter requirement.
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 tool, the description covers the core action and parameter. However, it lacks usage context (e.g., when to call it), return value information (no output schema), and side-effect transparency. It is adequate but minimal, leaving the agent to infer some necessary details from the tool name and siblings.
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 already provides 100% coverage for the single 'id' parameter, but its description ('ID of the resource') is generic. The tool description adds meaning by clarifying that the id refers to the pending org invitation, which helps the agent understand what to pass.
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 ('accept') and the resource ('pending org invitation') with the identifier ('by id'). It does not explicitly distinguish from the sibling tool 'accept_invite', but the specific resource type helps. The tool name includes 'my' which hints at the user's own invite, but the description omits that qualifier.
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 'accept_invite', nor does it mention prerequisites such as having a pending invite or how to obtain the id (e.g., via 'list_my_invites'). It only states the action.
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 bears full burden for behavioral disclosure, but it only restates the operation. It omits important traits such as whether duplicates are allowed, permission requirements, idempotency, or what happens if the lightbox or asset 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, concise sentence that is front-loaded with the verb and object. There is no extraneous information or repetition, making it efficiently scannable.
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 is a mutation with no annotations and no output schema, yet the description provides only the basic action. It lacks information about return values, errors, side effects, or operation semantics, which are important for an agent to safely invoke the 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 description coverage is 100% with both parameters described as 'ID of the resource', which is generic. The description adds no further meaning about which ID corresponds to the asset versus the lightbox. Baseline 3 is appropriate given high schema coverage, though the descriptions are unhelpful.
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 'Add an asset to a lightbox' uses a specific verb and resource, clearly stating the action. It distinguishes itself from sibling tools like 'add_asset_to_collection' and 'remove_lightbox_membership_assets' by naming the target container (lightbox) explicitly.
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 are there any prerequisites or conditions mentioned. The description solely states the action without any context on appropriate scenarios, edge 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether duplicate links are prevented), permission requirements, or the response format. Minimal insight into what happens upon creation.
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 appropriately front-loaded with the primary action and target. No filler or redundant 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?
This is a creation tool with 7 parameters and no output schema or annotations. The description does not mention return values, permission requirements, or edge cases. It is adequate for a simple action but lacks context for effective tool selection.
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 each parameter already has a description. The tool description adds no extra semantic value beyond naming the target resource types, which is already in the asset_group_id parameter description. Baseline 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 uses a specific verb ('Create') and a clear resource ('share link'), and specifies the target resource types ('Collection, Lightbox, or Storage Folder'). This clearly distinguishes it from sibling tools like delete_share_link and create_share.
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 alternatives. It does not mention that this creates a share link for asset groups specifically, or any prerequisites or conditions. Siblings like create_share and create_asset_group_invite exist but their relationship is not addressed.
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 side effects. It only repeats the action without stating whether deletion is permanent, requires permissions, or affects associated data. 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, concise sentence with no unnecessary words. It is 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?
For a simple destructive tool with no annotations or output schema, the description is too sparse. It omits important context such as irreversibility, permission requirements, or the distinction from revoke_access_request, making it incomplete for safe invocation.
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 fully describes the single 'id' parameter (100% coverage), so the baseline is 3. The tool description adds no further clarification, and the schema's 'ID of the resource' is generic but usable.
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 an access request.' uses a specific verb and resource, clearly distinguishing it from siblings like create, update, or revoke. It is a precise statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 revoke_access_request or finalize_access_request. The description does not mention any prerequisites or context for deletion.
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 bears full responsibility for disclosing behavioral traits. It only states 'Delete' without mentioning irreversibility, permission requirements, or potential side effects on assets using the preset. This is a destructive operation with no warning about permanent consequences.
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 perfectly communicates the essential action for a simple deletion tool, achieving high conciseness without sacrificing clarity.
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 no annotations and no output schema, the description is incomplete for a mutation tool. It conveys the basic action but does not explain return behavior, failure modes, or any prerequisites such as whether the preset must exist. This leaves the agent without adequate information for robust invocation.
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 defines the 'id' parameter with a clear description ('ID of the resource'). Schema coverage is 100%, so the description adds no additional parameter meaning, but the baseline of 3 is appropriate since the schema carries the semantics effectively.
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' with a clear resource 'rename preset', directly stating the action. It distinguishes itself from sibling tools like create_rename_preset, update_rename_preset, and get_rename_preset by uniquely indicating 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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, consequences, or cases where deletion should be avoided, leaving the agent without contextual 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 behavioral disclosure. It only states that a saved search query is deleted, but does not indicate whether deletion is permanent, requires confirmation, or has side effects on related data. This lack of transparency could lead an agent to misuse the 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 wasted words. It states the essential action and resource efficiently, 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 delete operation with no annotations and no output schema, the description is too sparse. It fails to mention that deletion is likely irreversible, any necessary permissions, or what happens after the operation. This is a significant gap for a mutation tool, making the description incomplete for an agent deciding whether and how to invoke it.
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 for the single 'id' parameter, but the description itself adds no additional meaning beyond the schema's generic 'ID of the resource.' The schema already documents the parameter, so the baseline of 3 is appropriate, though more specific parameter context (e.g., tying the ID to a saved search query) would improve it.
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 resource ('saved search query'), clearly distinguishing it from sibling tools like create_search_query, get_search_query, and update_search_query. It is unambiguous about what operation is performed.
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 are any prerequisites or contextual conditions mentioned. The description simply states the action without explaining when deletion is appropriate or what constraints apply.
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, and the description does not disclose whether the deletion is permanent, reversible, or has side effects. It only says 'Delete a workflow step', which conveys the basic action but no additional 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.
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 without unnecessary words. It is well-structured and front-loaded, though it could benefit from a brief caveat about deletion consequences.
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, the description and schema together provide the core requirement (the id). However, it omits important caveats such as permanence, permissions, or whether the operation is reversible, which would make it more 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 parameter with a description ('ID of the resource'), giving 100% coverage, so the baseline is 3. The tool description adds no parameter-specific details, and the schema's generic description is adequate but not enhanced.
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' and names the resource 'workflow step', making the tool's purpose immediately clear. It also distinguishes itself from other delete tools in the sibling list, such as delete_asset and delete_workflow.
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 any prerequisites. The description simply states the action without indicating 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 carries the full burden of disclosure, but it only says 'Get' implying a read operation. It does not mention permissions, side effects, response format, or any special behavior. This is minimal 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 is front-loaded with the verb and resource. Every word adds value, with no wasted phrasing.
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 getter with one parameter, the description is thin. It does not explain what auto tags are, nor does it clarify the return shape (list vs. individual). Given the abundance of sibling tools, it could benefit from distinguishing itself more explicitly from related auto-tag operations.
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 for the single 'id' parameter, so the baseline is 3. The description adds that the id refers to an asset, which clarifies the generic 'ID of the resource' schema text, but does not provide additional depth beyond that.
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 ('AI-generated auto tags for an asset'). It distinguishes itself from similar tools like get_auto_tag (single auto tag) and list_auto_tags (all auto tags) by specifying it applies to a particular 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 such as get_auto_tag or list_auto_tags. The description does not mention exclusions or context in which this tool is 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 provided, the description must disclose behavioral traits itself. It only states the action without mentioning whether the operation is read-only, requires authentication, or has side effects (e.g., generating a new URL vs. returning an existing one). No details about response format or error behavior are included.
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 with no unnecessary words. It is efficiently front-loaded and conveys the core purpose immediately.
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?
Although the tool is simple, the description omits important context: the behavior of the 'size', 'watermarked', and 'version_number' parameters, the format of the returned URL, and any differences from sibling tools like 'generate_url'. Without an output schema, the description should explain return semantics, 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 input schema provides descriptions for all four parameters (id, size, watermarked, version_number), and schema coverage is 100%. The description adds no extra meaning beyond what the schema already declares, 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 tool's function: retrieving a download URL for an asset. It uses a specific verb ('Get') and identifies the resource ('download URL for an asset'), which distinguishes it from siblings like 'get_asset' (metadata) and 'bulk_download_assets' (bulk 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 such as 'get_asset_content', 'create_download', or 'get_download'. The description lacks context about prerequisites, use cases, or exclusions, leaving the agent without direction for selecting among 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 provided, and the description only states the core function. It doesn't disclose behavior such as whether the operation is read-only, error conditions, or what the response format might be.
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 concise and front-loaded. It avoids unnecessary words and directly conveys the tool's purpose.
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 low complexity (one parameter, no output schema or annotations), the description is reasonably complete. It indicates the output is text but doesn't cover edge cases or error scenarios; however, these are less critical for a simple getter.
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's description covers 100% of the single parameter ('ID of the resource'), so the description doesn't need to add parameter details. The schema is sufficient, and the description doesn't conflict or add extra.
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 OCR-extracted text from an image asset, using a specific verb and resource. It is distinct from siblings like get_asset_content by emphasizing OCR, though it doesn't explicitly differentiate from other asset getters.
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 doesn't mention prerequisites, exclusions, or when to prefer other tools like get_asset_content.
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 simply says 'Get queue position', implying a read-only operation, but does not disclose any behavioral details such as whether the job must be in a specific state, how the position is represented, or that it does not mutate the job. The minimal wording leaves room for ambiguity about side effects or prerequisites.
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. Every word is necessary, and there is no extraneous 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?
The description is extremely brief for a tool with no output schema and no annotations. It does not explain what 'queue position' means, the expected return format, or whether the job must be in a certain state. An agent would have to guess at the semantics. Given the simplicity of the tool, some clarification about the return value and usage context would make it 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 provides 100% coverage for the single 'id' parameter, describing it as 'ID of the resource'. The description adds the context that this is a bulk job, which slightly clarifies that the id refers to a bulk job ID, but it does not explain the format, constraints, or how to obtain the id beyond what the schema states. Baseline 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 'Get queue position for a bulk job' clearly states the specific verb ('Get') and resource ('queue position for a bulk job'). It is distinct from sibling tools like get_bulk_job (which retrieves job details) and list_bulk_jobs (which lists jobs).
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 does not provide guidance on when to use this tool versus alternatives. It does not mention that it is appropriate for checking the progress of a submitted bulk job, nor does it differentiate from get_bulk_job or cancel_bulk_job. No exclusions or context 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?
No annotations are provided, so the description carries the full burden. It discloses that the output is a tree hierarchy, but lacks details about read-only nature, whether all lightboxes are included, depth limits, or response format.
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 with the action and resource, with no wasted 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?
The tool is simple (no params, no output schema), but the description is minimal. It does not explain what the tree contains or clarify whether this is a safe read operation, which is relevant given the lack of annotations.
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 baseline is 4. The description adds no parameter information because none are needed.
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 lightboxes hierarchy as a tree, using a specific verb and resource. It distinguishes from siblings like list_lightboxes by emphasizing the tree structure, 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?
There is no guidance on when to use this tool versus alternatives like list_lightboxes or get_lightbox. The description does not mention intended scenarios 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 burden of behavioral disclosure. It only says 'details' without describing the response format, error behavior, authentication needs, or any side effects. While 'get' implies a read-only operation, this is not explicitly stated and no additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 efficiently conveys the tool's core purpose, making it easy to parse. There is no unnecessary verbosity.
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 'details' are returned, but it does not. The tool appears to be a simple get-by-id, yet even for that, the absence of return value information and behavioral context leaves a notable gap. It is minimally adequate but incomplete.
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 covers 100% of parameters with 'id' described as 'ID of the resource'. The description adds minimal context that the resource is a storage folder, but it does not provide additional parameter semantics beyond what the schema already documents. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource 'storage folder' with 'details', clearly distinguishing it from sibling tools like list_storage_folders (which lists) and get_storage_folders_tree (which returns a tree). It unambiguously 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 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 list_storage_folders or get_storage_folders_tree. The description only states the action without contextual cues, leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' implies a non-destructive, read-only operation, and 'details' indicates the response scope. However, with no annotations, the description does not explicitly disclose side-effect safety, required permissions, or response format, leaving some 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 extremely brief at three words and contains no filler, front-loading the verb and resource. While it is concise, this brevity sacrifices explanatory richness, making it efficient but not fully informative.
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 single-parameter getter, the description is minimally sufficient: it conveys the action and resource. However, with no output schema and no behavioral context, the agent cannot infer what fields are returned or how the ID is used, leaving it at a basic viable level.
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 100% coverage for the single 'id' parameter, but the description adds no additional semantic context. The parameter description 'ID of the resource' is generic; the tool name implies it's a webhook ID, but the description does not reinforce this.
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 read action ('Get') targeting the 'webhook' resource. It distinguishes from siblings like list_webhooks (list vs. single) and get_webhook_logs (details vs. logs), though it doesn't explicitly say '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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that this retrieves a single webhook by ID, nor does it contrast with list_webhooks or get_webhook_logs.
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 that it lists rights packages, without disclosing pagination behavior, scope, ordering, or authentication requirements. Even though page/per_page parameters exist in the schema, the description does not mention them.
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?
A single concise sentence that directly states the tool's purpose. It is front-loaded and efficient, but 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?
For a simple list operation with no output schema and two optional parameters, the description covers the basic purpose. However, it lacks details about pagination behavior and what constitutes a rights package, so it is 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?
Both parameters (page, per_page) are fully described in the schema, so schema coverage is 100%. The description adds no additional meaning beyond the schema, 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 identifies the action (list), resource (rights packages), and purpose (managing asset usage rights). It distinguishes from sibling tools like get_rights_package (single item) and create_rights_package (creation).
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 explicit guidance on when to use this tool versus alternatives. The phrase 'for managing asset usage rights' is a purpose statement, not usage context. No mention of 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?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning whether it is destructive, reversible, requires permissions, or what happens to the associated tags. This leaves key operational details unspecified.
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 gets straight to the point with no redundant language.
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 or output schema, the description is too brief. The missing semantics of the 'id' parameter and lack of behavioral detail make it 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?
The single 'id' parameter is documented generically as 'ID of the resource' in the schema. The description does not clarify which resource the id refers to, adding no value beyond the schema. Baseline 3 applies due to 100% schema coverage, but no extra meaning 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 states a clear action — 'Unlink the creator-tag association' — with a specific resource context ('from a person tag'). This distinguishes it from siblings like set_tag_face_creator_tag, which performs the linking 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 usage as the inverse of setting a creator-tag association, but it does not explicitly mention when to use it over alternatives or any prerequisites. No exclusion criteria 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?
With no annotations, the description must disclose behavioral traits. It only states the high-level action without mentioning side effects, such as whether the previous invite is invalidated, whether the invitee receives a new email, or any permission 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 extremely concise and front-loaded, using a single clear phrase with no redundancy.
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 tool, the description is minimal but lacks important context such as the meaning of the id parameter and any state requirements for the invite. Given the presence of many invitation-related siblings, more complete guidance 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 input schema has one parameter 'id' with the generic description 'ID of the resource'. The tool description does not clarify that this is the invite ID, despite the tool name implying it. However, schema coverage is 100%, so the baseline for this dimension is 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 'Resend an invite email' clearly states the action (resend) and the resource (invite email), and is distinct from sibling tools like create_invite or update_invite.
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_invite or update_invite. There is no mention of prerequisites or contexts for resending.
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 implications. It does not mention that reverting is likely destructive, whether a new version is created, or any permission requirements. The description simply states the action without 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 sentence, front-loaded with the main verb and object. It contains no unnecessary words, making it extremely 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?
Given the tool is a mutation with no annotations or output schema, the description is insufficient. It does not explain what happens after revert, whether the action is irreversible, or how it interacts with version history. Sibling tools like get_asset_versions and add_asset_version provide context but the description itself lacks 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 input schema describes both parameters with clear descriptions (id and version). The description adds no additional meaning beyond the schema, so it relies entirely on schema explanations, which are 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 clearly states the action (revert), the resource (asset), and the target (previous version). It distinguishes from related tools like get_asset_versions (read-only) and restore_asset (restore from trash), making the tool's 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. It does not mention prerequisites, when not to use it, or that revert should be used instead of restore_asset for trash recovery. Only the implicit purpose is 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 disclose behavioral traits. It mentions the admin permission requirement, but does not describe the effects of revocation (e.g., whether the underlying grant is deleted), reversibility, or any other side effects. For a mutating action, this is insufficient.
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 purpose and admin scope without unnecessary words. 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 absence of annotations and output schema, the description is too sparse to fully contextualize the tool. It lacks information about the effects of revocation, error cases, or how it relates to the other access management tools, leaving the agent uncertain about the exact workflow and consequences.
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 describes the only parameter 'id' as 'ID of the resource', which is vague and could refer to either the access request or the target resource. The tool description does not clarify this, but since schema coverage is 100%, the baseline of 3 applies; however, the description adds no additional semantic value 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 uses a specific verb 'revoke' and identifies the resource as 'a previously granted access request', which clearly conveys an admin action. It provides some distinction from related tools like delete_access_request by noting the request was 'previously granted', but does not explicitly name alternatives, so sibling differentiation is limited.
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 'Admin:' indicates the tool is restricted to administrators, and 'previously granted' implies it should be used for revoking already-approved access. However, it provides no explicit guidance on when to use this over delete_access_request or delete_access_grant, nor any exclusions or prerequisites beyond the admin role.
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 behavioral burden. It states the core mutation ('Set') but does not disclose side effects, permissions, idempotency, or validation behavior. The 'mirrors' reference is vague without details of the mirror 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 concise sentence with no fluff. It is front-loaded with the action and resource, and the parenthetical mirror note is efficient. Every word earns its place.
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 6 parameters, no annotations, and no output schema, this description is highly incomplete. It fails to mention any return values, error conditions, or parameter usage nuances, leaving the agent largely uninformed beyond the tool's basic purpose.
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 17% (only 'id' has a description). The description does not explain any of the 6 parameters, such as the differences between 'value', 'text', 'custom_meta_value_id', and 'custom_meta_value_ids'. It only implies a value parameter without clarifying which schema fields apply.
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: 'Set a custom meta field value on an access request.' It includes a specific verb, resource type, and target field, and explicitly references the sibling tool set_asset_custom_meta, distinguishing it as the access request variant.
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 that this tool is for access requests ('on an access request') and references the alternative for assets ('mirrors set_asset_custom_meta'). It lacks explicit when/when-not exclusions, but the resource type is unambiguous.
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 details. It only states 'add', which implies mutation, but does not clarify whether assets are appended or replaced, duplicate handling, required session state, or permissions. This is minimal for a mutating 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 that directly states the action and target. There is no wasted wording, and 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?
The tool is simple with fully documented parameters, but the description lacks contextual information about the upload workflow, prerequisites, or return value. Given no output schema and no annotations, the description provides only the bare minimum needed to understand the 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 input schema already describes both parameters ('Upload session GUID' and 'Asset IDs to add') with 100% coverage. The description adds no additional semantic meaning beyond what the schema provides, 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 'Add assets to an upload session' uses a specific verb ('Add'), resource ('assets'), and target ('upload session'), making its purpose unambiguous. It also distinguishes itself from sibling tools like add_asset_to_collection or add_assets_to_group by clearly scoping to upload sessions.
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 relative to alternatives like create_upload_session or set_upload_done. The agent cannot infer the workflow context (e.g., after creating a session, before finalizing it) from the description 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 must convey behavioral traits. It implies a state-changing action (recording agreement) but does not specify side effects, permissions, idempotency, or what happens after invocation. The agent is left without critical safety information for a write 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 front-loads the main verb and object, followed by a clarifying context. It earns its place without unnecessary elaboration.
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 lacks behavioral context such as side effects, permissions, and usage boundaries. While the core action is clear, the absence of annotations and guidance on related tools makes it only minimally complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is described in the schema as 'ID of the resource', and the tool description adds that the action is on an access request, implying 'id' refers to that request. This adds minimal value beyond the schema, but since schema coverage is 100%, a baseline of 3 is appropriate. The description does not clarify the ID format or any 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 clearly states the tool's purpose: to record agreement to terms/NDA on an access request. The verb 'record agreement' is specific and the resource 'access request' is named. This distinguishes it from sibling tools like submit_access_request or finalize_access_request, which have different actions.
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 explicit guidance on when to use this tool versus alternatives. It mentions 'Guest' as a context cue but does not state when this tool is appropriate, what prerequisites exist, or when a different access request tool should be used instead.
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 of behavioral disclosure. It does state that assets are moved to the next step, but it omits important mutation details such as permission requirements, irreversibility, partial failure handling, or what happens when an asset cannot be approved. 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 concise sentence that front-loads the action and outcome. Every word earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation with no annotations and no output schema, the description covers the basic action and outcome but leaves out useful context such as required permissions, partial approval behavior, and response semantics. It is minimally viable but not fully 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?
Schema coverage is 100% with descriptions for both parameters, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; the id parameter remains vaguely described as 'ID of the resource' and the description does not clarify that it refers to the workflow step 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 the specific verb 'approve' with a clearly identified resource ('all selected assets in a workflow step') and states the outcome ('moving them to the next step'). This distinguishes it from the sibling tool approve_workflow_step_picks, which appears to handle a more specific subset, and makes the tool's 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?
No guidance is given on when to use this tool versus approve_workflow_step_picks or other workflow-related tools. The description implies batch approval of selected assets but does not state prerequisites, exclusions, or alternative selection criteria.
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 fails to mention whether tags are created if missing, whether existing tags are preserved, any limits, atomicity, or permission requirements. For a bulk mutation operation, 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.
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. It efficiently communicates the core action and scope without waste.
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 only 2 simple parameters, the lack of annotations and output schema leaves important context missing, such as whether tags are auto-created, what happens if an asset ID is invalid, and whether the operation is atomic. The description alone is insufficient for an agent to understand the full behavior of the tool.
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 add meaning beyond the parameter names. It only restates that 'tag names' are applied to 'assets', which is barely more than the schema's asset_ids and tag_names. It does not clarify whether tag_names must already exist, how duplicates are handled, or any constraints on the arrays.
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 'Add' and the resource 'tag names to many assets at once', which distinguishes it from singular add_tags_to_asset and bulk_remove_tags_from_assets. It is specific and unambiguous about scope.
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 for adding identical tags to multiple assets, but it does not explicitly state when to use this versus alternatives like add_tags_to_asset or bulk_remove_tags_from_assets. No exclusions or alternative guidance 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 full burden. It states the action but does not disclose side effects, reversibility, or whether cancellation is asynchronous. It also does not clarify what happens if the job is not running or already completed.
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 with no redundant words. It is front-loaded and appropriate for a simple one-parameter 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?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description provides the minimum viable context. However, it lacks details about cancellation semantics, such as whether it only works on 'running' jobs or also queued ones, and what the expected result or errors might be.
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% and the parameter description is generic ('ID of the resource'). The tool description adds no specific meaning to the 'id' parameter beyond associating it with a bulk job, which is already implied by the tool name. Baseline 3 applies because the schema handles 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 clearly states the action 'Cancel' and the resource 'running bulk job', distinguishing it from sibling tools like list_bulk_jobs, get_bulk_job, and create_bulk_job. The scope 'running' adds a useful qualifier that separates it from other bulk job operations.
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 whether it should be used only for running jobs or if it also applies to queued jobs. No exclusions or conditions 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?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only defines what the resource is, but does not mention side effects, required permissions, whether the portal is immediately active, or what happens to the underlying collection. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Create a new contribution portal') and efficiently adds a parenthetical definition. 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?
Given there are 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the full behavior, prerequisites, or return value. While the resource concept is defined, the tool's complete usage context is 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?
Schema description coverage is only 17% (only asset_group_id has a description). The description helps clarify that 'name' is the portal name and that the portal is tied to an asset group, but it does not explain parameters like enabled, message, require_login, or allow_anonymous. The description insufficiently compensates for the schema gaps.
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 creates a new contribution portal and elaborates on what that is (a named upload link tied to a collection/lightbox/folder). This distinguishes it from sibling create tools like create_share_link or create_asset_group_invite.
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 contribution portal is needed, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., create_share_link, create_asset_group_invite). There are no exclusions or prerequisite notes.
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 restates the action ('Cancel/revoke') without revealing side effects, reversibility, or permissions. It does not say whether the invitee is notified, if the action is idempotent, or what happens to associated data. This is minimal disclosure 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.
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 object. It avoids unnecessary words and clearly communicates the core function without padding. 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 single-parameter delete operation, the description is minimally sufficient. However, without annotations, output schema, or any mention of postconditions, the description doesn't fully cover the behavioral context. It adequately names the operation but leaves the agent wondering about idempotency and side effects, so it scores as average.
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 a generic description 'ID of the resource', and schema coverage is 100%. The tool description adds no additional meaning about the parameter beyond what the schema provides. Per the rubric, high schema coverage sets a baseline of 3, and since the description doesn't compensate with more context, a 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 uses a specific action ('Cancel/revoke') and clearly identifies the resource ('asset group invite'). It is immediately distinguishable from sibling tools like create_asset_group_invite, update_asset_group_invite, and list_asset_group_invites, as it is the only one denoting a delete/cancel 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. For example, it doesn't mention that update_asset_group_invite could be used to modify an invite instead of canceling it, nor any preconditions such as the invite being in a cancellable state. The intended usage is only implied by the name and verb.
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. It indicates deletion but does not specify whether the operation is irreversible, cascades to associated resources, or requires special permissions. This leaves 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, direct sentence with no filler or redundancy. It front-loads the action and resource, making it immediately 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?
For a simple delete operation with a single parameter, the description captures the core purpose. However, it omits any details about side effects, return values, or irreversibility, which could be relevant for user decision-making. The minimalism leaves some gaps, but the simplicity of the tool mitigates their impact.
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 a generic description for the 'id' parameter ('ID of the resource'), and the tool description imparts the meaning that this id refers to a filter group. While this adds some context beyond the schema, it does not elaborate on format or constraints. Baseline is 3 due to high 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 'Delete a filter group' uses a specific verb and resource, clearly indicating the action. It distinguishes itself from sibling tools like create_filter_group, update_filter_group, and get_filter_group by the delete verb.
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 or consequences. The description simply 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 disclosing behavioral traits. It states the destructive action but fails to mention whether deletion is permanent, what happens to lightbox contents, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence that is front-loaded and contains no filler. Every word earns its place, and for this simple tool, it is appropriately 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 captures the core action but omits context about consequences, ownership, and reversibility. It is minimally viable, covering the essential operation but leaving 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 coverage is 100% for the single parameter 'id', and the schema describes it as 'ID of the resource'. The tool description does not add further parameter detail, but the parameter is simple and the tool name clarifies that 'id' refers to the lightbox ID. Baseline of 3 applies due to high 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 'Delete a lightbox' uses a specific verb ('Delete') and a well-defined resource ('lightbox'). It clearly distinguishes this tool from sibling tools like update_lightbox, create_lightbox, and add_asset_to_lightbox, so 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is entirely self-contained with the bare action, leaving the agent to infer usage from the 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, the description carries full responsibility for behavioral disclosure. It states 'Delete' but does not clarify permanence, immediate revocation, or any side effects. For a deletion action, this leaves significant ambiguity about consequences.
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 filler. It front-loads the purpose and earns its place without 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?
For a simple delete tool with one parameter and no output schema, the description is minimally viable but lacks contextual depth. It does not mention the relationship to disable/enable tools or the irreversible nature of deletion, which would be helpful for an agent deciding between tools.
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 fully describes the one parameter ('id') with a description, and the tool name makes it clear the id refers to the personal access token. The description adds no additional parameter semantics, but the schema coverage is complete, so baseline 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 uses a specific verb ('Delete') and resource ('personal access token'), clearly distinguishing it from sibling tools like enable/disable/list tokens. There is no ambiguity about the action being performed.
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. Given sibling tools like disable_personal_access_token exist, it would be valuable to note that delete is permanent while disable may be reversible, but such context is 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. It simply states the action without disclosing consequences, permissions, idempotency, or return behavior. As a destructive operation, this lack of 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 concise sentence with no wasted 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?
For a simple delete operation with one parameter, the description covers the essential action, but it omits any mention of side effects, reversibility, or response. Given the lack of annotations and output schema, this leaves some 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 100%, and the description's 'by id' adds no meaning beyond the schema's description of the 'id' parameter. Baseline 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 uses a clear verb ('Revoke / delete') and specifies the resource ('share') and the means of identification ('by id'). It distinguishes from siblings like delete_share_link by focusing on the share 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 provided on when to use this tool versus related operations like delete_share_link or revoke_access_request. The description only states the action, leaving the agent to infer appropriate 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 bears the full burden of behavioral disclosure. It simply states 'Delete a webhook' without mentioning whether the deletion is permanent, irreversible, or requires special permissions. This is a minimal disclosure lacking side effects or consequences.
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, and direct sentence with no unnecessary words. It is appropriately sized for a simple delete operation and is front-loaded with the core action.
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, full schema coverage, no output schema), the description is adequate but not fully complete. It lacks any mention of return value, side effects, or dependencies, though these are less critical for such a straightforward delete tool. A bit more context about consequences would improve 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 100% coverage for the single parameter 'id', which is described as 'ID of the resource'. The description adds no additional meaning beyond the schema, which is already sufficient for this simple one-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 'Delete a webhook' clearly states the specific verb (delete) and resource (webhook), making it distinct from sibling tools like list_webhooks, get_webhook, create_webhook, and get_webhook_logs. It is concise 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 explicit guidance on when to use this tool versus alternatives, such as when to list or get webhooks. The usage context is implied by the verb 'delete' but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 basic fetch operation without mentioning return format, authentication requirements, error behavior, or the fact that it is a read-only operation. This leaves the agent without critical safety or side-effect 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?
The description is a single, focused sentence with no redundant words or filler. It earns its place by being clear and minimal.
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, the description is minimally adequate but lacks details about return values (no output schema) and any caveats. It does not explain what exactly is returned or any potential access restrictions, so contextually it is incomplete.
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 fully documents the single 'id' parameter with a description, and the description's phrase 'by id' simply reiterates this. Schema coverage is 100%, so the description adds no additional semantic meaning 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 uses the specific verb 'Get' and clearly identifies the resource 'asset group invite' with the 'by id' scope. This distinguishes it from sibling tools like list_asset_group_invites, create_asset_group_invite, update_asset_group_invite, and delete_asset_group_invite.
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 listing invites or creating new ones. There are no explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 ('Get version history') without detailing return format, pagination, ordering, or any access requirements. This is minimal disclosure for a tool that could have significant behavioral nuances.
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 unnecessary words. It is front-loaded and efficient, conveying the core purpose clearly.
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, the description is adequate but leaves gaps: it doesn't specify what the version history contains, how results are ordered, or whether it includes the current version. Given the absence of an output schema and annotations, more context would improve 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 input schema describes asset_id as 'ID of the resource' with 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate when the schema already documents the parameter fully.
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' with the resource 'version history' and clarifies it applies to an asset. This distinguishes it from sibling tools like get_asset (asset details), add_asset_version (adds a version), and revert_asset (reverts to an earlier version).
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_asset_event_log or get_asset_meta. There is no mention of use cases, exclusions, or prerequisites.
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 behavioral burden. It only states that details are retrieved, with no mention of return format, error behavior, permissions, or side effects. The word 'details' is vague and does not disclose what is returned.
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 words, making it very concise. However, it is so terse that it omits potentially useful context, but it is still 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?
For a simple getter with no output schema, the description should explain what 'details' are included in the response. It fails to do so, leaving the agent without information about the return value or any possible error conditions, which is inadequate for safe invocations.
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 single parameter 'id' is fully described in the schema (100% coverage). The description adds no additional semantic meaning beyond what the schema provides, 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 uses a specific verb 'Get' with the resource 'custom meta field details', clearly distinguishing it from sibling list/create/export tools. It unambiguously identifies the action and target resource.
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 no explicit guidance on when to use this tool versus list_custom_meta_fields or other alternatives. Usage is only implied by the tool name and the verb 'Get', providing minimal contextual direction.
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 transparency burden. The verb 'List' clearly indicates a read-only operation, and the optional filter is mentioned, but details about pagination, definition of 'recent', timezone handling, and response structure are absent.
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, immediately stating the action and scope, with the optional filter mentioned separately. No redundant 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 listing tool, the description gives the core purpose and optional filters, but fails to differentiate from the sibling get_recent_tag_events, and doesn't cover pagination behavior or event semantics, which is a gap given no output schema.
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 identifies 'year' and 'month' as optional filters, adding some meaning beyond the schema which lacks descriptions for these fields. However, it does not clarify value formats (e.g., YYYY, 1-12), and page/per_page are already described in the schema, limiting added value.
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 ('List'), resource ('tag activity events'), and scope ('for the org'), making the core function clear. However, it does not distinguish from the similarly named sibling 'get_recent_tag_events', and 'activity events' is 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?
No usage guidelines are provided. The description does not mention when to prefer this tool over the nearly identical 'get_recent_tag_events', nor does it specify any exclusions or typical use cases beyond the optional year/month filter.
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 implies a read operation via 'Get details', but does not disclose what specific details are returned, error behavior, permission requirements, or any side effects. There is no contradiction with annotations, but the information is 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, direct sentence with no redundant words. It earns its place by defining the resource type and the action, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required param, no output schema), so a complete explanation of return values is not necessary. However, the description lacks usage context and leaves 'details' vague. It is adequate for a simple get-by-id tool but not fully complete given the ambiguous sibling landscape.
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% for the single parameter 'id', described as 'ID of the resource'. The tool description adds that the resource is a tagging, which helps interpret the generic 'resource' wording. However, no additional parameter-specific details, such as format or scope, are given, so the added value is modest.
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' with the resource 'tagging' and clarifies it as a 'tag-to-asset relationship'. This clearly distinguishes it from sibling tools like get_tag (get tag details) and get_asset (get asset details), 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 such as get_tag, list_tags, or delete_tagging. It only states what the tool does, not the context in which it should be selected.
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 states the basic action but provides no additional context such as scope (organization-wide), default pagination behavior, or whether it includes all auto tags. It is not misleading but lacks depth that would help an agent understand the side effects or return structure.
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 words, directly stating the action. It is appropriately concise 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?
For a list tool, the description is minimal. There is no output schema or annotations, and the description does not explain the return format, the meaning of 'auto tags', or the scope of the listing. The undocumented q parameter and lack of alternative tool direction make this less complete than it could be.
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?
Only page and per_page have schema descriptions; q has none. The description does not explain q or any filtering behavior, so an agent must guess what q does. With 67% schema coverage, the description adds no parameter semantics and fails to compensate for the undocumented q 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 'List AI-generated auto tags' uses a specific verb ('List') and resource ('auto tags'), with 'AI-generated' clarifying that these are auto-generated tags rather than user-created tags. This distinguishes it from sibling tools like list_tags, which lists regular tags, and get_asset_auto_tags, which lists per-asset auto tags.
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 use this tool over alternatives, nor does it direct users to related tools like get_asset_auto_tags for per-asset listing or get_auto_tag for single lookup. There is no context about prerequisites or filters.
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, and the description only says 'List lightboxes in the organization' with no mention of pagination, read-only nature, ordering, or any behavioral nuances. The domain-specific behavior (e.g., parent_id filtering) is not 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?
A single, concise sentence conveys the core purpose without wordiness. 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 annotations, no output schema, and an undocumented parameter, the description alone is insufficient for an agent to fully understand the tool's behavior, expected parameters, or return value. It lacks context about pagination semantics and parent_id usage.
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 describes 'page' and 'per_page' but leaves 'parent_id' undocumented. The description adds no parametric context, failing to compensate for the 67% schema coverage gap, especially for parent_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 ('List') and the resource ('lightboxes'), with an organizational scope. It distinguishes from sibling tools like get_lightbox (single item) and create_lightbox/delete_lightbox (mutations).
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 verb 'List' implies enumeration, and sibling names provide some context, but there is no explicit guidance on when to use this versus get_lightboxes_tree or get_lightbox. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 revealing pagination behavior, return structure, or any side effects. It does not mention that results may be filtered via the 'q' parameter or limited by 'per_page'. 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 extremely concise at two words, with no filler or redundant information. Every word earns its place, and the structure is direct and front-loaded.
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 and a thorough input schema, the description is minimally viable. However, it lacks any mention of pagination, filtering, or return payload, relying entirely on the schema for context. For a list operation with no annotations or output schema, richer context would be helpful, but the description is not inadequate.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no additional semantic meaning beyond what the schema already provides. However, it does not contradict the schema, and the schema is 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 'List webhooks' uses a specific verb and resource, clearly stating the tool's action. It distinguishes from sibling tools like 'get_webhook' (singular) and 'create_webhook' by indicating a list operation for multiple webhooks.
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. It does not mention that filtering or pagination are available, nor does it contrast with 'get_webhook' for fetching a single webhook. No usage context 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?
With no annotations, the description carries the full burden of behavioral disclosure. It merely states the action without explaining side effects, prerequisites, error behavior, or reversibility. The 'counterpart to apply' hint is helpful but not enough for a mutation tool with zero 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, efficient sentence that front-loads the action and includes a useful cross-reference. 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?
Despite its simplicity (2 params, no output schema), the tool is a mutation with no annotations, and the description gives no parameter details, no behavioral notes, and no elaboration on 'pinned-assets'. Significant gaps remain for an agent 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 provides no explanation of the two parameters (asset_ids, asset_group_membership_id). It fails to compensate for the lack of schema documentation, leaving an agent without guidance on what these parameters mean or how to use them.
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 ('Remove pinned-assets') on a clear resource ('lightbox membership'), and the phrase 'counterpart to apply' distinguishes it from the related apply tool. This is a precise, unambiguous purpose statement.
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 identifies the tool as the counterpart to 'apply', implying it should be used to undo an apply operation. However, it doesn't provide explicit exclusions or alternatives, but the context is sufficient for understanding 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a non-obvious side effect ('Reindexes the asset on success'), which is valuable, but it does not mention other behavioral traits such as required permissions, potential data modifications, or failure behavior. The side-effect disclosure adds context but is not comprehensive.
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 core purpose and then a side effect. Every word adds value, with no redundancy or filler. It is well-structured and 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?
Given the tool's relatively simple signature (one param, no output schema) and the disclosure of a side effect, the description covers the main operation. However, it does not explain what the search returns (e.g., matched faces, status) or any failure conditions, which would be important for a search tool with no output schema. Some gaps remain in understanding the full behavior.
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 a description for the single parameter ('ID of the resource'), so the baseline is 3. The description adds some clarity that the resource is an asset, but it does not specify how the 'id' should be formatted or used beyond schema information, and no additional parameter details are 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 clearly states the tool's function with a specific verb ('Run face search') and resource ('on an asset'), and mentions the use of the org-wide face index and matching to person tags. It distinguishes from sibling tools like tag_asset_face or detect_video_faces by focusing on searching/matching rather than tagging or detecting, though it does not explicitly name any 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, such as when to use search_asset_faces instead of detect_video_faces or tag_asset_face. The description implies usage based on its function, but lacks any explicit context, exclusions, or alternative tool references, making it hard for an agent to decide among many face-related 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 provided, the description carries the full burden of disclosing behavioral traits, but it only states that the tool updates a tag. It does not disclose whether the update is partial (PATCH-style) or full replacement, potential side effects, permission requirements, or the response format. This is a significant gap for a mutation tool with 41 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, front-loaded sentence that efficiently summarizes the tool's scope without listing all 41 parameters. The parenthetical list of field categories is concise and informative. It loses a point for using the somewhat jargonistic 'enrichment field' without definition, but overall it is well-structured and not 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 tool's complexity (41 parameters, no output schema, no annotations) and low schema description coverage, the description is insufficiently complete. It provides an overview but omits critical context like return values, partial update behavior, and the significance of admin-only fields (though some are noted in the schema). The description does not equip an agent to fully understand the tool's capabilities and constraints.
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 only 44%, so the description needs to compensate. It does provide high-level semantic grouping ('event fields', 'artwork fields', 'external-system links', 'synonym graph') that helps the agent understand the parameter categories. However, it does not explain individual parameter semantics or mention the required 'id' parameter, leaving many parameters underspecified.
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 with a specific verb and resource: 'Update a tag'. It goes beyond a simple restatement by enumerating the categories of enrichment fields it handles, which helps distinguish it from create/delete/merge operations on tags. The inclusion of specific field categories (description, sub_type, link, event fields, artwork fields, external-system links, synonym graph) makes the purpose concrete and scoped.
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 for updating existing tags but provides no explicit guidance on when to choose this tool over alternatives like bulk_update_tags or merge_tags. It does not state exclusions or mention scenarios where other tools are more appropriate. The 'accepts every enrichment field' phrase suggests comprehensiveness but doesn't offer clear decision criteria.
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 for behavioral disclosure. It only states the action 'Upload' without explaining whether this is a create/replace operation, validation behavior, permission requirements, or impact on existing transcripts. Minimal 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?
The description is a single, coherent sentence that communicates the core purpose and example formats without unnecessary words. It is appropriately brief and front-loaded.
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 two-parameter upload tool, the description provides adequate basic context. However, it lacks detail on return values, error behavior, whether the transcript replaces or appends, and any specific prerequisites. It's minimally viable but not comprehensive.
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 50%: 'id' is described as 'ID of the resource' but 'transcript' has no schema description. The description adds value by clarifying 'transcript' format (WebVTT or plain text) and implies 'id' refers to a video asset. This partially compensates for the schema gap, but leaves the semantics of 'id' still somewhat generic.
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 'Upload' and the specific resource: 'closed-caption / transcript text for a video asset'. It distinguishes itself from generic upload tools (upload_file) and asset update tools (update_asset) by specifying the transcript content type and target 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. It doesn't mention when not to use it, prerequisites (e.g., asset must exist), or contrast with similar upload/update tools. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 itself. It only restates the operation ('Delete') without detailing side effects, permanence, permissions, or impact on associated data. This is insufficient 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 one concise sentence with no filler. It is appropriately front-loaded for a simple delete 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?
For a destructive tool with no annotations and no output schema, the description lacks crucial context about consequences (e.g., irreversibility) or success/failure behavior. However, the schema covers the only parameter, so partial 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 input schema already documents the 'id' parameter with 100% coverage, and the description adds no additional parameter meaning. Baseline 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 ('Delete') and the resource ('a tag-import job'), distinguishing it from sibling operations like create_tag_import or get_tag_import. The verb 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 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 guidance or exclusions. The usage is implied by the verb 'Delete' and the resource name, but it doesn't mention alternatives or prerequisites like 'use update_tag_import to modify a job instead.'
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 behavioral burden. It discloses the lookup scope and keys but does not state whether exactly one parameter is required, what happens if both/neither are supplied, or behavior when no membership is found. This is a meaningful gap for a find 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?
A single sentence that is front-loaded with the key action, resource, scope, and lookup keys. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needs to be more self-sufficient. It communicates the basic lookup but omits required-parameter semantics and encounter behavior (e.g., duplicate matches, absence of results), which could lead an agent to invoke the tool incorrectly.
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 names both parameters and adds the OR relationship, which the schema does not express. Still, it leaves ambiguity around mutual exclusivity and whether one is mandatory.
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 'Find' with the resource 'membership', scopes it to 'current org', and clarifies lookup keys 'username OR user_id'. This clearly distinguishes it from siblings like list_memberships (plural listing) and search_memberships (broader search).
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 context is implied: use when you need exactly one membership in the current org and have either a username or user_id. However, the description does not explicitly mention alternative tools or state when not to use it, such as preferring get_membership or list_memberships.
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 only states what the tool returns ('details and status') but does not disclose read-only nature, potential errors, required permissions, or side effects. The verb 'Get' implies safety, but that is inferred rather than explicit.
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 wasted words. It is front-loaded with the main action and resource. It could add a little more context without becoming verbose, but it remains 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 one-parameter tool, the description provides minimal but acceptable context. However, with no output schema or annotations, it does not specify what 'details' include, the structure of the response, or error behavior, leaving some ambiguity 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?
Schema description coverage is 100% because the only parameter 'id' has a generic description 'ID of the resource'. The tool description adds no additional meaning beyond that, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 names the resource 'bulk job' with scope 'details and status'. It clearly differentiates from sibling tools like create_bulk_job, cancel_bulk_job, and list_bulk_jobs by indicating a single-job 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?
Usage is implied: one would call this when they need details/status of a specific bulk job. However, there is no explicit guidance on when to use it versus alternatives like list_bulk_jobs or get_bulk_job_queue_position, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the invoice is marked as paid, but does not describe side effects, reversibility, permission requirements beyond 'super-admin', or what happens to the invoice state or audit logs. The term 'out-of-band' is vague and not explained. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that efficiently conveys the action and role. Every word adds value, with no filler or repetition. It is appropriately concise for a simple one-parameter 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 tool has no annotations, no output schema, and a single generic parameter, the description must do more to provide context. It states the action and condition ('open' invoice), but lacks information about prerequisites, consequences, or how this fits into the invoicing workflow. This is borderline inadequate for a semi-privileged 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 describes the parameter 'id' as 'ID of the resource' with 100% coverage. The description does not add any parameter-specific meaning, such as clarifying that the id refers to an invoice. However, since schema coverage is high, the baseline score of 3 applies. The generic schema description does not provide much value beyond the 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: 'mark an open CAI invoice as paid out-of-band'. It uses a specific verb ('mark') and object ('invoice'), and the 'Super-admin:' prefix indicates a role restriction. This distinguishes it from sibling tools like add_organization_cai_budget or grant_organization_cai_budget, which are about budget, not payment.
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: it is for super-admins to mark an open invoice as paid outside the normal system. However, it does not explicitly state when to use this tool versus alternatives (e.g., when the invoice should not be marked, or if there is a standard payment flow). The role and 'open' condition provide some context, but there are no explicit exclusions or alternative tool references.
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 it only clarifies the non-global scope. It does not mention whether the action is reversible, requires permissions, or how it affects the asset's tag list, leaving significant behavioral ambiguity for a mutating 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?
A single sentence that immediately conveys the core action and scope. No redundant words, making it appropriately sized and front-loaded.
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 simplicity, the description covers the main purpose and scope, but lacks parameter semantics and usage guidance. Since there is no output schema and no annotations, the description should provide more context for a complete picture.
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?
Only half of the parameters have schema descriptions (id is described but auto_tag_id is not). The description adds no parameter-specific guidance, such as how to obtain the auto_tag_id, and does not compensate for the missing schema 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 uses the specific verb 'Dismiss' to indicate removing an auto-tag from a specific asset, and clarifies that it does not delete the auto-tag globally, which distinguishes it from delete_auto_tag. This makes the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for asset-level removal of an auto-tag and explicitly notes it does not delete globally, which informs users not to use it if global deletion is intended. However, it does not name an alternative tool like delete_auto_tag or specify conditions for use versus auto_tag_asset.
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 move operation but does not disclose side effects, whether indexes are zero-based, what happens on invalid indices, or whether the operation is reversible. For a mutating reorder operation, this is insufficient.
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, using only necessary words. It is appropriately sized for a simple 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?
For a simple two-parameter tool, the description gives the core action and parameter roles, but lacks context on index semantics and return value. Given no output schema and no annotations, it is minimally viable but has clear 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?
With 0% schema description coverage, the description must compensate. It clarifies that oldIndex and newIndex are source and target positions, but it does not explain the indexing convention (zero-based vs one-based), bounds, or behavior when moving within the same list. This leaves critical meaning undefined.
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 (reorder), the resource (rename presets), and the mechanism (moving from oldIndex to newIndex). This distinguishes it from sibling CRUD tools like update_rename_preset or delete_rename_preset.
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 implies when to use it, but there is no explicit guidance on when to use this versus alternatives, nor any mention of prerequisites or exclusions. The description doesn't state 'use this to change ordering' which is implicit from the verb.
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 says 'Update' which implies mutation, but does not disclose permissions required, whether the update is partial, reversibility, side effects, or response behavior. This is minimal disclosure for a mutating 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 no filler. Every word contributes to the core meaning, making it appropriately concise and front-loaded with the action and resource.
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 3 parameters, no annotations, and no output schema, the description is too sparse. It does not explain the 'message' parameter, the effect of the update, or expected response, leaving a user uncertain about correct invocation and outcomes.
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 low (33%: only 'id' is described). The description adds meaning to the 'role' parameter via the example 'change role', but leaves the 'message' parameter completely unexplained. It partially compensates for the schema gap but does not fully cover all parameters.
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?
Description states 'Update an asset group invite' with a specific verb and resource, and gives a concrete example ('e.g. change role') that clarifies scope. This clearly distinguishes it from sibling tools like create_asset_group_invite, get_asset_group_invite, and delete_asset_group_invite.
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?
There is no explicit when-to-use guidance or mention of alternatives. The parenthetical example 'e.g. change role' implies a use case, but the description does not state when not to use the tool or how it relates to other invite-related operations.
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, and the description does not disclose behavioral traits such as permissions, reversibility, side effects, or what the 'visibility' update actually does beyond the schema fields. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that effectively delivers the core purpose without redundancy. No wasted words or irrelevant 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?
The description is minimal and lacks contextual information about prerequisites, effects, or distinctions from related tools. Given the absence of annotations and output schema, it is not fully self-contained for correct invocation.
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 already describes all 4 parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond restating 'visibility', relying entirely on the schema for parameter meaning.
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 identifies the action ('Update') and the target ('visibility of a specific filter within a filter group'), distinguishing it from the sibling update_filter_group which updates the group itself. 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 Guidelines3/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_filter_group. Usage is implied only by the verb 'Update', with no conditions, prerequisites, or exclusions 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?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning permissions, reversibility, side effects, or whether the operation is idempotent. 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, focused sentence with a useful parenthetical. It is front-loaded with the verb and resource, and every word contributes to understanding the tool's purpose. No unnecessary 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?
With no output schema and no annotations, the description should explain what happens after the update or what the response contains. The one-line description lacks this context, making it incomplete for an update operation that may require confirmation of changes or error 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?
The schema description coverage is only 33%, so the description must compensate. It explicitly mentions the two updatable fields ('role' and 'note'), which adds meaning to the schema's role_level and note parameters. However, it doesn't explain the id parameter or provide additional detail beyond what the schema already offers.
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'), the resource ('an invite'), and the specific changeable attributes ('role or note'). This distinguishes it from other invite-related tools like resend_invite or accept_invite, which have different purposes.
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 updating an existing invite's role or note, but it does not explicitly state when to use it over alternatives like create_invite, resend_invite, or accept_invite. There is no exclusion or alternative guidance, but the core usage is clear enough to be inferred.
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 and relationship, but does not disclose whether the operation overwrites existing associations, requires specific permissions, how errors are handled, or if it is idempotent. For a mutation tool, this is a significant lack of 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 that directly states the verb, object, and target. It contains no fluff and earns its place by adding the clarifying parenthetical about the link direction.
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 two-parameter input and no output schema, the description is minimally viable but leaves open questions about edge cases (e.g., existing associations, invalid face_id) and the return value. It is adequate for a basic understanding, but not fully complete for an agent to anticipate all behaviors.
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 covers only 50% (only 'id' has a description, and it's vague). The description compensates by clarifying that 'id' refers to the tagging ID and 'face_id' is the Rekognition face ID, adding meaningful context to both parameters. However, it could be more explicit about the format or source of the face_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 'Associate' with a clear resource ('existing tagging') and target ('Rekognition face id'), explicitly stating the directional link (tagging → detected face crop). This clearly distinguishes it from the sibling tool 'disassociate_tagging_with_face'.
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 explicit guidance on when to use this tool versus alternatives like 'set_tag_face_membership' or 'set_main_face_for_tagging'. The intended usage is only implied by the action described, with no mention of prerequisites, exclusions, or alternative scenarios.
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 notes the bulk-by-ID nature of the operation, but does not disclose whether the deletion is permanent, how partial failures are handled, what permissions are required, or what the response format is.
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. It clearly states the action, target, and batching behavior in a concise manner.
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 bulk-delete tool with one parameter and no output schema, the description covers the core action and input meaning. However, the absence of annotations and behavioral details like error handling or expected result leaves it minimally complete but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'ids' as an array of numbers with no description. The description adds that these are tag IDs, which clarifies the parameter's meaning, but it does not provide additional constraints such as maximum count, uniqueness, or minimum size.
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'), identifies the resource ('tags'), and clarifies the scope ('many tags by id in a single call'), effectively distinguishing it from siblings like delete_tag and merge_tags. This makes the tool's purpose immediately clear.
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 (bulk deletion of multiple tags in one call) but does not explicitly state when to use this tool instead of alternatives like delete_tag or bulk_update_tags. No prerequisites, exclusions, or alternative comparisons 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 disclosing behavioral traits. It only states the core action 'Find' without specifying details such as whether missing names are ignored or cause an error, whether matching is case-sensitive, or what the response format is. This minimal context is a gap 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, front-loaded sentence that conveys the tool's purpose without any filler or redundant information. It is appropriately concise 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?
The tool is simple (one required parameter, no output schema, no annotations), and the description states the basic purpose adequately. However, it omits any mention of return behavior or failure scenarios, such as what happens when some tags are not found. This is a minor gap but not critical for a straightforward lookup 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 input schema fully describes the only parameter tag_names as 'Array of auto tag names to find' (100% coverage). The tool description adds no additional meaning beyond the schema's description, essentially repeating the same information. Hence, baseline 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 'Find multiple auto tags by their names at once' clearly identifies the verb (Find), the resource (auto tags), and the method (by names). It explicitly indicates a batch operation (multiple, at once), distinguishing it from sibling tools like get_auto_tag (singular) and list_auto_tags (list all).
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 needing to fetch several specific auto tags by name ('multiple... at once'), but it provides no explicit alternatives or exclusions. It does not mention when to prefer this over get_auto_tag for a single tag or list_auto_tags for all tags. Usage guidance is only implied, not 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 only says 'draft' without explaining side effects, permissions required, or how the draft is stored or later referenced. The behavioral context is 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?
Two sentences deliver the core purpose and usage guidance without any wasted words. It is appropriately concise 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 5 parameters (all optional) and no output schema, the description offers no explanation of what an access request is, how to structure it, or what a successful draft returns. It relies on the sibling tool reference but lacks needed context for full understanding.
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 information about the five parameters. Parameters like custom_meta and asset_group_id are unexplained, leaving the agent to guess their meaning and usage.
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 it creates a draft access request and distinguishes it from submit_access_request by labeling it as 'pre-submit'. The verb 'Create' is specific and the resource is clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use submit_access_request to send it, providing clear guidance on when to use this tool versus the alternative. This is effective usage differentiation.
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, and the description only states the basic invite action. It does not disclose that this likely sends an email (indicated in the schema's 'message' field), any required permissions, or what happens on success/failure. This is a significant gap for a mutating 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 sentence that is concise and front-loaded with the action, containing no extraneous 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?
While the schema is rich and the description covers the essential purpose, it lacks information about the response/return value and side effects like email sending. For a create operation with no output schema, some additional context would be beneficial, but the tool is relatively simple.
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 high (80%), so the schema already explains most parameters. The description adds the concept that email and membership_id are alternative invitation methods, which is helpful. However, it doesn't add detail beyond that.
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 'Invite' and clearly states the target (user via email or existing membership) and the resource (collection/lightbox/storage folder). This clearly distinguishes it from sibling tools like list/get/update/delete_asset_group_invite.
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 creating a new invite but does not explicitly state when to use it versus alternatives such as update_asset_group_invite or list_asset_group_invites. No exclusions or conditions are given.
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 term 'trash' implies the asset is moved to trash rather than permanently deleted, which provides some behavioral context. However, with no annotations, the description carries the full burden and does not disclose permissions, reversibility via 'restore_asset', or any side effects beyond the trash implication.
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 wasted words. It is front-loaded with the action and resource, making it easily scannable.
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 tool, the description is adequate, but it does not mention what happens after deletion (e.g., asset can be restored), return values, or error conditions. The sibling context shows 'restore_asset' exists, but the description itself does not provide this linkage.
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 already provides 100% coverage for the single parameter 'id' with a description ('ID of the resource'). The tool description itself adds no additional meaning to the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource ('asset'), and the parenthetical 'trash' clarifies it's a soft delete. This distinguishes it from related tools like 'restore_asset' and 'get_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 such as 'restore_asset' or 'get_trashed_assets'. There is no mention of prerequisites, exclusions, or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds a concrete detail that requests respond with an X-PAT-Disabled header, which is useful. However, it does not explain what disabling does to the token (e.g., whether it revokes access, is reversible, or affects existing sessions). This is a modest but incomplete 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 filler. It efficiently conveys the essential purpose and a key behavioral detail. 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?
Given the tool's low complexity (one parameter, no output schema), the description is somewhat minimal but acceptable. It lacks details on reversibility, side effects, or typical use cases, but the name and description together provide a baseline understanding. More completeness would be expected for a mutation tool with no annotations.
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 100% coverage for the single 'id' parameter, but the description 'ID of the resource' is generic and does not specify it as the PAT's ID. The tool description does not clarify this further. Since the parameter is intuitively the token ID, the schema description is adequate, meriting 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 clearly states the action ('disable a PAT') and the specific resource (personal access token). It also identifies the scope as 'Super-admin', and the combination of verb+resource distinguishes it from sibling tools like enable_personal_access_token and delete_personal_access_token.
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 does not provide guidance on when to use this tool versus alternatives like enable or delete. It only notes 'Super-admin' as a precondition, but offers no context regarding scenarios where disabling is preferred over deleting, or any exclusion criteria. This is below the minimum viable 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?
No annotations are provided, so the description carries the full burden of disclosure. It names the core action but does not state whether the tagging itself is deleted, the operation is idempotent, or any permission requirements. This is thin 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 sentence with no filler. It front-loads the action and is concise while covering the core 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?
With only one parameter and no output schema, the description need not explain return values. However, the generic 'ID of the resource' could be ambiguous—it is unclear whether 'id' refers to a tagging ID or a face ID—and the effect on the tagging is not elaborated. This leaves some gaps for the agent.
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 fully describes the only parameter 'id' as 'ID of the resource', providing 100% coverage. The description adds no additional parameter-level information, but with full schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the specific resource ('face-crop association from a tagging'). This directly distinguishes it from related siblings like 'associate_tagging_with_face' and 'delete_tagging'.
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 face-crop association needs to be removed, but it does not explicitly mention alternatives or when not to use this tool. No sibling tools are referenced, leaving the agent to infer the appropriate 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 the full burden. It states the mutating action but gives no information about side effects, prerequisites (e.g., whether a URI must already be generated), success/failure conditions, or behavior if OTP is already enabled.
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 that communicates the core action, target, and requirement without any waste. 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 one-parameter tool, the description plus schema cover the basic purpose and input. However, as a mutating action with no annotations, it lacks context on prerequisites and side effects, leaving some gaps for the agent.
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 already provides 100% coverage for the single parameter otp_attempt, including its description. The tool description adds no additional parameter meaning beyond restating the need for a 6-digit code, so baseline 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 ('Enable TOTP 2FA'), the target ('current user account'), and the method ('by confirming a 6-digit code'). It distinguishes from sibling tools like get_my_otp_uri and disable_my_otp by focusing on the enabling step.
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 the user has a 6-digit code to confirm, but does not explicitly mention when to use this tool versus alternatives like get_my_otp_uri or disable_my_otp. No exclusions or alternative conditions are 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 must disclose behavior. It only says 'extend' without explaining side effects, permissions, or whether mutations are reversible. Critical behavioral details are 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, punchy sentence that front-loads the admin role and applicable states. It is extremely concise, though it sacrifices behavioral 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?
This is a mutation tool with no annotations or output schema, so the description must compensate. It covers the admin role and states but leaves unanswered what the API does, whether days and until are mutually exclusive, and what the response contains. Incomplete for a tool with 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?
Schema description coverage is 100% for the three parameters, and the schema already explains 'days' and 'until' and their alternatives. The tool description adds no parameter-specific guidance, so the baseline of 3 applies.
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 'extend' and identifies the resource as 'a trialing/past_due/canceled subscription', clearly distinguishing it from sibling tools like get_organization or update_membership. The 'Admin:' prefix adds role context. This 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for admin use and lists the subscription states it applies to (trialing/past_due/canceled), giving clear context for when to use it. However, it does not explicitly name alternatives or exclusions, so it falls short of full guidelines.
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 bears full responsibility for behavioral disclosure. It only states the lookup action and use case, but does not mention read-only nature, return format, error behavior, permissions, or side effects. For a lookup tool, this lack of transparency 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, front-loaded sentence that directly states the action and parameter. It is concise with no wasted words, making it easy to parse and understand.
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 (one parameter, no output schema, no annotations), the description covers the basic purpose and use case. However, it omits details about the return value, error handling, and the relationship with the similar 'get_access_request' tool, which could leave an agent uncertain about the tool's full behavior and when to choose it over alternatives.
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 explicitly mentions 'by guid', which adds meaning to the single parameter by identifying it as the lookup key. However, it does not describe the format, constraints, or expected values of the guid, leaving some ambiguity.
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 'Find an access request by guid' with a specific resource and parameter. It also adds the use case 'used in guest-link resolution', which provides context. However, it does not explicitly distinguish this from the sibling tool 'get_access_request', which could cause confusion about whether to use this or the get variant.
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 this tool: 'used in guest-link resolution'. This implies a specific scenario, but it does not mention alternatives or explicitly say when not to use it. The context is clear enough for an agent to understand its intended purpose, though it lacks explicit exclusion 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 must carry the full burden. It only states the action without mentioning that it's a read-only operation, whether it affects read/unread state, or what scope the count applies to (e.g., current user). This is insufficient for a complete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no extraneous words. It is appropriately sized for such a simple 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 description gives the basic purpose but lacks detail about the return format or scope. Given there is no output schema, the agent is left guessing whether the result is a plain integer or a structured object. For such a simple tool, it is marginally complete, but it could specify the scope (e.g., for the authenticated user) to be fully clear.
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, and the schema already confirms this (coverage 100%). The description adds nothing about parameters, but none are needed. The baseline of 4 is appropriate for a parameterless 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 'Get unread notification count' with a specific verb and resource. It distinguishes itself from sibling tool list_notifications, which would return notification items rather than a count. This is precise 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. There is no mention of list_notifications or any scenario where fetching the count is preferable to listing notifications. The agent receives no 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?
No annotations are present, so the description must disclose behavior itself. It only states the action, without mentioning pagination, sorting, permission requirements, or whether the result includes all assets or only direct ones. This leaves the agent without critical context about the tool's 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 sentence with zero wasted words. It uses a clean 'verb + object' structure that is immediately scannable.
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 operation, the description is sparse but functional. It doesn't explain pagination behavior (despite the page/per_page parameters), whether the share must be active, or what fields are returned in each asset. Given no output schema, more detail would improve completeness, but the tool's simplicity keeps this at an adequate level.
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 provides descriptions for all three parameters, covering 100% of them. The description adds no additional parameter semantics; the 'id' description remains generic ('ID of the resource') despite the tool's context, but the schema plus tool name make it understandable.
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 'List' and identifies the resource as 'assets included in a share,' clearly distinguishing it from siblings like get_share and list_shares. It is unambiguous about the tool's 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 guidance or alternative recommendations. However, the purpose is transparent from the name and description, implying this is the tool for retrieving assets within a share, which is adequate for a straightforward read operation.
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?
The description discloses the return fields but does not explicitly state that this is a read-only, safe operation. With no annotations provided, the burden falls on the description to convey side-effect-free polling behavior. It also does not mention any rate limits, resource costs, or whether repeated calls are appropriate.
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 key concept ('Lightweight status poll') and lists the relevant fields. No filler or 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 status polling tool, the description provides the return fields and purpose. However, without annotations or an output schema, it would benefit from explicitly stating safe-to-call/read-only nature and any rate-limit considerations. It is adequate but has clear gaps for a complete 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 already documents the single 'id' parameter with 100% coverage. The description does not specify that 'id' refers to a share ID, though it is implied by the tool name and description. The generic schema description 'ID of the resource' could be clearer, but the tool name fills that 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 clearly states it is a 'Lightweight status poll for a share' and lists the specific fields returned (aasm_state, progress, code, url, direct_link). This distinguishes it from sibling get_share, which presumably fetches full share details, and other share-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'lightweight' hints that this is meant for periodic status checks rather than full share retrieval, but the description does not explicitly state when to use this tool vs get_share or other alternatives. No exclusions or conditions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool gets a step, but does not mention error handling (e.g., not found), authentication requirements, or any side effects. For a read operation this is minimal but still leaves gaps.
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 conveys the essential action and resource immediately, earning a perfect conciseness score.
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 read tool, the description is minimally adequate but omits return value details, error behavior, and any context about workflow step status or usage. Since there is no output schema, the description could have added expected response information but does not. The tool is simple enough that a 3 is fair.
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 the single parameter 'id' as 'ID of the resource', and schema coverage is 100%. The description only reinforces that the step is retrieved by id, adding no new syntax or format details beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('workflow step') with an explicit identifier ('by id'). It clearly distinguishes this tool from siblings like list_workflow_steps and get_workflow, leaving no ambiguity about what it 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 phrase 'by id' implies usage when a specific workflow step identifier is known, but there is no explicit guidance on when to use this versus alternatives, nor any exclusion criteria. Usage context is entirely 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action without mentioning pagination behavior, sorting, read-only nature, or any side effects. This is a significant gap for a list operation that accepts paging parameters.
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 verb and resource. Every word provides value and there is no 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?
This is a simple list operation, but the absence of an output schema and annotations means the description could provide more context about return format, pagination, or ordering. The current description is minimally adequate but lacks these details.
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 provides 100% coverage with clear descriptions for all four parameters (id, type, page, per_page). The description does not add anything beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List comments on a Lightbox or Collection' uses a specific verb (list), resource (comments), and scope (Lightbox/Collection). This clearly distinguishes it from sibling tools like create_comment, update_comment, and delete_comment.
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 comments, but it does not provide explicit guidance on when to use it versus alternatives, nor any exclusions or preconditions. It is minimally clear from the sibling context, but the description itself lacks explicit usage 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 disclose behavioral traits. It only says 'List' (implying read-only) but does not mention pagination behavior, response format, permissions, or what fields are returned. The reference to contribution_id implies it is in the response, but that is not made explicit. This falls short of the disclosure expected without 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 two concise sentences, front-loaded with the main purpose and followed by a practical usage tip. Every sentence adds value with no repetition or filler. It is well-structured for quick parsing.
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 that there is no output schema and no annotations, the description could provide more context about return values, pagination, or how this tool compares to related list tools. However, the usage pointer to upload_file/upload_files adds practical context. It adequately covers the basics but lacks depth for a tool with many siblings and optional filters.
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 provides descriptions for all three parameters (q, page, per_page) with 100% coverage, so the description needs no additional parameter explanation. It does mention contribution_id, but that is not a parameter of this tool; it is a hint for subsequent upload tools. The baseline score of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('contribution portals'), with a clarifying parenthetical ('upload links') that distinguishes this from other list operations. It does not explicitly differentiate from sibling tools like list_lightbox_contributions, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit usage guidance: after listing, use the returned contribution_id with upload_file/upload_files to target a storage folder or lightbox. It does not explicitly state when to choose this over sibling list alternatives, but the instruction on how to use the result is direct and actionable.
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 the basic action without disclosing what data is returned, whether it includes disabled tokens, authentication requirements, or pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 with no redundant information. It earns its place entirely.
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 operation with pagination, the description is minimally adequate. However, without an output schema or annotations, it lacks details about the response structure or any filtering/scope nuances, which would make it more 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 covers both parameters (page and per_page) with descriptions, so there is 100% schema coverage. The description adds no additional parameter semantics beyond what the schema already provides, aligning with the baseline of 3 for high 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 uses a specific verb ('List') and clearly identifies the resource ('personal access tokens'). It distinguishes itself from sibling tools like create/delete/disable/enable_personal_access_token by indicating this is the read-only listing 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 usage is implied by the tool's name and the presence of pagination parameters, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisite conditions.
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 alone must disclose behavioral traits. It only states the action and domain, lacking information about read-only nature, permissions, pagination behavior, or response contents. This is a significant gap 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 with a parenthetical clarification. No redundant or filler language; it is front-loaded with the verb and resource.
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 two optional pagination parameters and no output schema, the description gives a clear purpose and domain context. However, it does not hint at return structure, ordering, or any filtering capabilities, which would be useful given the lack of an output schema.
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 provides full descriptions for both parameters (page and per_page) with 100% coverage. The description does not add parameter-specific meaning, but since schema coverage is complete, 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 uses the specific verb 'List' with the resource 'workflow steps' and clarifies the domain with 'the user-facing approval queue,' which distinguishes it from sibling tools like list_workflows and get_workflow_step.
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 parenthetical 'the user-facing approval queue' implies this tool is for viewing steps in the approval workflow, but it does not explicitly state when to use it compared to alternatives like list_workflows or get_workflow_step. No exclusions 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?
No annotations are provided, so the description must carry the full behavioral burden. It only says 'remove' without disclosing whether the removal is reversible, permanent, or whether any permissions or side effects apply. This is a bare description 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?
One short sentence that states the verb, direct object, and scope with no filler. 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?
The description covers the essential action and the two parameters' roles, but since there is no output schema or annotations, it lacks information on return values, error behavior, or reversibility, leaving some operational 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 50%; asset_group_id has a description and asset_ids is self-explanatory. The description adds the bulk aspect ('many assets') and the target container types, but no additional constraints like batch limits or idempotency.
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 (remove) and the resource (many assets from a collection/lightbox/storage folder). It distinguishes from siblings like add_assets_to_group and remove_lightbox_membership_assets by specifying the bulk multi-type container nature.
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 bulk removal across multiple container types but does not explicitly say when to choose this over related tools such as remove_lightbox_membership_assets or how to handle prerequisites or caveats.
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 disclosing behavior. It communicates destructiveness ('clear face-tagging state') and an async side-effect ('re-enqueue Rekognition indexing'), but omits details about reversibility, permissions, or what happens to existing indexing jobs.
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 efficiently captures both the primary action and the reindexing side-effect. There is no filler 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?
The operation is simple (one parameter) and the description states the core behavior. However, the ambiguous 'id' and lack of output/return behavior leave gaps. No annotations or output schema exist, so the description should clarify more, but it is adequate for a basic mutation 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?
The schema has 100% coverage with a description for 'id' ('ID of the resource'), but this is generic and unhelpful. The tool description adds no clarification about what resource the id refers to (e.g., tag id, face id). Since schema coverage is high, the baseline is 3, but the description does not enrich the parameter's meaning.
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 ('clear') and names the exact resource ('face-tagging state on a person tag') plus the subsequent action ('re-enqueue Rekognition indexing'). It clearly distinguishes itself from sibling tools like set_tag_face_membership or remove_tag_face_membership by describing a reset-and-reindex 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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or conditions that would warrant a reset. 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.
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 states only the basic action ('Transfer ownership') without mentioning permissions, whether the new owner must accept, reversibility, effects on memberships, or response behavior. 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, concise sentence that is front-loaded with the action and key details. No unnecessary words or repetition; 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 2-parameter tool with no output schema, the description is minimally adequate. However, given the absence of annotations, it lacks context about permissions, side effects, or what happens after transfer. It does not address how this tool relates to other lightbox operations, but the basic purpose is clear.
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 50% coverage; 'id' is described as 'ID of the resource' but 'user_id' has no description. The description adds value by clarifying user_id is the target user ('by user id'), but it does not clarify what 'id' refers to beyond the schema. It partially compensates 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 uses a specific verb 'Transfer' with a clear resource 'ownership of a lightbox' and recipient 'another user (by user id)'. It clearly distinguishes this from sibling tools like create_lightbox, update_lightbox, and delete_lightbox by focusing on ownership change.
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 the tool—when transferring ownership of a lightbox—but does not explicitly state alternatives or when not to use it. It gives no exclusions or relationships to other lightbox-related tools, making it adequate but not fully guided.
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 for disclosing behavior. It indicates field-level updates ('Update fields') but does not explain what happens on partial failure, whether fields are overwritten or merged, permission requirements, atomicity, or the response format. As a mutation tool, this lacks important 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 two sentences with no filler. It front-loads the primary action and provides practical guidance in the second sentence. Every word adds value, 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?
For a bulk mutation tool with no output schema or annotations, the description is incomplete. It omits critical details like return value (e.g., updated assets or job ID), behavior on partial failures, and any constraints or prerequisites. While the parameter semantics are partially covered, the operational context is insufficient for safe invocation.
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 50% (only `updates` has a description). The description enriches `updates` by listing example field names and correlating it to `update_asset`, but `asset_ids` remains unexplained beyond its name. The description adds partial value but does not fully compensate for the missing schema description of `asset_ids`.
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: 'Update fields on many assets in a single call.' It uses a specific verb (update), identifies the resource (assets), and contrasts with the single-asset `update_asset` sibling. The mention of field names (title, description, etc.) further clarifies 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 phrase 'many assets in a single call' implies when to use this tool (bulk metadata updates) versus `update_asset` for single updates. Referencing `update_asset` for field names provides context, but it does not explicitly mention alternatives for other bulk operations (e.g., tags, rights) or state when not to use it. Usage is clearly implied but not exhaustively specified.
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 full responsibility for behavioral disclosure. The term 'stub' suggests creating placeholder records if tags aren't found, but the description does not explain the implications: what gets created, whether this mutates data, required permissions, or what the response contains. This is a significant gap for a potentially mutating 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 no filler words. It front-loads the primary purpose and adds a scoping clarification in parentheses. However, the jargon 'stub' introduces some ambiguity, though this is more a clarity issue than 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?
The tool has no output schema and no annotations, so the description is the only source of behavioral context. It fails to explain what 'stub' means, what the tool returns, how errors are reported, or any side effects. For a bulk operation that appears to have a write component ('stub'), this is quite incomplete.
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 clarifies that the 'names' array consists of taxonomy tag names ('by name', 'many'), but adds no further constraints, such as uniqueness, case sensitivity, or behavior when a name is duplicated. The added meaning is minimal beyond the parameter name itself.
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 verb and resource: 'Find or stub many taxonomy_tags by name in a single call'. The parenthetical 'top-level — searches across taxonomies' distinguishes this tool from other tag-related tools (e.g., bulk_find_tags) by emphasizing cross-taxonomy 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 provides useful context: 'top-level — searches across taxonomies' signals when this tool is appropriate (cross-taxonomy lookup) and implies it is broader than taxonomy-scoped alternatives. However, it does not explicitly mention when not to use it or name alternative tools as the TDQS 4.3 example does.
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 burden. It only states the operation without disclosing permissions, reversibility, error handling, or behavior for tags that don't exist on some assets. For a destructive bulk operation, this is insufficient.
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, front-loaded, and precisely worded. Every word earns its place, with no redundancy or irrelevant 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?
The tool is a bulk mutation with no annotations, no output schema, and minimal description. It lacks critical context about whether the operation is synchronous, whether it validates all tags before applying, or what happens if some asset_ids are invalid. This is a clear gap for a destructive bulk 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 description adds meaning beyond the raw schema by explaining that asset_ids identify the target assets and tag_names are the names (not IDs) to remove from all of them. However, with 0% schema description coverage, it does not fully compensate—no details on case sensitivity, existence checks, or partial failures.
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?
Description clearly states the verb 'remove', the resource 'tags from assets', and the scope 'many assets at once'. It distinguishes from siblings like bulk_add_tags_to_assets and add_tags_to_asset by specifying removal and bulk behavior.
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?
Implied usage is clear: use when you need to remove the same tag names from multiple assets in one operation. Does not explicitly contrast with single-asset removal or bulk add, but the context is unambiguous.
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, and it does disclose a key side effect (auto-cleaning the parent PublishedAsset when the last image is removed). However, it omits other important behavioral information such as irreversibility, permissions, or whether the delete is hard or soft, making it only partially transparent.
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 only two sentences long, with no redundant or filler content. The key action and side effect are stated efficiently and in a clear order.
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 one-parameter delete tool with no output schema, the description provides the essential action and an important cascade effect. It is sufficiently complete, though it could mention irreversibility or other consequences, but those are largely implied by the term 'delete'.
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 covers the sole parameter (id) with 100% description coverage, so the baseline is 3. The description adds no additional meaning about the id beyond what the schema provides; it only implies that the id refers to a PublishedImage row.
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 single PublishedImage row') with a specific verb and resource. It also distinguishes this from sibling delete tools by naming the exact entity type, and the auto-clean behavior adds further 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 guidance is provided on when to use this tool versus alternatives (e.g., delete_asset) or when not to use it. The description is purely functional and gives no contextual usage cues.
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 behavioral disclosure. It states the action (remove) but does not mention whether the operation is permanent, requires specific permissions, or returns a response indicating success or failure. For a delete operation, this is a minimal but notable 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, front-loaded sentence that uses a specific verb and clarifies with a parenthetical. Every word is meaningful, with no filler or restatement of structural information. It is an excellent example of conciseness.
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 parameter and no output schema, the description adequately conveys the core action. It could be improved by stating whether the operation returns any result or if it is irreversible, but given the simplicity of the operation, the description is reasonably complete for an agent to select and invoke the 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?
The schema describes the 'id' parameter as 'ID of the resource' with 100% coverage. The description does not add any parameter-specific meaning beyond the schema; however, the tool name makes it clear the id refers to the tagging. Baseline of 3 is appropriate because the schema already documents the parameter and the description adds no further 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 'Remove a tagging (untag an asset)' clearly states a specific action (remove) and a specific resource (tagging), with a parenthetical clarifying the operation. It distinguishes from sibling tools like delete_tag (which deletes a tag definition) and bulk_remove_tags_from_assets (which handles bulk operations).
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 tool name and description: use this to remove a single tagging from an asset. However, the description does not explicitly mention when to prefer this over alternatives like bulk_remove_tags_from_assets or remove_asset_auto_tag, nor does it provide exclusions. Guidance is present but not explicit.
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 of behavioral disclosure. The note 'Members are not deleted' is a useful side-effect clarification, but the description does not mention other aspects such as permission requirements, reversibility, or whether the deletion is permanent. It adds some value beyond the tool name but is still 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 extremely concise: two short sentences that immediately convey the action and the key non-destructive side effect. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 with no output schema, the description is largely adequate: it states the purpose and highlights the most important behavioral consequence (members not deleted). It lacks usage guidance, but that was scored separately. The description is complete enough for an agent to understand the basic 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 covers the single 'id' parameter with 100% coverage, providing a clear description ('ID of the resource'). The tool description adds no additional parameter-specific meaning, so the baseline score of 3 for high schema coverage 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 uses a specific verb ('Delete') and resource ('user group'), clearly distinguishing it from sibling tools like create_user_group, update_user_group, or get_user_group. The additional statement 'Members are not deleted' further clarifies the operation's 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?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or situations where it should be avoided. The only contextual hint is the note about members not being deleted, but this is more of a behavioral clarification than 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?
No annotations are provided, so the description carries full burden. It only states the action and form, omitting any detail about tree structure depth, ordering, or read-only guarantees. 'Get' implies read, but no behavior is 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?
Single sentence of six words, front-loaded with action and object, no filler. 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?
No output schema exists, yet the description does not explain what the tree structure contains or how it is formatted. It also doesn't differentiate from sibling tree tools like get_storage_folders_tree, leaving context gaps.
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 with an empty schema (100% coverage), so parameter semantics are trivially satisfied. Description need not explain any parameters.
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 ('collections hierarchy') with a clear qualifier ('as a tree'), distinguishing it from flat list_collections or single get_collection. It clearly 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hierarchical collection views but does not explicitly state when to prefer it over list_collections or other tree tools like get_lightboxes_tree. 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?
No annotations are provided, so the description must disclose behavioral traits. It simply says 'Get a rename preset' without mentioning what happens if the ID is not found, whether it returns the full object, or if any permissions are required. This is minimal disclosure for a 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 one short sentence that is front-loaded with the action and resource. It wastes no words and is appropriately sized 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 CRUD getter with one parameter and no output schema, the description is nearly complete. It could explicitly state 'by ID' to align with the schema, but the overall tool is simple enough that this description suffices.
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 the 'id' parameter described as 'ID of the resource'. The description adds no additional meaning beyond that, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a rename preset' clearly identifies the operation (get) and the resource (rename preset). This distinguishes it from sibling tools like list_rename_presets, create_rename_preset, update_rename_preset, and delete_rename_preset.
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 use when a single rename preset is needed by ID, but provides no explicit when-to-use vs alternatives. Sibling tools like list_rename_presets suggest the alternative for listing all presets, but the description itself doesn't mention this.
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 must carry the transparency burden. It explains the core behavior (automatic tagging) but does not disclose permissions, idempotency, or effects on existing links. This is acceptable but lacks depth 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?
Two concise sentences with the action front-loaded. No redundant words, and the consequence is stated efficiently. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple link operation, the description covers the main functionality and outcome. However, it omits potential edge cases like pre-existing links, required permissions, or error behavior, which would be more critical for complex tools. Given the low complexity, it is nearly 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?
Schema coverage is 100% but both parameter descriptions are generic ('ID of the resource', 'Creator tag name'). The description adds some context by saying 'by name' for the creator tag, but leaves the 'id' parameter's role ambiguous. Meets the baseline for high coverage without adding substantial 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 clearly states the action (link a person tag to a creator tag) and the consequence (photos gain the person tag automatically). It distinguishes from siblings like set_tag_face_membership by focusing on creator tag linkage, though it 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when wanting to link a person tag to a creator tag) but does not provide explicit context or exclusions. No alternative tools are mentioned, so guidance is mostly inferred 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?
With no annotations, the description must describe behavioral traits, but it only restates the action. It does not disclose important behavior such as whether duplicates are ignored, how partial failures are handled, any permission requirements, or the operation's atomicity. 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, well-structured sentence with no wasted words. It is front-loaded with the verb and resource, making its purpose immediately clear.
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 has only two simple parameters and no output schema, but the description is minimal. It does not explain what the operation returns, how it handles edge cases (e.g., invalid asset IDs), or any side effects. While the core action is clear, an agent may need additional information to invoke it confidently in all scenarios.
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 already provides 100% coverage, describing 'ids' as an array of asset IDs and 'asset_group_id' as the ID of a Collection or Lightbox. The description adds no additional parameter-level detail beyond the schema, so it earns 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 clearly states the action ('Add'), the resource ('multiple assets'), and the target ('a Collection or Lightbox'). It explicitly mentions 'multiple' and 'at once', which distinguishes it from sibling tools like add_asset_to_collection and add_asset_to_lightbox that handle single assets.
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 primary use case: adding several assets in one operation. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent would infer when to use this tool versus the single-add siblings. However, no explicit when-not-to-use 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, the description must carry the full burden of behavioral disclosure. It only states that it returns a download URL for a ZIP file. It does not mention whether the operation is synchronous or asynchronous, whether it creates a job, any limits on asset count or size, auth requirements, or URL expiration. 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?
A single, front-loaded sentence: 'Get a download URL for multiple assets (returns a ZIP file)'. Every word earns its place, and the parenthetical efficiently communicates the return type. No fluff 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 has 5 parameters and no output schema, but the schema already documents all parameters with descriptions. The description covers the return value (a ZIP file URL) but omits important context such as whether the download is asynchronous, how long the URL is valid, or any constraints on the bulk operation. Given the complexity, the description is adequate but not 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?
Schema coverage is 100% with every parameter having its own description, so the baseline is 3. The tool description itself adds no additional parameter semantics beyond the schema; it only mentions 'multiple assets', which maps to the asset_ids parameter. No compensation 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?
Clearly states the action ('Get a download URL') and resource ('multiple assets'), with a parenthetical specifying the output is a ZIP file. This distinguishes it from single-asset tools like get_asset_download and from create_download/get_download which likely manage download jobs.
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 that this is for multiple assets, implying use when you need to download more than one asset at a time. It does not explicitly name alternatives or provide when-not-to-use guidance, but the 'multiple assets' phrasing provides sufficient directional clarity.
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 burden. It discloses that the tool supports a broad enrichment surface, but does not explain conditional behaviors (e.g., event fields require sub_type=event), required permissions, or effects like name uniqueness. This leaves the agent with incomplete behavioral expectations.
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: a clear imperative purpose followed by a concise list of supported enrichment areas. Every word earns its place, and the most important information is front-loaded.
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 create operation, the description is adequate, but this tool has 38 parameters, no annotations, and no output schema. The description gives a high-level overview but does not explain conditional constraints, defaults, or the return value. It is not complete enough for an agent to use confidently without additional schema inspection.
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 only 37%, so the description must compensate. It groups parameters into categories (description, sub_type, link, event fields, artwork fields, external-system identifiers), which provides some structure. However, it does not explain which specific parameters belong to each group or any conditional relationships, so the agent still has to infer from an under-described 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 opens with 'Create a new tag,' a specific verb and resource that clearly distinguishes it from sibling tools like update_tag, delete_tag, and get_tag. It also summarizes the supported enrichment surface, reinforcing the tool's scope.
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 'Create a new tag' implies when to use the tool, but the description offers no explicit guidance on when not to use it or alternatives (e.g., create_taxonomy_tag for taxonomy-specific tags). There are no prerequisites or exclusions 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, the description carries the full burden for behavioral disclosure. While it mentions that in-flight steps may need separate cancellation, it does not state whether deletion is irreversible, what permissions are required, or what actually happens to associated steps. This is insufficient 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 extremely concise at two sentences, front-loaded with the primary action, and every word earns its place. No unnecessary detail.
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 with one parameter, the description is reasonably complete, but the caveat about in-flight steps is ambiguous (e.g., under what conditions they need cancellation, whether deletion succeeds regardless). No output schema exists to clarify behavior, leaving some 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%, but the property description 'ID of the resource' is generic and does not specify it is the workflow ID. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
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 'Delete a workflow' with a specific verb and resource, distinguishing it from sibling tools like delete_workflow_step. The additional caveat about in-flight steps further clarifies 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 provides clear context for when to use (when a workflow needs to be deleted) and includes a practical caveat that in-flight workflow_steps may need separate cancellation. It does not name explicit alternatives, but the context is 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 must carry the full behavioral burden. 'View' strongly implies read-only, but the description does not explicitly state that it performs no modifications, nor does it clarify what is included (e.g., pending vs. all requests) or any return format details. Minimal disclosure beyond the basic structure.
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, front-loaded sentence that conveys the essential purpose without any filler. Every word contributes meaning.
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 parameterless tool with no output schema, the description provides a basic understanding but requires the agent to infer the exact output structure and when to use it relative to sibling access-request tools. It lacks details like whether the tree includes filtering or statuses, and it doesn't compare to list_access_requests.
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 schema coverage is trivially complete. The description accurately summarizes the output without needing parameter explanations, matching the baseline for no-parameter tools.
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?
Clearly states it returns a hierarchical tree view of access requests grouped by asset group, identifying both the resource and the organizational structure. The verb 'tree view' distinguishes it from flat listing or single-fetch tools like list_access_requests and get_access_request.
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 use when a hierarchical representation by asset group is needed, but it does not explicitly state when to choose this over list_access_requests or get_access_request. No exclusions or alternative tools are mentioned, leaving the usage context implicit.
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 explaining behavior. It indicates a read operation ('Get') but does not disclose response format, permissions, error behavior, or whether all metadata types are always present. The description adds minimal behavioral context beyond the action itself.
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?
One sentence, no unnecessary words, front-loaded verb and purpose. Ideal for a simple getter 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?
Given the tool's simplicity (single parameter, no output schema), the description is adequate but lacks any mention of return value structure or edge cases like missing metadata. Since there are no annotations, additional detail on what the response looks like would improve 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 input schema has full coverage for the single 'id' parameter with a clear description. The tool's description doesn't add further parameter semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 extracted EXIF/IPTC/XMP/file metadata for an asset. The verb 'Get' and the specific metadata types distinguish it clearly from sibling tools like get_asset or get_asset_content.
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 metadata is needed and the specific metadata types give clear context. However, it doesn't explicitly contrast with alternatives like get_asset or mention when not to use this tool, though this is not a major issue given the specificity.
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 for behavioral disclosure. It only says 'Get details' which implies a read operation, but it does not explain permissions needed, what 'details' includes, error behavior, or response format. This is a minimal statement with 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?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 with one parameter and no output schema, the description is minimally viable. It tells what the tool does but not what fields/details are returned or any special constraints. Given the simplicity, a bit more specificity (e.g., 'basic details' or 'full organization object') would improve completeness, but it is not severely lacking.
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 description 'ID of the resource' is generic, and the tool description clarifies that the ID refers specifically to an organization. This adds meaning beyond the schema, which has 100% coverage. The description tells the agent that the expected input is the organization's ID, which is useful.
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 (organization), and the scope (details by ID). It distinguishes from siblings like list_my_organizations and find_organization by explicitly indicating a direct ID-based 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?
The description implies usage when you have an organization ID and want its details, but it does not explicitly mention alternatives or when not to use this tool. No exclusions or comparisons to siblings are provided, so guidance is only 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 full burden. It adds useful context like 'currently associated' and 'across the org', but does not disclose return format, pagination, permissions, or whether it returns all face crops or only the main one. This leaves gaps for a read tool without annotations.
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, front-loaded sentence with no filler. It states the action and scope efficiently.
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 list tool with no output schema, the description covers the basic purpose and scope. However, it does not explain what the returned 'face crops' include (e.g., URLs, IDs, bounding boxes) or how 'currently associated' is determined, which a user might need absent an output schema.
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 100% coverage for the parameter, but the description 'ID of the resource' is generic. The tool description clarifies the resource is a 'person tag', which helps infer that the id is the tag id, but this mapping is not explicitly stated. The description adds some meaning but relies on inference.
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 lists 'face crops currently associated with a person tag' with the scope 'across the org'. It uses a specific verb ('List') and a specific resource, distinguishing it from sibling tools like get_asset_face_taggings (asset-specific) and set_tag_face_membership (mutation).
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 (retrieve face crops for a person tag) but does not explicitly mention when to use this tool versus alternatives like get_asset_face_taggings or search_asset_faces. No exclusions or alternative tool names 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 must carry the full burden. It only states the net effect ('hide') without disclosing whether the hide is reversible, whether it overrides per-face ignore settings, or any side effects or permissions. The sibling tool ignore_asset_face_toggle suggests a toggle mechanism, but this description does not clarify the relationship.
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 object, with no filler. Every word contributes to clarity.
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?
While succinct, the description lacks information about return values, reversibility, or side effects for a mutating action. Given no annotations or output schema, a bit more context would be needed for full clarity, though the operation is straightforward.
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 describes 'id' generically as 'ID of the resource', but the description's 'on an asset' clarifies that the parameter is the asset ID, adding meaning beyond the schema. With 100% schema coverage, baseline is 3; the asset context justifies a 4.
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 ('Hide'), the target ('all unidentified face crops'), and the scope ('on an asset'). It distinguishes from sibling tools like ignore_asset_face_toggle, which operates on a single face, by specifying 'all unidentified' rather than a single face.
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 (hiding all unmatched faces) but does not explicitly state when to use this tool versus alternatives such as ignore_asset_face_toggle, tag_asset_face, or block_asset_face. There is no mention of exclusions or alternative scenarios.
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 of behavioral disclosure. It explains the concept of access grants but does not disclose pagination behavior, return format, or any side effects. 'List' implies a read-only operation, but lacks detail beyond that, making it acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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-resource pairing and adds a useful clarifying parenthetical. There is no wasted or redundant wording, making it exceptionally 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?
The tool is a simple list operation with two optional pagination parameters and no output schema. The description provides the key conceptual context (defining access grants) but omits explicit mention of pagination or response details, which are partially covered by the schema. It is adequate but not comprehensive.
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% as both 'page' and 'per_page' have descriptions ('Page number', 'Results per page (max 100)'). The tool description adds no parameter-specific information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List') and resource ('access grants'), and the parenthetical defines access grants as 'records produced when an access request is finalized', which semantically distinguishes it from the sibling tool list_access_requests. This is a specific, non-tautological description.
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 by clarifying that access grants are the finalized records from access requests, suggesting this tool is for listing finalized grants, but it does not explicitly state when to use it vs. alternatives like list_access_requests or provide exclusions. The guidance is implicit rather than explicit.
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 the scope ('current org') and status ('pending'), but does not mention permissions, pagination behavior, ordering, or response structure. It also doesn't state that this is a read-only operation. This is minimal behavioral disclosure for a tool with no annotations.
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 action, resource, and scope. No wasted words, front-loaded with the verb. Ideal 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?
For a simple read-only list tool, the description covers the basics: what it lists and the scope. However, with no output schema and no annotations, it lacks information about return format, pagination defaults, and permission requirements. It's minimally complete but leaves gaps that could confuse an agent about what to expect.
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 provides 100% coverage for both parameters (page and per_page) with descriptions. The tool description adds no additional parameter semantics, so it relies entirely on the schema. Baseline 3 is appropriate since the schema fully documents the parameters.
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 'List' and clearly defines the resource as 'pending requests from users asking to join the current org'. This distinguishes it from sibling tools like list_memberships (existing memberships) and get_pending_membership_requests_count (count only).
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 need to view pending membership requests for the current org, but it does not explicitly state alternatives or exclusions. For example, it doesn't mention that list_memberships is for active memberships or that get_pending_membership_requests_count provides just a count. The context is clear, but there's no explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 core function and does not mention read-only nature, pagination behavior, return format, or any side effects. For a simple list operation this is a notable gap, though the schema covers parameters.
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 that delivers the essential purpose and key distinction without any wasted words. It is well-structured and easily scannable.
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 (list with pagination), and the description is adequate for basic use. However, there is no output schema, so the description could have mentioned what the response contains (e.g., array of share objects) or any default pagination behavior. It provides just enough context but leaves some details unspecified.
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 already provides 100% coverage for the 'page' and 'per_page' parameters, so the description does not need to add much. The baseline is 3, and since the description adds no additional parameter context, this score 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 verb 'List' and the resource 'shares', and provides a specific definition ('one-off transfers of an asset/group to a user') that distinguishes it from the sibling tool for public share links. This makes the purpose unambiguous and differentiates it from 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes it is 'distinct from public share_links', providing an exclusion that helps the agent choose this tool over the alternative. However, it does not explicitly state when to use this tool versus other list tools, so guidance is good but not fully elaborated.
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 must fully convey the read-only nature of the operation. The term 'preview' and 'before submitting' strongly imply that no files are renamed or jobs submitted, but the description does not explicitly state that it makes no changes or what happens on invalid inputs. It provides basic transparency adequate for a simple preview.
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 of 14 words, front-loading the core purpose. No redundant or filler 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 the tool has 6 parameters, no output schema, and no annotations, the description is too brief. It does not explain how the preview is presented (e.g., list vs. diff), what the parameters control, or what errors may occur. For a tool with this complexity, the description is insufficient.
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 6 parameters with 0% coverage, and the description does not explain any of them. It hints at the existence of a rename preset and assets, but custom_text, start_number, global_start, custom_text_2 are left undefined. The description fails to 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 uses a specific verb ('preview') and a specific resource ('filenames a rename bulk job will produce'), clearly distinguishing it from sibling tools like create_bulk_job or get_bulk_job. It states the tool's function precisely.
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 'before submitting it' gives clear temporal context for when to use this tool. However, it does not explicitly name alternative tools (e.g., create_bulk_job) that would actually submit the job, so a user could still be unsure when not to use this. The timing clue is helpful but not complete.
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 states the core action but fails to disclose side effects (e.g., whether the tag itself is deleted, if it affects child tags, required permissions, or idempotency). 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?
A single sentence of 10 words with no filler. It is front-loaded and immediately conveys the 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?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but minimal. It does not mention return values, error cases, or the tag's status after detachment, leaving some ambiguity. More detail on effects would improve 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 describes the parameter as 'ID of the resource,' which is generic. The description clarifies that the ID refers to a tag, adding meaning beyond the schema. Schema coverage is 100%, but the description provides necessary context for the resource 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 'Detach' with a clear resource 'a tag' and target 'all taxonomies it belongs to.' This precisely distinguishes it from sibling tools like 'delete_taxonomy_tag' or 'remove_tag_face_membership'.
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 (when wanting to remove a tag from all taxonomies), but it does not explicitly state when not to use it or mention alternatives like 'delete_taxonomy_tag' or 'add_tag_to_taxonomy'.
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, leaving the description to carry the transparency burden. It discloses that the action is AI-enabled and lists example tasks, but it fails to mention side effects (e.g., async processing, cost, or asset modification), authentication needs, or irreversibility. For a mutation-like 'invoke' action, 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, front-loaded sentence with no redundant filler. Every phrase contributes meaning, and the parenthetical examples aid comprehension without bloating the 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?
Given no output schema and no annotations, the description omits critical behavioral details like return value or job semantics. It adequately explains the core purpose but leaves questions about what happens after invocation. For a two-parameter action tool, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic value beyond the schema: 'on an asset' clarifies the vague 'ID of the resource' for the id parameter, and 'custom meta field action' maps directly to custom_meta_field_id. With only 50% schema coverage, this compensation is useful and helps disambiguate both parameters.
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 provides a specific verb ('Invoke') and resource ('asset'), coupled with a clear scope ('AI-enabled custom meta field action'). It includes concrete examples ('LLM-driven extraction, classification, or description') that distinguish it from sibling tools like auto_tag_asset or generate_asset_alt_text.
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 a usage context (triggering a custom AI action on an asset) but does not explicitly state when to use this versus sibling AI tools, nor does it mention any prerequisites or exclusions. This is acceptable but not fully explicit.
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 does reveal the comment-context scoping, but it does not disclose the read-only nature, authentication requirements, pagination behavior, or any return value structure. The description adds only a little beyond the schema's parameter descriptions.
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, clearly stating the tool's purpose and target use case. It is highly 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?
With 5 parameters, no annotations, and no output schema, the description covers the core purpose and scoping but omits details like return format, pagination defaults, or any special behavior. It is sufficient for a straightforward search tool but leaves some ambiguity, so it is not fully 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?
Schema description coverage is 60%, and the description adds some meaning for the undocumented commentable_id and commentable_type parameters by mentioning 'collection / lightbox' and 'comment context.' However, it does not explain commentable_id itself, and q/page/per_page are already well-described in the schema. This provides moderate added value, earning a 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 clearly states a specific verb ('Search') and resource ('memberships'), further scoped by context ('within a comment context (collection / lightbox)'). This distinguishes it from sibling tools like list_memberships and find_membership by indicating a focused use case.
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 a clear usage context: 'used for assignee pickers and @-mention lookups in commenting flows.' This tells the agent when to use this tool, but it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does disclose the key behavior 'creates per-member copies', which goes beyond the tool name. However, it omits side effects (e.g., whether existing copies are replaced), prerequisites (e.g., permissions), and idempotency details.
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 sentences with no wasted words. The action and use case are front-loaded, making it concise and well-structured.
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 mutating operation with no annotations and no output schema, the description provides the core purpose but lacks important context such as return value, behavior on existing copies, and whether this is an append or replace operation. It is adequate but leaves clear 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 description coverage is 0%, and the description does not adequately explain the two parameters. It mentions 'pinned assets' but does not clarify that asset_ids specifies the assets to push or how asset_group_membership_id identifies the membership. The relationship between parameters and the described behavior is ambiguous.
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 ('push... pinned assets out to all members') and the resource ('lightbox membership's pinned assets'). It distinguishes from siblings by noting it creates per-member copies, and the use case of broadcasting curated picks.
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?
Provides a clear use case: 'Used to broadcast curated picks to a shared lightbox.' This implies when to use the tool. However, it lacks explicit exclusions or alternative tool references, so it doesn't fully reach level 5.
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?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It clearly states a key non-destructive behavior ('Existing auto-tags are preserved; new ones are appended') and mentions the external service (Rekognition/Vision). However, it does not disclose potential costs, asynchronous execution, permission requirements, or error conditions, which are relevant for a mutation tool without 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 two succinct sentences, front-loaded with the action ('Run Rekognition / Vision auto-tagging'). It avoids redundancy and every clause adds value, including the preservation behavior. This is an example of efficient, focused writing.
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 tool with one required parameter and no output schema, the description covers the core purpose and the essential behavioral nuance (preservation). It could mention side effects like costs or long-running processing, but given the tool's simplicity, the description is sufficiently complete for an agent to invoke it 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 schema has 100% coverage for the single parameter 'id' with a generic description ('ID of the resource'). The description adds that the operation targets 'a single asset', clarifying the resource type and reinforcing that 'id' refers to an asset. This is helpful but not a major enhancement over the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') with a specific resource ('asset') and method ('Rekognition / Vision auto-tagging'), clearly distinguishing it from siblings like remove_asset_auto_tag or get_asset_auto_tags. The phrase 'on a single asset' further differentiates it from bulk operations such as bulk_add_tags_to_assets.
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 for performing auto-tagging on an asset, but it does not explicitly state when to use this tool instead of related alternatives like run_asset_ai or add_tags_to_asset. The statement about preserving existing tags gives behavioral context, but there are no explicit exclusion criteria or alternative tool references.
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?
With no annotations, the description carries the burden of disclosing behavior. It explicitly mentions creating a 'Blocked Face' tag and excluding the face from future matching, which are meaningful side effects beyond the tool name. It does not mention reversibility or permissions, but the core behavioral traits are transparent.
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 front-loads the action and resource, then adds a parenthetical with key side effects. Every word earns its place; 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?
For a two-parameter tool with no annotations and no output schema, the description covers the main operation and effects, but leaves parameter semantics under-specified and does not mention any prerequisites, return values, or error conditions. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'id' has a generic description). The description does not clarify what 'id' refers to (asset vs. face crop) or what 'face_id' means. The phrase 'detected face crop' hints at the relationship, but the description fails to compensate for the undocumented 'face_id' parameter, 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 action 'Block' on a specific resource ('detected face crop on an asset') and distinguishes from siblings by elaborating the effects: creates a 'Blocked Face' tag and excludes from future matching. This is specific and not a tautology, earning full marks.
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 the tool (blocking a detected face crop) and the behavioral effect (excludes from future matching), but does not explicitly contrast it with similar tools like ignore_asset_face_toggle or tag_asset_face. No exclusions or alternative guidance is given, so it remains at an implied-usage level.
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 disclosure burden. It reveals some conditions (existing account, org membership) but does not specify the return format, whether the operation is read-only, or any error behavior, leaving important behavioral details ambiguous.
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 that efficiently communicates the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should explain what the check returns or what the agent can expect. It provides criteria but omits return value details, leaving the outcome ambiguous.
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%. The description references 'a given email' but adds no additional meaning about the parameter, such as format constraints, allowed values, or examples. 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 tool's function: checking whether an email is a valid recipient for a new invite. It lists specific criteria (already has account, already in org), which distinguishes it from siblings like create_invite and find_invite.
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 context: use this before creating a new invite to validate the recipient email. It implies the workflow step but does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions markdown and @mentions support, but this simply repeats the schema's text property description and does not add beyond it. It does not disclose permissions, side effects, error conditions, or return values.
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, no fluff, and the main purpose is stated upfront. Every phrase earns its place.
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 create operation with all parameters fully documented in the schema, the description is sufficient for an agent to understand how to invoke it. It could ideally mention the return value, but this is not critical given the tool's 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 coverage is 100%, so the baseline is 3. The description repeats what the schema already provides (type/id/text roles, markdown support) without adding any new semantic meaning beyond the structured definitions.
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 a new comment') and specifies the resource ('on a Lightbox or Collection'). It distinguishes from sibling tools like list_comments, update_comment, and delete_comment by its clear create semantics.
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 makes it clear when to use this tool: to create a new comment on a Lightbox or Collection. It does not explicitly name alternatives or exclusions, but the purpose is self-evident given the sibling list includes update/delete/list comments.
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. 'Save' indicates a mutating operation, and the note about the sql field being an Elasticsearch SQL WHERE clause adds useful context. However, it doesn't disclose return values, validation behavior, or side effects, leaving gaps typical of a create 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 long, front-loads the primary action ('Save a new search query'), and includes only the essential constraint about the sql field. No wasted words 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?
Given the tool's simplicity (3 params, 100% schema coverage, no output schema), the description adequately covers the core action and the most critical parameter constraint. It doesn't mention output or prerequisites, but these are less critical for this straightforward create 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?
Schema description coverage is 100%, so baseline is 3. The description adds a mild prescriptive nuance ('should contain') to the sql parameter, but this largely echoes the schema's own description. No significant added 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a new search query' with a specific verb (save) and resource (search query), distinguishing it from sibling operations like list, get, update, and delete. The word 'new' reinforces the create intent.
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 word 'new' implies this tool is for creating a search query, but there is no explicit guidance on when to use it vs. alternatives like update_search_query for modifying existing queries. Usage is implied rather than directly 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 of behavioral disclosure. It only states the action without mentioning side effects, reversibility, session implications, or any security verification required. For a security-sensitive mutation, 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, clear, front-loaded sentence with no unnecessary words. It is concise and fully 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?
The tool is simple with no parameters and no output schema, but the description omits behavioral details an agent needs for a security-sensitive operation, such as reversibility or additional authentication required. It is adequate for basic invocation but lacks comprehensive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema. The description adds meaningful context by specifying 'current user account', clarifying the implicit target of the operation. This exceeds the baseline of 4 for zero-parameter tools.
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 'Disable' and clearly identifies the resource 'TOTP 2FA' on the current user account. It distinguishes the tool from siblings like enable_my_otp and get_my_otp_uri.
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 of turning off TOTP for one's own account, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites/exclusions. No guidance on 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.
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 says 're-enable a previously disabled PAT', which states the basic action but does not disclose any side effects, such as whether the token value changes, whether the token must be actively disabled, or any additional permission checks beyond the super-admin role. It adds no behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that packs the essential information: role, action, and object. It is front-loaded and contains no filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with one parameter and no output schema, the description covers the who (super-admin), what (re-enable PAT), and condition (previously disabled). It does not mention how to obtain the ID or explicitly state that this is the inverse of disable_personal_access_token, but these are inferable from context. The description is sufficiently complete for the tool's 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?
The schema has one parameter 'id' with a generic description 'ID of the resource'. Schema coverage is 100%, but the description does not add specifics such as 'ID of the PAT'. Since coverage is high, the baseline is 3, and the description does not actively confuse or add value. It lacks a clear statement that 'id' refers to the personal access token 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: 're-enable a previously disabled PAT', with the explicit scope 'Super-admin'. It identifies both the verb (re-enable) and the resource (PAT), and it is distinct from sibling tools like disable_personal_access_token and delete_personal_access_token, which perform different operations.
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 by specifying the required role ('Super-admin') and the condition ('previously disabled'). It implies when to use the tool—when a PAT was disabled and needs reactivation—but does not explicitly mention alternatives or exclusion criteria. Since sibling tools are named similarly, the context is clear enough.
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 transparency burden. It discloses that the tool uses AI and saves to the alt_text field, but omits critical behavioral details for a mutation: whether existing alt text is overwritten, if any AI costs or credits are incurred, or if special 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?
A single sentence, front-loaded with the action and result, with no unnecessary words. It earns every word and is highly scannable.
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 one-parameter mutation with no output schema, the description adequately covers the purpose and side effect. It does not explain return values nor caveats like overwrite behavior, but these are not strictly required given the tool's 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 100% for the only parameter, but the description is generic ('ID of the resource'). The tool description adds context that the id refers to the asset, which is helpful, but doesn't provide additional syntax or format details. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('asset') with a clear outcome ('saves to the alt_text field'). It distinguishes itself from sibling tools like auto_tag_asset (tags) and run_asset_ai (generic AI) by focusing on accessibility alt text generation.
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 need alt text for an asset. It does not explicitly mention alternatives or exclusions, but the context is strong enough to understand when to use this tool versus generic update or AI tools.
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. It discloses that results are paginated and include version history and user actions, but does not elaborate on permissions, ordering, or whether it is read-only. Adds some behavioral context but not comprehensive.
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 that conveys the core function, scope, and pagination. No filler or redundant information.
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 description adequately covers the tool's purpose and key behavioral trait (pagination). No output schema exists, but the description hints at what is returned. It is sufficient for a simple read-only audit log 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% and all three parameters (id, page, per_page) are documented in the schema. The description adds no extra parameter semantics, but it does mention pagination which aligns with page/per_page. Baseline 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 tool's purpose: an audit trail for an asset, covering every version and user actions. It distinguishes from siblings like get_asset_versions by focusing on the event log aspect.
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 (when you need an audit trail for an asset) but does not explicitly mention alternatives or when not to use it. No exclusivity is 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 burden. It only states what the tool does, not behavioral details like whether it includes empty folders, pagination, depth limits, or the exact structure of the returned tree. Minimal extra transparency is offered.
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 with no unnecessary words. It is front-loaded and entirely earned.
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 zero-parameter read tool, the description is fairly complete: it names the resource and the tree format. However, without an output schema, more detail about the return structure (e.g., nested objects, included fields) would be helpful. Still, the simplicity of the tool means this is 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 fully covers parameters. The description adds no parameter details, but with no params to document, a baseline of 4 is appropriate per the rubric.
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 storage folders as a tree hierarchy, using a specific verb and resource. This distinguishes it from sibling tools like list_storage_folders (flat list) and get_storage_folder (single folder).
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 tree structure is needed, but does not explicitly contrast with list_storage_folders or get_storage_folder. No when-to-use or when-not-to-use guidance is provided, though the tree wording offers some context.
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 discloses that the tool returns members and permissions, indicating a read operation, but does not mention auth requirements, error behavior, or whether the operation has side effects. For a simple get, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the verb and resource. Every word adds value; 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?
For a low-complexity tool with one parameter and no output schema, the description is nearly complete. It states what is returned (members + permissions) and how the resource is identified (by id). Missing a brief note on what to use for listing all groups, but not essential.
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 already documents the single 'id' parameter with 100% coverage. The description's 'by id' adds no new semantic meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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'), resource ('user group'), and scope ('by id'), with an explicit note that it returns members and permissions. This distinguishes it from list_user_groups and get_membership.
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 use when you have a specific user group ID, but no explicit alternatives or exclusions are given. It does not mention when to prefer this over list_user_groups or other group-related tools.
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 of behavioral disclosure. It does transparently explain the effect of set_synonym (preserve as synonym vs. delete), but it omits other important side effects such as asset reassignment, irreversibility, or permission requirements. It provides some behavioral context but lacks completeness.
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 that conveys the core operation and the key behavioral option. Every word earns its place, with no redundant or filler content.
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 low complexity (3 simple parameters, no output schema), the description is largely complete. It covers the main action and the set_synonym variation. However, it could mention typical side effects (e.g., asset retagging) to fully complete the picture for an agent, though these are not strictly necessary for this level of complexity.
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 description adds meaning to the schema parameters by establishing that 'id' is the source tag and 'target_tag_id' is the destination, which is not explicitly stated in the schema. The schema's coverage of id is vague ('ID of the resource'), but the description clarifies its role. The set_synonym parameter already has a schema description, and the tool description reinforces it.
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: 'Merge one tag into another.' It specifies a specific verb and resource, and distinguishes itself from sibling tools like update_tag and delete_tag by describing a distinct consolidation operation. The additional detail about set_synonym further clarifies the 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 gives no explicit guidance on when to use this tool versus alternatives such as update_tag or delete_tag. It does not mention prerequisites, when merging is appropriate, or situations where another tool should be used instead. The intended usage is implied but not clarified.
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 disclosing behavior. It only states the primary effect but does not mention any side effects, prerequisites, or error conditions (e.g., what happens if the asset is not trashed, or whether permissions are required). This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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, with a parenthetical clarification. Every word earns its place, and 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.
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 parameter and no output schema, the description covers the essential purpose and context. It clearly indicates the condition (trashed) and the relationship to delete_asset, but omits potential caveats like permission requirements or failure modes. Given the tool's simplicity, this is nearly 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 fully documents the single parameter 'id' with a generic description ('ID of the resource'). The description adds the context that this id refers to a trashed asset, which is somewhat helpful, but does not go beyond what the schema already implies. With 100% schema coverage, 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 ('Restore'), the target resource ('a trashed asset'), and explicitly ties it to the inverse operation ('undo delete_asset'). This distinguishes it from sibling tools like update_asset or get_asset, which operate on non-trashed assets.
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 the tool: when an asset is in the trash and needs to be brought back. The reference to delete_asset further signals the intended use case, though it does not explicitly mention exclusions or alternative tools for similar scenarios.
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 transparency burden. It discloses interactive gallery features (thumbnails, hover previews, inline editing, rating, tagging, download), but it does not clarify whether edits persist, what permissions are required, or how results are returned (UI vs. API). This leaves important behavioral implications unstated.
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 well-structured with a clear one-line purpose followed by a concise bulleted feature list and a usage note. It is somewhat verbose but every bullet adds specific functionality context. It avoids redundancy and is easily scannable.
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 complexity (17 parameters, no output schema, no annotations), the description adequately conveys the visual-gallery purpose and usage context, but it does not explain the return format, pagination behavior, or how the interactive gallery is delivered to the user. These are significant gaps for an agent deciding whether and how to invoke the 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 description coverage is 82%, so the schema already documents most parameters. The description adds no parameter-specific details beyond the general search and visual browsing context, so it does not significantly compensate for the small documentation 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 clearly states the tool searches for assets and displays them in an interactive visual gallery, distinguishing it from the sibling search_assets tool. The feature list reinforces the specific interactive browsing 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 description explicitly says 'Use this when the user wants to visually browse or explore assets,' providing clear context. It doesn't explicitly mention alternatives or when not to use it, but the guidance is sufficient for differentiation.
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 behavioral burden. It states the core action but omits side effects (e.g., permanent overwrite, behavior on non-video assets), permissions required, or error conditions. 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, well-structured sentence that immediately states the resource type and action. It contains no unnecessary wording and is easy to parse.
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 two-parameter setter, the description provides the core function and parameter meaning. However, it lacks details on prerequisites, error handling, or return values. Given the low schema coverage, a bit more context would be helpful, but the essential purpose is clear.
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 only generically describes 'id' as 'ID of the resource' and leaves 'seconds' entirely undescribed. The tool description adds meaning by clarifying id as the video asset and seconds as the frame time offset, providing necessary context that compensates for the schema's 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 identifies the action: set the poster/preview image of a video asset from a specific frame time. It uses a specific verb and resource, distinguishing it from sibling tools like update_asset or set_asset_custom_meta.
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 for video assets but provides no explicit guidance on when to use this tool versus alternatives. It lacks exclusion criteria or context for selection among other asset-related tools.
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 behavioral disclosure burden. It discloses the key behavior that passing null clears the creator tag, which is important nuance. However, it doesn't explain whether the operation is atomic, how it affects assets with existing tags, what errors might occur, or what the response looks like, leaving some gaps.
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 front-loads the verb and resource. Every word contributes meaning, and it avoids unnecessary filler or repetition of the tool name.
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 bulk setter, the description covers the core operation well, but without annotations or an output schema, it lacks details on return values, error handling, and prerequisites (e.g., whether the creator tag must exist). This is adequate but not complete for an agent needing to anticipate 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?
The description adds meaning by explicitly stating that null clears the tag, which maps directly to the creator_tag_id parameter's null type. However, it doesn't name the parameters or explain asset_ids beyond implying they identify the assets. Since schema coverage is 0%, the description only partially compensates for the lack of explanation.
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 'Set' (or 'clear') and the resource 'creator tag' on 'many assets,' which specifically distinguishes it from sibling tools like bulk_add_tags_to_assets (regular tags) and set_tag_face_creator_tag (face-level creator tags). The mention of 'in one call' highlights the bulk nature, making it precise 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description strongly implies when to use this tool: when you need to set or clear creator tags on multiple assets at once. It doesn't explicitly mention alternatives or exclusions, but the 'many assets in one call' phrase is a clear contextual signal that this is for batch operations, which is sufficient for most agents.
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 must carry the full burden. It discloses that passing null clears the rights package, which is useful. However, it does not state the effect on existing rights packages, permission requirements, or potential partial failures, leaving 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, concise sentence with no filler. It directly states the operation, the special case (null), and the scope, 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?
Given the simplicity of the tool and lack of annotations or output schema, the description provides the core operation but omits important context such as whether the operation overwrites existing rights packages, what the response contains, and whether permissions are required. More detail would improve 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?
With 0% schema coverage, the description compensates by explaining that rights_package_id can be null to clear and that asset_ids refers to multiple assets. It adds meaning beyond the schema, which only lists types, by clarifying the null behavior and the bulk nature.
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 (set or clear) and the resource (rights package) on many assets. It uses a specific verb and identifies the scope ('many assets'), distinguishing it from single-asset operations and other bulk tools like bulk_add_tags_to_assets.
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 need to set or clear rights packages on multiple assets at once ('in one call'), but it does not explicitly mention alternatives or exclusion criteria, such as when to use a per-asset update instead.
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 discloses that the operation approves and grants access, which is a key side effect. However, it omits important behavioral context such as whether the action is reversible, prerequisites (e.g., request must be in 'submitted' state), or consequences for the request record.
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, tightly constructed sentence that leads with the intended role ('Admin:') and immediately states the action and outcome. Every word contributes, and there is no 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?
For a tool with one simple parameter and no output schema, the description provides the essential purpose. However, the lack of behavior details (e.g., state requirements, reversibility, expected result) leaves some gaps for an agent deciding to invoke it. It is minimally sufficient 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 schema has one parameter (`id`) with a generic description 'ID of the resource'. The tool description adds no further parameter explanation, but given 100% schema coverage, the baseline of 3 applies. The tool name and description imply that `id` is the access request ID, but no explicit clarification is added.
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 (finalize) and the resource (submitted access request), and specifies the outcome (approves and grants access). The 'Admin:' prefix also distinguishes it as an admin-only operation, setting it apart from related tools like `submit_access_request` or `revoke_access_request`.
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 'Admin:' prefix and the verb 'finalize' imply this is to be used after an access request has been submitted, and only by admins. It provides clear usage context but does not explicitly name alternatives or exclusion conditions, so it falls slightly short of a top score.
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 does not explicitly state that the operation is read-only, whether admin privileges are required, or what scope the count covers (e.g., current organization vs. all). This leaves ambiguity 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is easy to parse and front-loaded with the key term 'Count'. It wastes no words and 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 tool with no parameters and no output schema, the description is adequate but lacks clarity on scope (e.g., organization-wide count?) and what exactly constitutes 'pending'. It also does not describe the return value in detail, though 'Count' implies a number. This is a minor gap for such a simple tool.
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 fully covers parameter semantics. The description adds no parameter information, but with 0 params the baseline is 4, and there is nothing to add.
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 that this tool returns a count of pending membership requests, with a specific use case for badging admin dashboards. It distinguishes itself from sibling tools like list_membership_requests by focusing on a count rather than a list.
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 context ('for badging admin dashboards') indicating this is for use when a simple count is needed. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks full 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 full burden. It notes the visibility filter ('visible-to-current-user') which is a behavioral trait, but does not disclose return format, pagination, or edge cases (e.g., tags with zero counts). It's a likely read-only operation, but this is not explicit. Adds some value but lacks richer 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?
A single, front-loaded sentence that conveys the tool's purpose and use case without waste. 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?
Given the tool is a simple count operation with no output schema, the description should explicitly state the return format (e.g., a mapping of tag_id to count) and whether tags with zero assets are included. It does neither, leaving some ambiguity. It is adequate but not 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?
Schema coverage is 50%: taxonomy_id has a generic description ('ID of the resource') and taxonomy_tag_ids has none. The description clarifies that counts are computed per taxonomy_tag_id, which helps, but taxonomy_id's role is still somewhat vague (though implied by the tool name). The description partially compensates for the schema gaps.
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: count assets visible to the current user for each taxonomy tag ID. It specifies the resource (taxonomy tags) and the purpose (tree view counts), distinguishing it from sibling tools like get_taxonomy_tags_tree or get_asset_counts.
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 use case ('for displaying counts in a tree view'), implying when this tool is appropriate. It does not explicitly name alternatives or exclude when not to use it, but the context is sufficient for a tool of this specificity.
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 key behaviors: the slice is queued (async operation) and creates a new asset (non-destructive), and optionally adds to a lightbox. However, it does not mention whether the operation returns a job ID, any permissions required, or what happens to the original asset beyond implied non-destructiveness.
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 core action and parameters, with no superfluous detail. Every phrase contributes value: the action, the unit specification, the 'new asset' distinction, and the optional lightbox behavior.
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 mutating, queued action with no output schema, the description covers the main purpose and key side effects, but lacks details about the returned result (e.g., job ID, asset ID) and any constraints (e.g., start < end). It is adequate for basic understanding but leaves important operational context unspecified.
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 leaves `start` and `end` without descriptions, but the description adds crucial meaning by specifying they are in seconds. It also clarifies that `lightbox_id` is optional. The `id` parameter description in the schema is minimal, and the description doesn't add more, but with 50% coverage, the added units and optionality compensate well.
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 identifies the action (slice), resource (video asset), and output (brand-NEW asset), and distinguishes it from the sibling `slice_new_asset_version` by explicitly stating 'new asset' rather than a version. It also mentions the optional lightbox addition, making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for creating a new sliced asset, and the qualifier 'brand-NEW' hints at when to use it, but it does not explicitly state when not to use it or mention alternatives like `slice_new_asset_version`. Without an explicit comparison, the usage guidance remains implied rather than clearly stated.
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. It discloses the prerequisite state, but does not explain what happens after processing starts (e.g., async behavior), whether it's reversible, or what errors occur if the job is not in the 'analyzed' state.
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 that front-loads the action and condition, with no wasted 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?
The tool is simple with one parameter and no output schema, but the lack of annotations and absence of outcome details leave gaps. The agent knows the precondition but not what the response will be or how failures are signaled, making it somewhat incomplete for a state-transition action.
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 fully describes the single 'id' parameter as 'ID of the resource' (100% coverage). The tool description adds that this refers to a tag-import job, but does not provide additional syntax or format details, staying at the baseline for high 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 action ('Start processing') on a specific resource ('tag-import job') and includes a precondition ('in the analyzed state'). This effectively distinguishes it from sibling tools like create_tag_import, update_tag_import, and get_tag_import.
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 'once it is in the analyzed state' provides a clear condition for when to use the tool. It doesn't explicitly mention when not to use it or list alternatives, but the state-based guidance offers sufficient context for the job workflow.
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. It discloses the action and the 'in-progress' constraint, but doesn't explain what happens if the export isn't in-progress, whether the change is reversible, or if it triggers emails. The term 'toggle' also adds ambiguity about whether it flips or sets the value.
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?
One sentence, front-loaded with a specific verb, and no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 setter, and the description plus schema cover essential inputs and the action. The 'in-progress' qualifier and guid reference are enough for basic use, but the toggle/set ambiguity and lack of behavior details slightly reduce 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?
Schema coverage is 50% with only guid described. The description compensates by identifying send_email as the flag to toggle, and the schema already documents guid via create_meta_download reference. With only two parameters, this is sufficient.
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 'Toggle' and identifies the resource 'send_email flag' on a 'metadata export', which clearly distinguishes it from siblings like create_meta_download. However, 'toggle' is slightly imprecise because the schema requires a boolean value, implying the tool sets the flag to the provided value rather than flipping the current state.
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 this tool updates an existing metadata export's email preference, and the schema's guid description references create_meta_download. It offers clear context for when to use it (on an in-progress export), but lacks explicit exclusions or alternative tool references.
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?
With no annotations, the description discloses key behavioral traits: it is asynchronous and returns a boolean via { exists: boolean }. This adds value beyond the name and gives the agent necessary information about execution and return format. It does not mention side effects (none implied) or error behavior, but the core traits are covered.
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 primary action and includes the return type. There is no filler or redundant content; every word contributes useful information.
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 one-parameter tool without an output schema, the description is complete: it explains the purpose, provides an example, notes async behavior, and specifies the return shape. It lacks edge-case details (e.g., case sensitivity) but these are not necessary for such a straightforward utility.
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% with the parameter described as 'Tag name to check'. The description adds the example of 'artwork inventory numbers' but does not provide additional semantic detail such as case sensitivity, format, or length constraints. Baseline 3 is appropriate since the schema already fully documents the 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?
Description clearly states the tool performs an 'Async uniqueness check for a tag name' with a specific example use case. This distinguishes it from other tag-related tools like create_tag or get_tag by focusing on validation rather than mutation or retrieval.
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 to check uniqueness before creating/updating a tag, and the example ('e.g., for artwork inventory numbers') provides context. However, it does not explicitly state when to use this vs. alternatives or mention any exclusion criteria, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the asynchronous background nature and the return of a { guid } for polling, which is essential behavioral context. With no annotations provided, this compensates partially, but it does not state whether the operation is read-only or any side effects beyond creating the export.
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 with no filler, front-loading the key action and return behavior. Perfectly concise.
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 creation tool with 4 params, the description covers the essential process: initiate export, get guid, poll status. It does not detail how to poll or retrieve the final CSV, but the reference to 'poll status' gives adequate direction. No output schema exists, so the return format is stated.
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?
Input schema descriptions cover all 4 parameters with 100% coverage, so baseline 3 applies. The description does not add parameter-specific meaning beyond indicating it's a metadata CSV export, so no additional 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?
Description states the specific verb 'kick off' and resource 'background metadata CSV export', clearly distinguishing it from sibling tools like list_meta_downloads and create_download. It also notes the return format, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for initiating a background metadata CSV export but offers no explicit when-to-use guidance or exclusions. Sibling tools like create_download and bulk_download_assets exist, so alternatives are not addressed.
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?
With no annotations provided, the description discloses a key behavioral trait: tags inside the taxonomy are detached, not deleted. This helps the agent understand side effects. However, it does not mention permissions, reversibility, or the fate of detached tags beyond detachment.
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 with the main action stated first and a clarifying side effect second. It is concise and every word contributes meaningful information.
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 single-parameter delete tool with no output schema, the description covers the core purpose and the most important side effect. It lacks details on return values or error conditions, but these are less critical given the tool's 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?
The schema already provides a description for the only parameter ('ID of the resource'), and the tool description clarifies that the id refers to a taxonomy. The description adds no further parameter-specific details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 a clear resource ('taxonomy'). It also clarifies that tags inside are detached, not deleted, which distinguishes it from related tools like delete_tag and delete_taxonomy_tag.
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 implicitly tells the agent when to use this tool (to delete a taxonomy), but it does not explicitly contrast it with alternatives like delete_tag or delete_taxonomy_tag, nor does it state when not to use it. The side-effect note provides some context but no direct usage guidance.
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 clearly says 'Trigger', implying an asynchronous operation, and indicates a backfill scenario. However, it does not mention idempotency, whether existing face tags are overwritten, or what the response indicates, which are potential gaps for a mutation-like trigger.
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 of 18 words. It leads with the action and resource, then adds the conditional context. There is no redundant information 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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description adequately covers purpose and usage context. It could be improved by noting that detection is asynchronous and how to verify results, but this is a minor gap given the straightforward nature of the 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% with the parameter 'id' described as 'ID of the resource', which is generic. The tool description adds no additional parameter context. Since the single parameter is self-explanatory and the schema fully describes it, 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 states a specific action ('Trigger face detection') on a specific resource ('existing video asset') with a clear context ('for videos uploaded before video face tagging shipped'). This distinguishes it from sibling face-related tools like tag_video_face or get_asset_face_taggings, which handle tagging or querying rather than backfill detection.
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 explicitly scopes the tool's use to videos uploaded before the face tagging feature shipped, which tells the agent when this tool is appropriate. It does not name alternatives but the contextual exclusion is clear enough.
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. It discloses a key behavioral trait: it is a 'super-admin diagnostic' that 'shows' match details, implying read-only and privilege requirements. However, it does not explicitly state that it does not modify data, nor does it mention rate limits, output format, 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 that conveys the essential purpose and context without wasted words. Every word contributes.
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 modest complexity (3 params, no output schema), the description covers the core behavior and output concept ('which fields/terms matched'). It omits details like response format or error conditions, but the diagnostic nature and schema fill in much of the 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 100%, so baseline is 3. The description does not add substantive detail about parameters beyond what the schema already provides ('id', 'q', 'text_q' are self-explanatory). It does not clarify mutual exclusivity of q and text_q, but that is already partially 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 clearly states a specific verb ('show') and resource ('which Elasticsearch fields/terms matched a query for a given asset'), with role context ('super-admin diagnostic'). It distinguishes from sibling tools like search_assets by focusing on explanation rather than execution.
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 'super-admin diagnostic' provides clear context for when to use this tool (diagnosing search matching for assets) and implies it is not for general search. It does not explicitly name alternatives or exclusions, but the diagnostic framing gives adequate usage direction.
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. It discloses the public flow context which hints at authentication requirements, but it does not describe return values, error behavior, or whether the operation is read-only. For a simple lookup, some of this is expected but missing.
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 of 11 words. It is front-loaded and every word earns its place, stating both the action and the context with zero waste.
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), the description is mostly complete for selection and invocation. It tells the agent what and when, but omits details about the response shape and error handling. With no annotations, a bit more detail would improve completeness, but it is adequate for a one-param lookup.
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 only one parameter 'token' with zero description coverage. The description adds that the token is for an invite, which gives it meaning beyond the bare schema. However, it does not provide format, constraints, or where the token comes from, so it only partially compensates 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 uses a specific verb and resource: 'Look up an invite by token'. It clearly identifies what the tool does and adds context ('for the public invite-acceptance flow') that differentiates it from sibling tools like list_invites or accept_invite.
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 by specifying the tool is for the public invite-acceptance flow. This implies its intended use, though it does not explicitly name alternative tools or state exclusions. It tells the agent when this tool is appropriate, but not when to use another tool instead.
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 'Find' and does not disclose behavioral traits such as whether authentication is required, rate limits, error handling (e.g., what happens if slug not found), or whether the operation is strictly read-only. The text does not explicitly guarantee non-mutating behavior, which is a notable gap for an unannotated 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 concise sentences. The first states the core function, the second gives usage context. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param lookup, the description is largely complete: it states what it does, when to use it, and the key input. There is no output schema, but the tool's purpose implies returning an organization object; the description doesn't specify return fields or error cases, which would improve completeness. However, given the simplicity and existing sibling context, it covers most necessary guidance.
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 input schema only defines slug as a string, offering no semantic meaning. The description adds valuable context by explaining the slug's real-world use ('custom-domain URL or know the slug but not the id'), which helps the agent understand what value to provide. This goes beyond the schema's bare type definition, though a bit more detail about slug format would elevate it further.
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 ('Find') acting on 'an organization' via a specific method ('by slug'). It distinguishes from siblings like get_organization by clarifying this tool resolves a slug to an organization, exactly for cases where the id is unknown. The mention of 'custom-domain URL' further clarifies use case.
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 explicit context for when to use: 'when you have a custom-domain URL or know the slug but not the id.' This implies alternatives like get_organization are for when you have the id, though it doesn't name the sibling explicitly. It effectively guides the agent on when this tool is appropriate compared to other organization-related tools.
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 must carry the full burden. It explains the core logic (returns changed asset ids, fallback behavior) and implies a read-only operation, but does not mention potential caveats like whether trashed/deleted assets are included, pagination, or permission requirements beyond what's in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary behavior followed by a use case. Every word earns its place; there is no redundancy or fluff.
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 read-only sync helper with no output schema, the description covers the essential behavior and use case. It lacks some details like the exact response format (though 'asset ids' implies a list) and whether pagination exists, but it is reasonably complete given the tool's simplicity and the schema's full coverage.
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, so the baseline is 3. The description adds one useful detail—the specific server-tracked field name 'last_external_sync_at'—but does not elaborate on any_user or created_via, which are already documented 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 clearly states the tool's function: it returns asset ids changed since a timestamp, with a specific fallback to the server-tracked last_external_sync_at. It also labels itself as a sync helper and suggests its use for export/mirror jobs, distinguishing it from general asset search or retrieval tools.
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 explicitly mentions the tool is useful for export/mirror jobs, giving clear context for when to use it. However, it does not name alternative tools or explicitly state when not to use it, so it falls short of full exclusion guidance.
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 of behavioral disclosure. It mentions what the catalog contains (grouped, IPTC, custom meta fields, basic set), which adds useful context, but it does not disclose the output format (e.g., array structure), return size, pagination, or any side effects. For a read-only getter, the description is somewhat transparent but not fully explicit about the operation being non-mutating.
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 that is front-loaded with the core action ('Get the column catalog') and includes essential detail about the catalog's scope. Every word contributes meaning, with no fluff or repetition.
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 has no parameters and no output schema, the description provides a reasonable high-level explanation of what is returned (a column catalog with specific categories). It is complete enough for a simple getter. However, it could slightly improve by clarifying what a 'catalog' entails structurally (e.g., list of column names and metadata), but the provided detail is adequate for most users.
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 and a 100% schema coverage (empty schema). Baseline for 0 params is 4. The description does not need to add parameter details since there are none. It correctly implies that no input is required, which aligns with 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 clearly states the tool's function with a specific verb ('Get') and resource ('column catalog for metadata exports'). It distinguishes itself from sibling tools like list_meta_downloads by focusing on the column catalog, not the exports themselves, and even enumerates the included column sets (grouped + IPTC + custom meta fields + basic).
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 to retrieve available columns for metadata exports, but it does not explicitly state when to use it compared to alternatives (e.g., before creating a meta download). It lacks an explicit 'when/when-not' recommendation, but the context is not misleading. The guidance is minimal but adequate for a simple getter.
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 discloses that this is a preview ('would be sent' and '(preview)'), which implies no email is actually sent. However, it does not explicitly state whether the operation is read-only or if any state is changed, and it lacks details about 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, well-structured sentence that front-loads the verb 'Render' and includes all essential information without any wasted words. It is appropriately concise.
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 annotations), the description covers the core functionality sufficiently. It explains what the tool does, the resource it operates on, and that it is a preview. Missing details like return format or error cases are not critical for this simple preview tool.
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 input schema only says 'ID of the resource', which is generic. The description clarifies that 'this share' refers to the share whose email body is being rendered, thereby giving the 'id' parameter a concrete meaning. This adds value 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 uses a specific verb ('Render') and a specific resource ('the HTML email body that would be sent for this share'), clearly distinguishing it from sibling tools like get_share or list_shares. The added '(preview)' clarifies the operation is a rendering, not an actual send, 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 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 to preview the HTML email body for a share, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. The context is implied rather than directly stated.
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 of behavioral disclosure. It adds a useful scope (tags created/updated by the job) and implies a non-mutating list operation, but it does not explicitly state whether the tool is read-only, mention any permission requirements, or describe behavior when the job ID is invalid. The 'List' verb implies safety, but this is not fully 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, concise sentence that front-loads the action and object, with no wasted words. It is easily parsed and directly usable.
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 description is adequate for a simple list operation with 100% schema coverage, but it lacks any mention of pagination behavior or the structure of the returned tags. Given no output schema and no annotations, a bit more detail about return types or pagination would improve completeness, but the tool's simplicity keeps it within acceptable range.
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 covers all three parameters, and the description adds meaning by clarifying that 'id' refers to the tag-import job, which is ambiguous from the schema alone ('ID of the resource'). The pagination parameters are self-explanatory, so the description's clarification of the primary parameter adds value over 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 clearly states the operation (List), the resource (tags), and the specific scope (created/updated by a tag-import job), which distinguishes it from general tag-listing tools like list_tags and get_tag.
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 case—listing tags associated with a specific tag-import job—but it does not explicitly state when to prefer it over alternatives like list_tags, nor does it mention any exclusions. The context is clear enough to infer the intended scenario, but guidance on alternatives is absent.
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 provided, so the description must carry the burden. It discloses the core hierarchical behavior but omits details like recursion depth, empty-tag handling, sort order, or response structure. Provides some context beyond the name, but gaps remain.
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?
One sentence, front-loaded with the key verb and resource, no wasted words. Clearly conveys the core functionality.
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?
With no output schema, the description needs to indicate return type. 'Hierarchical tree view' gives a good hint. For a single-parameter read operation, this is fairly complete, though a bit more detail on tree structure would push it to 5.
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% (taxonomy_id described as 'ID of the resource'), but that description is generic. The tool description adds 'within a taxonomy', but does not clarify what taxonomy_id references or any formatting constraints. Baseline 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?
Clearly states it provides a hierarchical tree view of taxonomy_tags within a taxonomy, with parent→children relationship. Distinguishes from flat list tools like list_taxonomy_tags.
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 use when a hierarchical tree structure is needed, which distinguishes it from flat tag list tools. However, it does not explicitly state when not to use it or mention alternatives by name.
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. It clearly indicates a read-oriented list operation and adds a selection criterion, but it does not disclose potential behavior like pagination, ordering, response shape, or any access requirements. This is adequate for a simple list tool but leaves room for more 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, concise sentence that front-loads the action and resource. Every word earns its place, and there is 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?
For a zero-parameter list tool, the description is nearly complete: it names the resource and the filtering criterion. However, without an output schema, it would benefit from a brief note about what is returned (e.g., list of portal IDs/names), so it is not quite a 5.
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 baseline for zero-parameter schemas is 4. The description adds no parameter-specific semantics, but none are needed since the schema is empty and coverage is complete.
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 ('List') and a clear resource ('featured contribution portals') with a parenthetical explaining what 'featured' means in the UI. This distinguishes it from sibling tools like list_contributions and get_contribution.
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 parenthetical '(those highlighted in the org UI)' implies when to use this tool—when you need only UI-featured contribution portals—but it does not explicitly state when not to use it or mention alternatives such as list_contributions for unfiltered lists. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that this returns only standalone/link-only contributions, but it omits any detail on return format, ordering, or pagination. For a simple read-only list tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully states the tool's purpose without any filler. It front-loads the essential information.
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 (no params, no output schema, no annotations), the description is nearly complete for understanding its purpose. The only slight gap is not elaborating what a 'standalone (link-only) contribution' specifically entails, but the sibling context clarifies this.
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 and schema coverage is 100% (vacuously). Per the baseline for 0 params, the score is 4; the description adds no parameter-specific information because there are none to describe.
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 identifies the tool as listing 'standalone (link-only) contributions,' with a specific verb and resource. The qualifier 'standalone (link-only)' distinguishes it from sibling tools like list_contributions, list_group_contributions, and list_lightbox_contributions.
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 (when you need link-only contributions) but does not explicitly contrast it with list_contributions or other contribution list variants. No exclusions or alternatives are stated, so guidance is merely 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 provided, so the description must cover the safety and behavior profile. It conveys the core action and its purpose, but does not disclose whether promoting a tagging overwrites an existing canonical face, whether it is reversible, or any permission requirements. These gaps prevent a higher score, though the core behavior is clearly stated.
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 exactly two sentences, front-loaded with the primary action ('Promote a tagging') and followed by concise usage context. Every word contributes value with 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?
For a simple tool with one parameter, no output schema, and no annotations, the description provides the essential purpose and the workflow context. It lacks edge-case behavior (e.g., what happens if no face cropping exists) but is adequate for a low-complexity tool, and the sibling context reinforces its role.
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 100% coverage with a generic 'ID of the resource' description, so the baseline is 3. The tool description adds no additional parameter detail beyond the schema; it neither clarifies that the ID refers to the tagging nor provides format constraints, leaving the agent to infer from the tool 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 uses a specific verb ('Promote') with a clear resource ('a tagging') and outcome ('to the canonical face for its tag'). It also distinguishes itself from siblings by explicitly linking to tag_asset_face and explaining the role in selecting the crop, which is unique among the listed tools.
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 states when to use the tool ('Used after tag_asset_face to pick which crop represents the person'), providing a direct workflow context. It does not explicitly name alternatives to avoid, but the usage context is unambiguous enough for an agent to select it appropriately.
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 description discloses the core behavioral effect (user becomes canonical face) but lacks details on side effects, permissions, or error conditions. With no annotations, the description carries the full burden, and while it covers the main action, it is not comprehensive.
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 concise, two sentences, and front-loaded with the primary action. Every word adds value, and no unnecessary information is present.
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 two-parameter mutation tool with no output schema, the description sufficiently covers purpose and use case. It does not describe return values or errors, but the core function is clearly communicated.
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 clarifies the 'email' parameter (user's email) but leaves 'id' ambiguous as 'ID of the resource' in the schema. Schema description coverage is 50%, and the description partially compensates by mentioning 'person tag' but does not explicitly map id to the tag.
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+resource: 'Associate a person tag with a user (by email).' It clearly distinguishes this from sibling tools like 'reset_tag_face' by specifying the association mechanism and outcome (canonical face).
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 clear context for when to use the tool: 'useful for faceless tags that need to point to a real person.' However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It does disclose the key behavior: it patches only the description field and leaves other fields untouched. However, it does not mention permissions, return values, or error cases, which are relevant 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 sentence that efficiently states the primary behavior, scope, and relationship to an alternative tool. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter patch tool, the description provides purpose, scope, and sibling differentiation. It does not explain return values or authentication, but given the simplicity and lack of output schema, this is mostly adequate. The only notable gap is the absence of any mention of response behavior or error conditions.
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 covers 50% of parameters (only 'id' has a description). The tool description clarifies that the 'description' parameter is the field to be patched, adding some meaning beyond the bare schema. However, it does not provide additional format or constraints beyond what is already obvious.
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 ('Patch'), identifies the resource ('description field on an asset'), and clearly distinguishes from the sibling tool update_asset by explicitly limiting scope to the description field only.
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 'lighter than update_asset; does not touch other fields' gives clear context for when to use this tool versus update_asset. It implies using this when only the description needs updating, though it doesn't explicitly state exclusions for other scenarios.
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?
With no annotations, the description carries the behavioral disclosure burden. It discloses the critical non-obvious behavior that the SQL query is immutable after creation, which prevents users from expecting to modify it. It does not mention other behavioral aspects like permissions or return values, but for a simple update tool, this is a meaningful and sufficient 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 two sentences with no redundant wording. The action is front-loaded, and the critical note about SQL immutability is placed at the end. Every word earns its place, 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.
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 three parameters and no output schema, the description is adequate but leaves gaps: it does not clarify whether updates are partial or full, whether both name and description can be updated in one call, or what happens if an attempt is made to change the SQL query. These are relevant for successful invocation and correct behavior, so the description is not fully 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?
Schema description coverage is only 33% (only id has a generic description). The description adds minimal value by stating that name and description are updatable, but it does not clarify the id parameter's meaning (e.g., that it references the search query ID) or provide any format or usage details. With low schema coverage, the description should compensate more thoroughly.
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 a saved search query's name or description, using a specific verb and resource. It distinguishes itself from sibling tools like create_search_query, delete_search_query, and get_search_query by explicitly limiting updates to name/description and noting that SQL cannot be changed.
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 when to use this tool (to update name/description) and provides a key constraint: the SQL query cannot be changed after creation, effectively telling users not to use this tool for SQL changes. However, it does not explicitly name alternative tools or provide a when-not-to-use scenario beyond the SQL limitation.
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?
There are no annotations, so the description carries the full burden. It does disclose a key behavioral trait: approving picks advances only the chosen assets. However, it does not mention side effects, permissions, preconditions, or what happens to unapproved assets. The reference 'Same shape' is a useful shorthand but relies on knowledge of the sibling 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 only two sentences, front-loaded with the primary action and followed by the distinguishing behavior. Every sentence 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters, no annotations, and no output schema, the description covers the core function and the key differentiator from the sibling. However, it omits details like what happens after approval, whether the action is reversible, and what the response contains. The 'same shape' reference is a shortcut that may not be self-contained for an agent.
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 only 50% (asset_ids lacks a description). The description adds context by equating 'picks' with 'chosen assets,' implying that asset_ids identifies which assets to approve. This provides some meaning beyond the schema, but it does not explicitly describe the parameter format or clarify the exact relationship between id and asset_ids beyond the generic 'ID of the resource.'
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 ('Approve') and resource ('a curated subset (picks) within a workflow step'), making the tool's function obvious. It also distinguishes it from the sibling tool by noting 'Same shape as approve_workflow_step but only the chosen assets advance,' which differentiates it from the full-approval variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool 'approve_workflow_step' and specifies the difference: 'only the chosen assets advance.' This tells the agent when to use this tool (for a subset of assets) versus the sibling (for all assets), meeting the explicit alternative requirement.
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 aspects on its own. It only states the action (update AASM status) with examples, but does not mention required permissions, side effects, valid state transitions, or reversibility. 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 only two sentences long, front-loads the action, and the differentiation is packed into the second sentence without any unnecessary words. Every sentence 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?
The description covers the core function and differentiates from the sibling, but because there are no annotations and no output schema, it lacks information about response format, error conditions, or required permissions. For a mutation tool, this is a notable gap, making the description merely 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 schema already covers both parameters at 100%, but the description adds value by giving concrete examples of valid statuses ('activate, suspend'), which clarifies the otherwise vague 'Target AASM state' schema text. This goes beyond the structured data.
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 'Update', the resource 'membership', and the specific scope 'AASM status'. It explicitly contrasts with `update_membership`, which patches role_level/preferences, making the purpose unambiguous and differentiated from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly names the alternative tool (`update_membership`) and clarifies what it does instead, providing explicit when-to-use and when-not-to-use guidance. This is exactly what the dimension asks for.
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 adds the 'public flow' context and clarifies the token type, but it doesn't mention side effects (e.g., invite consumption), potential auth requirements, or failure modes. Sufficient for a simple accept action but leaves some gaps.
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 that states the action, specifies the token type, and differentiates from a sibling. Every part is informative with no fluff or repetition.
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 annotations), the description covers the key context: what it does, how it's triggered, and how it differs from a closely related tool. It doesn't specify post-acceptance behavior, but for a one-parameter action, this is largely complete.
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 only defines `token` as a string with no description (0% schema coverage). The tool description compensates by explaining the token is an 'email-link token', giving essential meaning to the parameter. This is helpful and adequate for a single 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 the action ('Accept an invite') and the specific mechanism ('using its email-link token'). It explicitly distinguishes this from the sibling `accept_my_invite`, which targets a different flow. This provides a specific verb, resource, and scope with strong differentiation.
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 usage context by labeling this the 'public flow' and contrasting it with `accept_my_invite` (which is profile-scoped for authenticated users). This tells an agent when to use this tool versus the alternative, though it could be more explicit with a direct 'use this when' statement.
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. It transparently discloses the stub behavior: 'otherwise unsaved Tag-shaped records the agent can persist,' making clear this does not persist changes itself. This is valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no filler or redundant information. It earns every word.
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?
With no output schema or annotations, the description does a good job covering the key return semantics: existing matches vs unsaved stubs. It lacks details on the stub record structure or error behavior, but for a single-parameter tool, it's largely complete.
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 only defines a 'names' array of strings with no description. The description clarifies that these are tag names via 'by name' and implies the array is for many tags. However, it doesn't specify constraints like exact matching, case sensitivity, or duplicate handling, leaving some gaps.
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: 'Find or stub many tags by name in a single call.' It distinguishes itself from sibling tools like get_tag (single tag) and bulk_find_auto_tags (auto tags) by specifying 'tags' and 'many by name.'
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 via 'many tags by name in a single call' – indicating it's for batch name lookups. However, it doesn't explicitly name alternative tools (e.g., check_tag_name, create_tag) or state when not to use it, so guidance is only 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 of disclosing behavior. It does mention two key behavioral traits: it 'clears the moderation flag' and 're-indexes', which indicates a mutating action with a side effect. However, it does not discuss reversibility, permission requirements, or behavior if no flag exists, making it only partially transparent.
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, well-structured sentence that front-loads the primary purpose ('Mark an NSFW detection as a false positive') followed by the concrete effects. Every word earns its place; there is 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 one-parameter tool with no output schema, the description provides the core action and a notable side effect (re-indexing). It lacks details on error conditions or permissions, but these are less critical given the tool's simplicity. The description is complete enough for an agent to understand the tool's purpose and primary behavior.
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 input schema has 100% coverage but the parameter description 'ID of the resource' is generic. The tool description clarifies that the 'id' refers to the asset, adding meaning beyond the schema. This is sufficient for a single parameter tool, hence above the baseline 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 clearly states the tool's function with a specific verb ('Mark') and resource ('an NSFW detection as a false positive on an asset'). It also explains the concrete actions it performs ('clears the moderation flag and re-indexes'). This distinguishes it from sibling tools like ignore_asset_unidentified_faces, which deal with faces rather than NSFW moderation flags.
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 on when to use the tool: when an NSFW detection is identified as a false positive. It implicitly indicates this tool is for clearing false positives, but it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does disclose potentially destructive actions ('destroy_all', 'restore_all') and overwrite behavior ('cmf_overwrite_mode (skip/overwrite)'), which adds useful transparency. However, it does not explain whether the job runs asynchronously, what side effects occur on invocation, or any permission requirements beyond a hint in the schema ('rerun_auto_tag super-admin only'). The description is informative but not fully transparent about the execution model and downstream 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 well-structured as a bulleted list of operation types, front-loading the core purpose and then organizing parameters into logical groups. Every sentence adds useful information without redundancy. It is appropriately sized for the tool's complexity—comprehensive yet scannable.
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 high complexity (26 parameters, rich schema, no output schema), the description is relatively complete: it covers the major operation types and parameter combinations. However, it misses the rename-preset and remove-from-group parameter groups, and it does not mention what the job returns (e.g., a bulk job ID for tracking via get_bulk_job). These gaps are notable but not severe, so the description is close to complete for a tool of this scope.
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?
Although schema description coverage is 100%, the description adds significant value by grouping parameters into high-level operation categories (e.g., 'Metadata updates: use description + description_mode, rating, rights_package_id') and explaining which parameters work together. This goes beyond the schema's individual field descriptions. However, it omits some parameter clusters such as rename operations (rename_preset_id, rename_custom_text) and remove-from-group operations (remove_asset_group_id, remove_asset_group_type), leaving some combinations undocumented.
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 a bulk job for batch operations on assets' and then enumerates specific operation types (tags, metadata, organization, AI, bulk actions), which distinguishes it from more specialized sibling tools like bulk_edit_assets or bulk_add_tags_to_assets. The verb 'create' plus the resource 'bulk job' and the detailed scope make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing what each operation type entails (e.g., 'Tag management: use tag_names + tag_mode') and how to combine parameters. However, it does not explicitly state when to prefer this tool over alternatives like bulk_add_tags_to_assets or bulk_set_asset_rights_package, nor does it mention when not to use it. This is close to a 4 but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 reveals that the session is 'long-lived', supports appending over multiple calls, returns a session guid plus aws_key/bucket, and requires a follow-up call to set_upload_done. This is valuable context, but it omits potential details like session expiry, cancellation, or permission requirements (e.g., can_upload).
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 three concise sentences. The first sentence states the core function, the second gives when-to-use scenarios, and the third covers the return value and required next step. Every sentence 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively compensates for the lack of an output schema by explaining the return value (session guid plus aws_key/bucket) and the critical follow-up (set_upload_done). It provides enough lifecycle context for a typical batch-upload workflow, though it doesn't mention session expiry, cleanup, or prerequisite permissions, leaving minor 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 input schema has 100% description coverage, meaning every parameter already has a clear description in the schema. The tool description does not add additional parameter-level semantics beyond what the schema provides, 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 a specific action and resource: 'Create a long-lived upload session.' It goes on to explain the session's purpose ('append files to over multiple upload_file / upload_files calls') and distinguishes it from related tools by mentioning grouping in the Mediagraph UI and resume-after-crash capabilities. This makes it unmistakable what the tool does and how it relates to sibling upload tools.
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 explicit when-to-use guidance: 'Use this when batch-uploading many files from a script or agent loop, when you want them grouped under one upload in the Mediagraph UI, or when you need to resume after a crash.' It also references the relevant sibling tools (upload_file, upload_files, set_upload_done). However, it lacks an explicit when-not-to-use statement (e.g., for single-file uploads), which would have pushed it to a 5.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently states a key behavioral trait: the author-only restriction and the implication that non-authors will be rejected. It does not detail other side effects (e.g., irreversibility, cascade deletion of replies), but for a simple delete tool this is a reasonable 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 consists of two concise sentences, front-loaded with the action ('Delete a comment') followed by the essential authorization rule. Every word earns its place; there is no waste 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 1-parameter delete tool with no output schema, the description covers the core purpose and the critical usage constraint. It does not explain the return value or behavior on failure, but these are often implicit for delete operations. Overall, it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single 'id' parameter, but its description ('ID of the resource') is generic and does not specify 'comment'. The tool description implicitly clarifies that the id refers to a comment, adding meaning beyond the schema. However, no additional syntax, format, or validation details are provided, 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 tool's action: 'Delete a comment.' This is a specific verb+resource pairing that distinguishes it from sibling tools like create_comment, update_comment, and list_comments. The additional authorization constraint ('Only the comment author can delete their own comments') further clarifies 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 provides a clear usage rule: only the comment author can perform the deletion. However, it does not explicitly mention alternatives or when to use this tool vs. others (e.g., update_comment for editing, list_comments for viewing). The authorization context is helpful, but exclusion/alternative guidance is absent.
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 of transparency. The verb 'Find' clearly indicates a read-only operation, and the description explains what the tool returns. However, it does not mention authentication requirements, behavior when the asset is not found in the group, or whether the result is a user object or ID. This is adequate for a simple lookup but leaves some gaps.
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, well-structured sentence that immediately conveys the tool's purpose. Every word earns its place, and the parenthetical clarification of asset_group types is useful without adding clutter.
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 two-parameter lookup tool, the description is largely complete: it explains what the tool does, the meaning of the parameters, and the scope of asset_group. However, it does not specify the return format (e.g., user object, user ID) and does not address potential error conditions. Given the complexity, these omissions are minor but slightly reduce 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 description adds meaning beyond the schema by specifying that 'asset_group_id' refers to a collection, lightbox, or folder, and implicitly clarifies that 'id' is the asset ID. Since the schema only describes 'id' as 'ID of the resource' and provides no description for 'asset_group_id', this textual clarification is valuable and compensates for the 50% 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 tool's purpose with a specific verb ('Find') and resource ('which user added a given asset to a given asset_group'). It also clarifies that asset_group includes collections, lightboxes, and folders, which distinguishes it from related tools. This is highly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when you need to know the user who added an asset to a particular asset_group. It provides context but does not explicitly mention alternatives or exclusions. Since the tool is quite specific, the context is sufficient for most agents to select it correctly.
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 must fully communicate behavior. It correctly implies this is a read-only retrieval ('Get'), but it does not explicitly state that it has no side effects, whether OTP must already be enabled, or how it relates to enable_my_otp. Some behavioral context is present but not fully 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, front-loaded sentence with no fluff. It efficiently conveys the action, resource, and purpose without exceeding necessary length.
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 zero-parameter tool with no output schema, the description sufficiently covers what is returned and its intended use. A minor gap is that it does not mention prerequisites or the relationship with enable/disable_my_otp, but the tool is simple enough that the description is essentially complete.
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 no parameters, so the baseline is 4. The description adds context about the output's purpose (encoding in a QR code) which is helpful, though not required for parameters. No additional parameter 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 uses a specific verb ('Get') and identifies the exact resource ('otpauth:// URI') and purpose ('setting up TOTP 2FA') on the current user account. This clearly distinguishes it from sibling tools like enable_my_otp and disable_my_otp, which are about enabling/disabling rather than retrieving the setup URI.
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 indicates the use case: setting up TOTP 2FA. However, it does not explicitly mention when not to use this tool or name alternatives (e.g., 'use enable_my_otp after generating the URI'). The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral transparency. It explains that the result is role-derived abilities and indicates how the tool aids in error interpretation, but it does not describe the return format or behavior on failure. This adds some context but leaves gaps.
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 concise, consisting of two sentences that immediately state the purpose, provide examples, and give actionable pairing advice. Every word earns its place, with no 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 description covers the tool's purpose and provides valuable usage context, but with no output schema, it does not fully specify the return format. Given the simplicity of a one-parameter getter, it is mostly complete but could benefit from a note on the expected response structure.
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 description for 'id' is generic ('ID of the resource'), but the description's phrase 'in an organization' hints that the id refers to an organization, adding meaning. Since schema coverage is 100%, the baseline is 3, and this extra context justifies a 4.
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 role-derived abilities for the current user in an organization, with concrete examples like 'manage Asset' and 'view_details Tag'. This distinguishes it from sibling tools such as whoami or get_membership by focusing on abilities rather than identity or membership.
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 explicit guidance to pair with INSUFFICIENT_SCOPE errors to distinguish role denial from missing token scope, which is an actionable usage context. However, it does not explicitly mention alternatives or when not to use the tool, so it is slightly below a perfect score.
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. It correctly indicates a read-only fetch operation, but it does not disclose any edge behaviors such as handling of missing IDs, partial failures, or rate limits. The `aggregates_only` parameter changes the response semantics and is not mentioned in the description. Adequate for a simple read but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first states the core action, the second gives a precise workflow recommendation. No filler, front-loaded, and highly scannable for an agent.
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 straightforward batch hydration read with two params, one required. The description sufficiently covers the primary use case, mentions the source (search_assets), and explains the benefit (avoiding round-trips). It does not discuss error handling or response format, but given no output schema, a modest description is acceptable. Slightly more detail on the `aggregates_only` behavior would improve completeness but is already in the schema.
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 the context 'full asset records' and 'one call' which aligns with the `ids` parameter's purpose, but it does not elaborate beyond the schema's 'Asset ids to hydrate.' The `aggregates_only` parameter is only explained in the schema. The description does not meaningfully increase 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 opens with a specific verb-resource construction: 'Fetch full asset records for an explicit ID list in one call.' This clearly distinguishes it from the sibling `get_asset` (single asset) and `search_assets` (query-based, returns summaries). The 'explicit ID list' scope and batch behavior are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit usage context: 'Use after `search_assets` returned a set of IDs and you want full attributes without N round-trips.' This names a specific preceding sibling, states the reason for choosing this tool, and implies the alternative (repeated calls to `get_asset`) is less efficient. Clear when-to-use and no ambiguity.
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 explains the core behavior (listing pending invites) but does not disclose details like output format, pagination, or read-only nature (though 'List' implies it). It adds context by specifying 'pending' and 'org' but lacks deeper behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It is concise, front-loaded with the action and resource, and every word adds value without 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, zero-parameter tool, the description is largely complete. It specifies the resource (org invitations), scope (current user), and status (pending). Given the lack of an output schema, a brief note on return shape could enhance completeness, but it's not necessary for basic usage.
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 there is nothing to explain. The schema already completely covers the empty input. The description correctly adds no parameter details, earning the baseline 4 for zero-parameter tools.
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 (list), the resource (pending org invitations), and the scope (addressed to the current user). This distinguishes it from sibling tools like list_invites and accept_my_invite, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to see the current user's pending organization invitations. It doesn't explicitly mention alternatives, but the 'current user' scope inherently differentiates it from other invite-related tools. No exclusions are needed.
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 of behavioral disclosure. It reveals that the tool re-runs the OAuth flow, implying re-authentication, but does not mention side effects such as invalidation of existing tokens, requirement for user interaction, or impacts on current session. Some transparency is present, but gaps remain.
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 only two sentences, front-loaded with the core action, and contains no redundant or filler language. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (zero parameters, no output schema), the description adequately covers purpose and usage scenarios. It lacks detailed side-effect disclosure, but for a 0-param auth flow tool, the description is reasonably complete and not misleading.
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 trivially covers all parameters. The description provides no parameter-specific information, which is appropriate. A baseline of 4 applies for tools with no parameters, and no deduction is warranted.
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+resource ('Re-run the OAuth authorization flow') and explicitly states two use cases: switching to a different Mediagraph organization or re-authenticating. This clearly distinguishes it from all sibling tools, which focus on other functional domains.
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 explicitly states when to use the tool ('Use this to switch to a different Mediagraph organization or re-authenticate'), providing clear context. It does not mention when not to use it or alternatives, but given no similar sibling tools exist, this is sufficient guidance.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that finalizing triggers post-upload hooks (notifications, contribution acceptance, etc.) and implies a mutating action. It could mention idempotency or error conditions, but it gives relevant side-effect context beyond what the name alone conveys.
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 sentences, with the first stating the core purpose and the second providing usage context. It is front-loaded, direct, and contains no redundant or irrelevant information.
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 one-parameter tool with no output schema, the description covers purpose, side effects, and when to call it. A minor gap is that it doesn't describe the return value or error behavior, but given the simplicity of the operation, this is not a significant deficiency.
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 description for the single 'id' parameter is 100% covered, stating it's the numeric Upload id (NOT the guid) returned by create_upload_session. The description adds no additional parameter detail beyond this, so baseline 3 applies.
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 ('Finalize an upload session, marking it as complete') and distinguishes it from the sibling upload tools (create_upload_session, upload_file/upload_files) by positioning it as the finalization step. It also specifies the side effect (triggers post-upload hooks), leaving no ambiguity about its role.
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 explicitly says to call this after the last upload_file/upload_files in a batch opened with create_upload_session, providing clear sequencing guidance. It doesn't mention when not to use it or alternatives, but no alternative finalize tool exists, so the guidance is sufficient.
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?
With no annotations, the description carries the full burden and does well by disclosing that the operation is asynchronous, queues the result, and requires polling the asset. It also clarifies the result becomes a new version. This goes beyond a simple 'slices' statement, though it omits details like error handling or exact polling 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?
Two sentences with no filler. The core action, parameters, outcome, and async behavior are all front-loaded and clearly stated.
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 moderate complexity (3 params, no output schema, no annotations), the description provides enough to invoke it and understand the next step (poll the asset). It lacks details on how to poll or what completion state to expect, but it is actionable and covers the essential workflow.
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 only describes 'id' generically and leaves 'start'/'end' undocumented. The description adds meaning by specifying 'start' and 'end' are in seconds and that the slice applies to a video asset. However, it does not explain edge cases (e.g., inclusiveness, bounds, format), so it only partially compensates for the low 33% 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 states a specific action ('Slice'), the resource ('video asset'), the parameters ('between start and end (seconds)'), and the outcome ('queue the result as a NEW VERSION of the same asset'). This clearly distinguishes it from the sibling tool 'slice_new_asset' which is likely for creating a new asset.
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: the tool creates a new version of the same asset, rather than a separate asset. It also mentions the async nature ('Async — poll the asset') which guides when to use it. However, it does not explicitly name alternatives or state 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.
Behavior4/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 discloses the key authorization requirement—only the comment author can update—which is essential for an agent to anticipate failures. It does not mention return values or error behavior, but for a simple update operation, this constraint is a high-value transparency element.
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 just two sentences and 15 words, front-loading the core action ('Update a comment') and immediately following with the key constraint. There is no filler or redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (2 fully documented parameters, no output schema, no annotations), the description adequately covers the primary purpose and the critical authorization caveat. It does not specify what the response contains (e.g., updated comment object), but that absence is partially mitigated by the straightforward nature of an update operation. It is functional but not exhaustive.
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: both parameters ('id' and 'text') are described with meaningful details ('ID of the resource' and 'Updated comment text'). The description itself adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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' with the resource 'comment', clearly indicating a mutation operation on an existing comment. It distinguishes itself from sibling tools like create_comment, delete_comment, and list_comments by focusing on the update action, and adds a critical constraint (author-only) that narrows its 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 description clearly implies this tool is for modifying an existing comment, contrasting with create/delete/list siblings. It also provides context about when the operation is permitted (only by the author), but does not explicitly name alternative tools or when not to use it (e.g., 'use create_comment for new comments'). The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the two-step process: returns a signed S3 URL, then PUT the file there to complete. It also notes it initiates a new version, which is a meaningful side effect. Missing permission requirements or failure behavior, but the core flow is well covered.
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 sentences, front-loaded with the primary action, and every word adds value. No fluff or repetition.
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 moderate complexity, no output schema, and no annotations, the description covers the key flow (initiate, signed URL, PUT) and provides an alternative. It lacks param details but is otherwise complete for an agent to invoke it 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 25% (only id has a description). The description does not explain filename, content_type, or file_size beyond their names, nor clarify how they relate to the upload. With low schema coverage, the description should compensate, but it doesn't.
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: 'Initiate an upload of a NEW version of an existing asset.' This specifies the verb (initiate upload), resource (asset version), and differentiates from siblings like `upload_file` by focusing on creating a new version rather than a full upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For end-to-end uploads from disk, prefer `upload_file` with the asset id.' This tells the agent exactly when to use this tool versus an alternative, and implies this tool is for staged uploads via signed URL.
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?
With no annotations, the description carries full burden and discloses substantial behavior: Elasticsearch cross_fields matching, implicit id:asc tiebreaker, wildcard/existence operators, and sort behavior. It does not cover output structure, default pagination, or authentication, but for a read-only search tool, the disclosed query semantics are highly valuable.
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?
Though long, the description is well-organized into sections (query syntax, multi-word note, sort, common fields) with no redundant sentences. It front-loads the purpose and then provides dense, structured reference material appropriate for the tool's complexity.
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 20-parameter search tool with no output schema, the description thoroughly covers the query language, sort, and search fields. However, it does not explicitly describe the response format or default result ordering, which would be needed for full completeness. The main functional aspects are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has high coverage (85%), but the description adds deep meaning for the 'q' parameter with full syntax, examples, and field search. It also reveals two undocumented parameters ('order' and 'direction') and lists common search fields, going far beyond the schema's terse descriptions. This significantly enhances 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 immediately states 'Search for assets using filters and advanced query operators', clearly identifying the verb (search), resource (assets), and the capability (filters and advanced operators). It distinguishes from sibling tools like get_asset (single asset by ID), search_asset_faces (face-specific search), and search_assets_visual (visual search) by focusing on metadata and query syntax.
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 for advanced asset searching but does not explicitly state when to use this tool vs alternatives like search_assets_visual or get_asset. It gives no exclusions or 'when not to use' guidance, so the context is clear but not fully differentiated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool checks storage quota and implies a boolean result, which is sufficient for such a simple, side-effect-free operation. However, it does not explicitly mention return values or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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: 'Check' indicates the action, 'uploads are allowed' specifies the subject, and '(storage quota)' clarifies the basis of the check.
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 (no parameters, no output schema), the description is mostly complete. It states what the tool does and its main criterion (storage quota). It could be slightly more explicit about the return type (e.g., 'returns true if uploads are allowed'), but the name and phrasing strongly imply a boolean result.
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, and the schema coverage is complete (empty object). Per the rubric, a baseline of 4 is appropriate since there are no parameters to describe and the description correctly adds no irrelevant parameter information.
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 ('check') and resource ('uploads'), and clarifies the scope with '(storage quota)'. This clearly distinguishes it from sibling tools like upload_file or list_uploads, 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 Guidelines4/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 to verify whether uploads are permitted before attempting an upload, but it does not explicitly name alternatives or exclusions. It provides clear context without going into when-not-to-use scenarios.
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?
With no annotations, the description carries the full burden. It discloses key behavioral constraints: results limited to top 10 and no pagination. This prevents surprise for users expecting full event history. It does not detail output format, but for a simple read operation the disclosure is sufficient.
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, information-dense sentence: every word adds value. It is front-loaded with the core purpose and includes the critical constraint without any fluff.
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 tool with no parameters, no output schema, and simple behavior, the description is largely complete. However, mentioning that get_tag_events offers pagination or filtering would improve completeness by guiding users to the right tool for extended use cases.
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, and schema coverage is trivially 100%. Per rubric, a baseline of 4 is appropriate since there are no parameter semantics to clarify.
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 'Top 10 most recent tag activity events (no pagination)' clearly states the verb (get), resource (tag activity events), and scope (top 10 most recent, no pagination). It distinguishes itself from sibling get_tag_events by emphasizing recency and the fixed limit, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '(no pagination)' provides clear context that this tool is for quick retrieval of recent events only, implicitly excluding use cases requiring historical or paginated access. However, it does not explicitly name an alternative like get_tag_events, so it stops short of a full 5.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains the toggle semantics (state flip), the per-asset scope, and contrasts with global blocking, which helps predict side effects. It does not mention return values or errors, but for a simple toggle this is reasonably transparent.
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 long, front-loaded with the action, and every phrase earns its place. It avoids repetition and is immediately scannable.
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 toggle operation with only two parameters and no output schema, the description covers the purpose, use case, and parameter semantics. It lacks details about idempotency or error behavior, but these are less critical for a focused toggle tool, especially given its brevity.
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 coverage is only 50% and the 'id' description is generic ('ID of the resource'). The description adds meaning by clarifying that the tool operates 'per-asset' (so id refers to the asset) and on a 'detected face id' (so face_id is the detected face). This compensates for the schema's lack of specificity.
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: 'Toggle the per-asset "ignore" state on a detected face id.' It identifies the resource (per-asset face), the verb (toggle), and distinguishes itself from global blocking ('without blocking the face globally'), which sets it apart from sibling tools like block_asset_face.
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 use case: 'Useful for hiding low-confidence detections without blocking the face globally.' This implies when to use the tool (per-asset, non-global) and hints at an alternative (blocking globally), though it does not explicitly name siblings or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses a meaningful side effect (reindexing) and the clear-field behavior. It doesn't mention permissions or error cases, but for a simple write operation it provides useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the purpose, and uses a clear bulleted list for the parameter mapping. Every sentence earns its place – no fluff, all high-signal information.
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?
Six parameters, no output schema, but the description explains the conditional parameter selection logic and side effects. It's sufficiently complete for an agent to invoke the tool correctly, though it could mention what happens after clearing or on invalid input.
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 coverage is 100%, so the baseline is 3. The description adds value by mapping field shapes to specific params (value, custom_meta_value_id, custom_meta_value_ids) and explaining the alias relationship for text. This goes beyond the schema's individual 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 starts with 'Write to a custom meta field on an asset' – a specific verb, resource, and target. It is clearly distinguished from sibling tools like set_access_request_custom_meta (different resource) and get_asset_meta (read vs write).
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?
Provides detailed guidance on which parameter to pass based on field shape (free/select/multi), plus how to clear the field. It doesn't explicitly mention alternatives, but the field-shape mapping is strong practical guidance for correct use.
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?
With no annotations, the description adequately signals a read-only operation via 'Return'. It also provides useful context about the current user's permissions and the practical benefit of avoiding BAD_ARGS, though it does not detail the response format or edge cases.
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, front-loaded sentences deliver the core purpose and a key benefit without any fluff. Every sentence 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 getter with no output schema, the description is complete: it states what is returned, for whom, and why it is useful. No significant gaps exist.
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 baseline is 4. The description adds no parameter semantics, but none are 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 the tool returns the list of role_level values the current user can grant in an invite. The verb 'Return' and specific resource make it distinct from create/update invite tools.
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 'Helps prevent BAD_ARGS at create time' strongly implies when to use this tool (before creating an invite). It does not explicitly name the companion tool create_invite or exclude alternatives, but the intent is clear.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It clearly indicates the operation is a read-only enumeration (via 'List') and clarifies the scope ('every organization' and 'across orgs'). It does not describe return format or authentication, but for a simple list operation, the behavior is sufficiently 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 two concise sentences that front-load the core purpose and immediately follow with a practical use case. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides all necessary context: what it does, who it acts on, and why to use it. It distinguishes itself from sibling tools like whoami and get_organization without needing extra detail.
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, which sets a baseline of 4. The description adds meaningful context by stating 'across orgs', explicitly implying that no org filter parameter exists and the operation covers all organizations. This goes beyond the empty 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 action ('List every organization the current user belongs to') and adds the scope 'across orgs', which distinguishes it from org-specific tools like get_organization. The mention of multi-tenant agents further clarifies its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('useful for multi-tenant agents picking which org to operate in'), but does not explicitly name alternative tools or state when not to use it. The 'across orgs' phrasing hints at differentiation from scoped tools, but falls short of full exclusion guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the operation indexes the face into Rekognition and that future uploads will automatically run face matching against this person, which are important side effects. It also clarifies that face_id comes from get_asset_face_taggings. It does not mention return values or error conditions, but the core side effects are well communicated.
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 front-loaded with a clear purpose sentence, followed by a concise three-step workflow and a one-line note about future behavior. Every sentence adds value, and there is no filler or redundancy.
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?
Given the parameter complexity (4 params, 2 required) and absence of annotations or output schema, the description provides sufficient context: the exact workflow, the source of face_id, the tag_id/name alternatives, and the long-term impact of indexing. This is enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters (100% coverage), so the baseline is 3. The description adds value by clarifying the relationship between parameters: face_id is obtained via get_asset_face_taggings, and tag_id/name are alternatives for associating the person tag. This helps the agent understand the parameter roles beyond their terse 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 clearly states the function: 'Manually tag a detected face crop on an image asset and index it into Rekognition for org-wide face matching.' This is a specific verb+resource+outcome that distinguishes it from sibling tools like tag_video_face or reset_tag_face. The workflow further specifies the exact 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 description provides a detailed workflow for the intended use case ('upload a headshot for a person tag'), referencing upload_file and get_asset_face_taggings as prerequisite steps. It clearly conveys when to use this tool within a broader process, but it does not explicitly contrast with alternative tools like tag_video_face or set_tag_face_membership.
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?
With no annotations, the description carries the burden, but the verb 'Get' and reference to 'currently authenticated' imply a safe, read-only operation with no side effects. It discloses the scope of information returned, which is sufficient for this tool type.
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 with no filler or redundancy. Every word contributes to understanding.
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 no-parameter, simple retrieval tool without an output schema, the description adequately covers what the tool does and its context. It is complete enough for an agent to select and invoke it correctly.
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 input schema has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed; the schema fully covers parameter space.
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 ('information about the currently authenticated user and organization'), clearly distinguishing it from sibling tools like get_organization or list_my_organizations. It precisely conveys 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 usage when needing current authenticated user/org context, but does not explicitly mention alternatives or exclusions. The context is clear enough for a simple query tool, so it meets the 'clear context, no exclusions' bar.
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?
With no annotations, the description carries the full transparency burden. It discloses important behaviors: session finalization in default mode, non-finalization with upload_guid, and automatic S3 multipart upload for files >16 MiB. It could also mention return values or error handling, but the provided behavior is detailed and non-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 well-structured with clear sections for body modes, session modes, and the multipart note. Each sentence adds necessary detail, and the formatting with numbered lists enhances readability without being verbose or redundant.
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 description covers the complex parameter interactions and session modes thoroughly, including the >16 MiB multipart behavior. However, no output schema is present, and the description does not mention the response format or error cases, leaving a small gap in completeness for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning to parameters: explaining that file_path is for local files and file_data requires filename, clarifying mutual exclusivity of upload_guid and contribution_id, and describing what happens in the default session mode. This goes well beyond the schema's parameter 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 clearly states the tool uploads a file to Mediagraph and differentiates body modes and session modes. It distinguishes the singular upload_file from siblings like upload_files and create_upload_session by explicitly describing its one-shot and session-append capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: when to use file_path vs file_data, when to use each session mode, and that modes are mutually exclusive. It references related tools (create_upload_session, set_upload_done) and explains the lifecycle consequences, making it clear when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses the default session lifecycle (create, upload, finalize), the non-finalizing append behavior, the contribution routing side-effect, and automatic S3 multipart for large files. These are meaningful behavioral traits not apparent from the schema alone.
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 compact and well-structured: a one-sentence main purpose, then a bulleted list for session behaviors, and a final sentence for large-file handling. Every sentence adds distinct information with no redundancy, and the key use case is front-loaded.
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 tool with session management complexity and multiple mode variants, the description covers the default behavior, parameter-driven modifications, the caller's finalization responsibility, and large-file handling. The lack of an output schema is acceptable because the tool's primary effect is side-effectual (uploading files), and the description sufficiently sets expectations.
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 100%, so baseline is 3. The description adds value by grouping parameters into session behavior scenarios (fresh session, append, contribution), giving the parameters contextual meaning beyond their individual schema descriptions. It also clarifies the caller's responsibility for finalization, which enriches the 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 opens with 'Upload multiple files from the local filesystem in one operation,' which clearly specifies the verb (upload), resource (files), and scope (multiple, from local filesystem). It also differentiates from sibling tools like upload_file (singular) and create_upload_session by framing the operation as a batched, session-managed action.
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 each parameter: default for fresh session, upload_guid for appending, contribution_id for contribution routing. It does not explicitly name alternatives (e.g., upload_file for single files) or state when not to use the tool, but the parameter-specific behavior serves as strong usage guidance.
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?
With no annotations, the description carries the full burden. It discloses key behavioral traits: it may fetch the entity if needed, supports two host modes, and uses hash routes for assets. It does not mention potential side effects or API costs, but given that this is a read-only URL generator, the disclosure is sufficient.
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 well-organized into logical sections: overview, host modes, path patterns, identifier rules, and overrides. The first sentence is a clear summary, and every subsequent line adds necessary detail without redundancy. Length is appropriate for the tool's complexity.
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?
Despite having no output schema, the description fully explains the output format by listing path patterns for every entity type and how hosts are constructed. It covers all nine parameters and provides enough context for an agent to invoke the tool correctly without ambiguity. Complete for a URL-generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial cross-parameter meaning beyond the schema. It explains which identifiers are valid for each entity type, that lightboxes use a composite '{id}-{name}' slug, and that tags can optionally include a name for prettier URLs. This guidance is not present in the schema 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 opens with a specific verb ('Generate') and resource ('direct deep-link URL to a Mediagraph entity'), enumerating all supported entity types. This clearly distinguishes it from any sibling tool, none of which generate URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases and contextual guidance: it explains identifier rules per entity type, when to use each parameter, and how to override hosts for staging. It also implicitly states when the tool is appropriate—whenever a deep-link URL is needed—and gives concrete examples.
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:

[![mediagraph-mcp MCP server](https://glama.ai/mcp/servers/mediagraph-io/mediagraph-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mediagraph-io/mediagraph-mcp)

Score Badge

Copy to your README.md:

[![mediagraph-mcp MCP server](https://glama.ai/mcp/servers/mediagraph-io/mediagraph-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mediagraph-io/mediagraph-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/mediagraph-io/mediagraph-mcp'

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