Miro MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific item types (e.g., create-card-item vs. create-sticky-note-item) or operations (e.g., get-specific-board vs. list-boards). However, some tools like delete-item and delete-specific-item-type tools (e.g., delete-card-item) could cause confusion, as delete-item might be overly general, leading to potential misselection when more specific deletion is needed.
Naming Consistency5/5
Tool names follow a highly consistent verb-noun pattern throughout, such as create-board, get-board-export-job-status, update-app-card-item, and delete-tag. All tools use snake_case uniformly, with clear action prefixes (create, get, update, delete, list, etc.), making them predictable and easy to parse.
Tool Count2/5
With 97 tools, the count is excessive for a single server, making it overwhelming and difficult for agents to navigate efficiently. While Miro's domain is broad, the toolset could be streamlined by grouping similar operations (e.g., generic item CRUD) rather than having separate tools for each item type, which inflates the number unnecessarily.
Completeness5/5
The toolset provides comprehensive coverage of Miro's domain, including full CRUD operations for boards, items (e.g., cards, shapes, text), tags, groups, and connectors, plus enterprise features like audit logs and eDiscovery. There are no obvious gaps; it supports creation, retrieval, updating, deletion, and management across all major resources.
Average 3/5 across 97 of 97 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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

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 'Adds a member', implying a write/mutation operation, but doesn't disclose any behavioral traits such as required permissions, whether the operation is idempotent, what happens on duplicate additions, error conditions, or rate limits. The 'Enterprise only' note is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with zero wasted words. It's front-loaded with the core action ('Adds a member to a project') and efficiently adds a constraint ('Enterprise only'). Every word earns its place, making it easy to parse quickly.
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 (a mutation with 5 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral nuances. While the schema covers parameters well, the description fails to provide necessary context for safe and effective use, especially for a write operation in a multi-tool environment.
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, thoroughly documenting all 5 parameters with clear descriptions and an enum for 'role'. The description adds no parameter-specific information beyond what's in the schema, not even hinting at parameter relationships (e.g., orgId/teamId/projectId hierarchy). With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.
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 ('Adds a member') and resource ('to a project'), making the purpose immediately understandable. It also includes a useful constraint ('Enterprise only') that clarifies the scope. However, it doesn't differentiate from the sibling tool 'remove-project-member' beyond the obvious verb difference, nor does it mention other related tools like 'get-project-member' or 'update-board-member' for 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 minimal guidance, only indicating it's 'Enterprise only' without explaining when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing proper permissions), when not to use it, or how it relates to sibling tools like 'remove-project-member' or 'get-project-member'. 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 provided, the description carries full burden for behavioral disclosure. It states the tool creates a copy but doesn't reveal whether this is a read-only or destructive operation, what permissions are required, whether it preserves all board content, or what happens to the original board. The mention of 'optional new settings' hints at customization but lacks specifics about default behaviors or limitations. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its operational characteristics.
Agents need to know what a tool does to the world before 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 immediately conveys the core functionality. Every word earns its place: 'Create a copy' establishes the action, 'existing Miro board' specifies the resource, and 'optional new settings' hints at customization without unnecessary elaboration. There's no redundant information or verbose explanations, making it optimally concise while still being 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?
For a tool that creates a new board copy (a mutation operation) with 5 parameters and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., the new board ID, success status, or error conditions), doesn't address permission requirements, and provides minimal behavioral context. While the schema covers parameters well, the description fails to compensate for the lack of annotations and output schema, leaving the agent with incomplete understanding of how to properly use this 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%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'optional new settings' which loosely corresponds to parameters like name, description, sharingPolicy, and teamId. However, it doesn't provide additional context about parameter relationships, default values, or practical usage examples that would enhance understanding beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a copy') and resource ('existing Miro board'), making the purpose immediately understandable. It distinguishes itself from 'create-board' by specifying it copies an existing board rather than creating a new one from scratch. However, it doesn't explicitly differentiate from other board-related tools like 'update-board' or 'get-specific-board' in terms of when to choose copying over other 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?
The description provides no guidance on when to use this tool versus alternatives like 'create-board' for starting fresh or 'update-board' for modifying existing boards. It mentions 'optional new settings' but doesn't clarify what scenarios warrant copying versus direct creation or modification. There's no mention of prerequisites, permissions needed, or typical use cases for board duplication.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. While 'Create' implies a write/mutation operation, the description doesn't address critical behavioral aspects: required permissions (e.g., edit access to the board), side effects (e.g., whether this affects other board elements), error conditions (e.g., invalid boardId), or response format. This leaves significant gaps 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place, and there's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It lacks information about behavioral traits (permissions, side effects), response expectations, error handling, and differentiation from sibling tools. While the schema covers parameters well, the description fails to address the broader context needed for safe and effective tool 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 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'data' and 'geometry', or provide examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new app card item') and the target resource ('on a Miro board'), which is specific and unambiguous. However, it doesn't differentiate this tool from similar sibling tools like 'create-card-item' or 'create-sticky-note-item', which also create items on Miro boards but for different item types.
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 (e.g., needing board access), exclusions (e.g., when not to create app cards), or comparisons to sibling tools like 'create-card-item' or 'update-app-card-item'. The agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a board but lacks details on permissions required, whether it's idempotent, rate limits, or what happens on failure (e.g., if the name is duplicate). This leaves significant gaps 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and includes key parameters, making it easy to parse quickly.
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 complexity of a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., board ID or success status), error conditions, or behavioral nuances, leaving the agent with incomplete operational 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 the schema fully documents all parameters. The description mentions 'name and sharing policies', which aligns with the schema but adds no extra meaning beyond it, such as default values or constraints not in the schema. This meets the baseline 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 clearly states the action ('Create a new Miro board') and specifies key resources ('with specified name and sharing policies'), making the purpose evident. However, it doesn't explicitly distinguish this tool from similar siblings like 'copy-board' or 'update-board', which would require mentioning unique aspects like initial creation versus modification or duplication.
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 (e.g., needing a team ID for certain contexts), exclusions, or comparisons to sibling tools like 'copy-board' or 'update-board', leaving the agent 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?
With no annotations provided, the description carries full burden but only states it 'Creates an export job' without detailing behavioral traits. It lacks information on permissions required, whether this is asynchronous (implied by 'job'), rate limits, what 'Enterprise only' entails, or what the job creation actually does (e.g., triggers background processing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. 'Enterprise only' adds necessary context without verbosity. However, it could be slightly more structured by explicitly separating functional and restriction aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what an 'export job' entails, what formats are supported (only implied by schema), how to retrieve results (though siblings exist), or error conditions. The 'Enterprise only' hint is helpful but doesn't compensate for missing behavioral 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 parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying 'boardIds' can handle multiple boards ('one or more'). This meets the baseline for high schema coverage without compensating 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 clearly states the action ('Creates an export job') and resource ('for one or more boards'), with the 'Enterprise only' qualifier adding specificity. However, it doesn't distinguish this from potential sibling tools like 'get-board-export-job-results' or 'get-board-export-job-status' beyond the creation aspect.
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 minimal guidance with 'Enterprise only' indicating a usage restriction, but offers no explicit when-to-use advice, alternatives (e.g., vs. other export methods), or prerequisites. It doesn't help an agent decide between this and sibling tools like 'copy-board' or bulk 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 carries full burden. It states this is a creation operation but doesn't disclose any behavioral traits: no information about required permissions, whether this is a write operation, what happens on failure, rate limits, or what the response looks like. For a creation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero waste. It's appropriately sized and front-loaded, making it immediately clear to an agent what this tool accomplishes.
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 creation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'card item' is (versus other item types), doesn't mention any behavioral aspects like permissions or side effects, and provides no context about the Miro board ecosystem. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify any semantic nuances. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new card item on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create-app-card-item' or 'create-sticky-note-item', which would require specifying what makes a 'card item' distinct from other item types.
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. With many sibling tools for creating different item types (e.g., create-app-card-item, create-sticky-note-item), the description lacks any context about what a 'card item' is or when it's appropriate compared to other item creation 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 full burden for behavioral disclosure. It states this is a creation operation (implying mutation/write), but doesn't mention permission requirements, whether the connector appears immediately on the board, if there are rate limits, or what happens if the start/end items don't exist. The description lacks crucial behavioral context 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, clear sentence with zero wasted words. It's appropriately sized for a creation tool and front-loads the essential information. Every word earns its place in conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a successful creation returns (e.g., connector ID), error responses, or the visual/functional impact on the Miro board. Given the complexity of creating graphical connectors between items, more context about the operation's effects is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., that startItem and endItem must be valid existing items) or provide examples of style configurations. Baseline 3 is appropriate when 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 ('Create a new connector') and the resource ('between items on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update-connector' or explain what a 'connector' represents in the Miro context (e.g., a line/arrow between objects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update-connector' or 'create-items-in-bulk' (which might include connectors). There's no mention of prerequisites (e.g., existing items on the board), error conditions, or typical use cases for creating connectors in Miro workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Create a new document item' which implies a write operation, but doesn't mention permissions required, rate limits, whether the operation is idempotent, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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, clear sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 this is a mutation tool (creating items) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral constraints. The 100% schema coverage helps with inputs, but overall context for safe and effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain URL format requirements or position coordinate systems). Baseline 3 is appropriate when 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 ('Create') and resource ('document item on a Miro board'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'create-text-item' or 'create-embed-item' that also create items on Miro boards, so it lacks sibling distinction for 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. With many sibling tools for creating different item types (e.g., 'create-text-item', 'create-image-item-using-url'), there's no indication that this is specifically for document items based on URLs, leaving the agent to guess based on 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 provided, the description carries the full burden of behavioral disclosure. It states it's a creation tool, implying mutation, but lacks details on permissions, side effects (e.g., if it affects board limits), error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens upon creation (e.g., returns an embed ID), error conditions, or behavioral nuances. Given the complexity of nested parameters and lack of structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no parameter-specific information beyond implying 'boardId' and 'data' are involved. It meets the baseline of 3 since the schema does the heavy lifting, but doesn't enhance understanding of parameter roles or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and resource ('new embed item on a Miro board'), making the purpose immediately understandable. It distinguishes from siblings like 'create-image-item-using-url' or 'create-text-item' by specifying the embed type, though it doesn't explicitly contrast with alternatives like 'update-embed-item'.
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 (e.g., needing board access), when not to use it (e.g., for updating existing embeds), or refer to sibling tools like 'update-embed-item' or 'delete-embed-item' for 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 carries the full burden of behavioral disclosure. It states 'create' but doesn't mention permissions required, whether this is a write operation, potential side effects (e.g., affecting board layout), or response format. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without 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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or what the tool returns. For a 5-parameter tool that creates resources, more context is needed to guide safe and effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what's in the schema (e.g., it doesn't explain relationships between parameters like data and style). Baseline 3 is appropriate when 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 ('create') and resource ('new frame on a Miro board'), making the purpose evident. However, it doesn't distinguish this from other creation tools like create-shape-item or create-text-item, which would require mentioning what makes a frame unique (e.g., a container for grouping items).
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. For example, it doesn't explain when to create a frame versus a group or other container-like items, nor does it mention prerequisites like needing board access. The description only states what it does, not 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.
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. While 'create' implies a write operation, it doesn't specify permissions required, whether the group is editable after creation, or what happens if item IDs are invalid. This leaves significant behavioral gaps 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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient 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 mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on permissions, error handling, return values, or how the group integrates with other board elements, leaving the agent with incomplete context for safe and effective 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?
Schema description coverage is 100%, so the schema fully documents both parameters (boardId and data with items). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints, meeting the baseline 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 clearly states the action ('create') and resource ('new group on a Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create-frame' or 'create-shape-item' that also create board elements, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create-items-in-bulk' or 'ungroup-items', nor does it mention prerequisites such as board access or permissions. The description only states what it does, not when or why 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 provided, the description carries full burden but reveals minimal behavioral information. It states this is a creation operation but doesn't disclose permissions required, rate limits, whether the image is uploaded immediately, what happens on failure, or the format of any response. The description mentions 'from device or from chat' but doesn't clarify how this choice is made or if there are different requirements for each source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for a creation tool, though it could potentially be more structured by separating the 'what' from the 'how' aspects. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (does it return an item ID?), what errors might occur, authentication requirements, or how the tool behaves with different file types/sizes. Given the complexity of image upload and board positioning, more contextual information 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter information beyond what's in the schema - it doesn't explain the relationship between parameters, provide examples, or clarify edge cases. The baseline of 3 is appropriate when 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 ('Create a new image item') and resource ('on a Miro board'), specifying the method ('using file from device or from chat'). It distinguishes from sibling 'create-image-item-using-url' by mentioning file-based creation, but doesn't explicitly contrast with other image-related tools like 'update-image-item-using-file'.
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 when to choose file-based creation over URL-based creation (create-image-item-using-url), or when to use this versus bulk creation tools (create-items-in-bulk-using-file). No prerequisites, constraints, or typical use cases are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't address critical aspects like required permissions, whether the operation is idempotent, error handling for invalid URLs, or rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal 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 and no output schema, the description is insufficiently complete. It lacks details on behavioral traits (e.g., permissions, side effects), usage context relative to siblings, and expected return values. While the schema covers parameters well, the overall context for safe and effective tool invocation 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?
Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, such as explaining URL format requirements or position coordinate systems. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 new image item') and resource ('on a Miro board using a URL'), which is specific and unambiguous. However, it doesn't explicitly differentiate from its sibling 'create-image-item-using-file', which handles image creation via file upload rather than URL. This omission prevents 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. It doesn't mention the sibling 'create-image-item-using-file' for file-based image creation, nor does it specify prerequisites like board access or URL validity. Without such context, an agent might struggle to choose between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states this is a creation operation (implying mutation/write) but doesn't disclose permissions needed, rate limits, whether items are created atomically, error handling for partial failures, or what the response contains. For a bulk mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before 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 core purpose without unnecessary words. Every element ('Create multiple items', 'on a Miro board', 'in a single operation') contributes directly to understanding the tool's function.
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 creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what types of items can be created (though schema shows sticky_note, card, text), behavioral constraints, error scenarios, or return values. Given the complexity implied by the nested items array and mutation nature, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (boardId, items) and their nested structures. The description adds no parameter-specific information beyond implying 'multiple items' relates to the items array. Baseline 3 is appropriate when schema does all 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 ('Create multiple items') and resource ('on a Miro board') with the operational context ('in a single operation'). It distinguishes from single-item creation tools like create-sticky-note-item or create-card-item by emphasizing bulk creation, though it doesn't explicitly name those 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?
The description provides no guidance on when to use this tool versus alternatives like create-items-in-bulk-using-file or individual item creation tools. It mentions 'in a single operation' which hints at efficiency, but lacks explicit when/when-not instructions or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It states it's a creation operation but doesn't disclose permissions required, rate limits, error handling, or what happens if the file data is malformed. For a bulk mutation tool, this is a significant gap in 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, efficient sentence that front-loads key information: action, resource, and method. There's no wasted wording, making it appropriately concise and well-structured for quick understanding.
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 creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the JSON file structure, success/failure responses, or how errors are handled. Given the complexity of batch operations, more context is needed to guide effective 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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value by implying the JSON file contains 'items to create' but doesn't provide format examples or constraints beyond what the schema states. Baseline 3 is appropriate when 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 ('create multiple items'), resource ('on a Miro board'), and method ('using a JSON file from device'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling 'create-items-in-bulk' (which likely uses different input methods), missing full sibling distinction for 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 like 'create-items-in-bulk' or individual item creation tools. It mentions the method ('using a JSON file') but doesn't specify scenarios, prerequisites, or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Create a new shape item,' implying a write operation, but doesn't mention permissions, side effects, rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, which is ideal 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?
Given the tool's complexity (5 parameters, nested objects, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error handling, or return values, leaving gaps that could hinder an AI agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 new shape item') and resource ('on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other shape-related tools like 'update-shape-item' or 'delete-shape-item' among the siblings, which would require more specificity for 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. With siblings like 'create-items-in-bulk' for batch creation or 'update-shape-item' for modifications, there's no indication of appropriate contexts, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. It states this is a creation operation but doesn't mention whether it requires specific permissions, what happens on failure, if there are rate limits, or what the return value looks like (especially problematic since there's no output schema). This leaves significant gaps 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, efficient sentence that states the core purpose without unnecessary words. It's perfectly front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns an item ID, error handling), nor does it provide context about permissions, side effects, or limitations. The 100% schema coverage helps with inputs but doesn't compensate for missing behavioral and output 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, which is acceptable but not additive. The baseline score of 3 reflects adequate but minimal value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and resource ('new sticky note item on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other creation tools like 'create-text-item' or 'create-shape-item' beyond specifying the sticky note type, which is a minor 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. With many sibling tools for creating different board items (e.g., create-text-item, create-shape-item), there's no indication of when a sticky note is appropriate versus other item types, nor any mention of prerequisites like board access or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a tag but omits critical details: whether this requires specific permissions, if it's idempotent, what happens on duplicate titles, or the response format. For a mutation tool, this leaves significant gaps in understanding its 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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse. Every word earns its place by conveying essential information without 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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like permissions, idempotency, or error handling, nor does it hint at the return value. Given the complexity of creating a resource, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (boardId, data, fillColor). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the relationship between data.title and fillColor. This meets the baseline score of 3 when schema coverage is high.
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 new tag') and resource ('on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'attach-tag' or 'update-tag', which would require explicit comparison to achieve a score of 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 like 'attach-tag' (for existing tags) or 'update-tag' (for modifications). It lacks context about prerequisites, such as board access permissions, or when not to use it, leaving the agent without 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 full burden for behavioral disclosure. It states this is a creation operation but doesn't mention any behavioral aspects like required permissions, whether it's idempotent, what happens on duplicate creation, error conditions, or what the return value contains. For a mutation tool with zero annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently communicates the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters (including nested objects), no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, what the tool returns, error handling, or contextual constraints. The description should provide more complete guidance for proper tool 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 description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 clearly states the action ('Create a new text item') and the resource ('on a Miro board'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from other creation tools like create-sticky-note-item or create-card-item, which would require mentioning the specific type of item being created.
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 for creating different item types (e.g., create-sticky-note-item, create-card-item), there's no indication that this is specifically for plain text items or when text items are preferred over other formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 tool deletes an item, implying destructive action, but doesn't disclose critical behavioral traits like permissions required, irreversibility, error handling, or rate limits. This leaves significant gaps 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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
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 is incomplete. It lacks details on behavioral implications, success/error responses, and differentiation from siblings, failing to provide sufficient context for safe and effective use in a complex toolset.
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 clear parameter documentation in the schema. The description adds no additional meaning beyond implying specificity ('specific app card item'), but doesn't compensate for schema gaps since there are none. Baseline 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a specific app card item from a Miro board'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'delete-card-item' or 'delete-item', which could handle similar deletions, leaving some ambiguity about specialization.
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. With siblings like 'delete-card-item', 'delete-item', and 'delete-app-card-item' available, the description lacks context on prerequisites, distinctions, or exclusions, offering minimal 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 carries full burden. It states the tool deletes, implying a destructive mutation, but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has side effects, or returns confirmation. This leaves significant gaps for safe agent 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, efficient sentence with zero waste—it directly states the tool's action and target. It's appropriately sized and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is incomplete. It lacks crucial behavioral context (e.g., permanence, permissions, response format) and doesn't differentiate from similar sibling tools, leaving the agent under-informed for safe and correct usage.
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 clear parameter descriptions in the schema. The description adds no additional meaning beyond implying 'boardId' and 'itemId' are used to locate the card, which is already covered by the schema. 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 clearly states the action ('Delete') and resource ('a specific card item from a Miro board'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete-item' or 'delete-app-card-item', which appear to handle similar deletion operations for different item types.
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 'delete-item' or other deletion tools in the sibling list. There's no mention of prerequisites, constraints, or comparative 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?
No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive operation, the description doesn't disclose critical behavioral aspects: whether this requires specific permissions, if the deletion is permanent or reversible, what happens to associated data, or any rate limits/constraints. For a destructive operation with zero annotation coverage, 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, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't address permissions, consequences, error conditions, or what happens post-deletion. Given the complexity of a delete operation and the lack of structured data, the description should provide more behavioral 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 both parameters clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 clearly states the action ('Delete') and the target ('a specific embed item from a Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from other delete operations like 'delete-item' or 'delete-embed-item' vs 'delete-app-card-item', which are present in the sibling tools 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple delete tools available (e.g., 'delete-item', 'delete-embed-item', 'delete-app-card-item'), there's no indication of when this specific embed deletion is appropriate versus a more general deletion method.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 the action is a deletion, implying a destructive operation, but doesn't mention critical details like whether deletion is permanent, requires specific permissions, or has side effects (e.g., affecting other board elements). This leaves significant gaps for safe agent usage.
Agents need to know what a tool does to the world before 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 zero wasted words, front-loading the key action and resource. It's appropriately sized for a simple tool, making it easy to parse quickly.
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 destructive nature and lack of annotations or output schema, the description is incomplete. It fails to address behavioral aspects like permanence, error conditions, or return values, which are crucial for an agent to invoke it correctly and safely 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?
Schema description coverage is 100%, with clear descriptions for both parameters (boardId and itemId). The description doesn't add any additional meaning beyond what the schema provides, such as format examples or constraints, but the schema adequately covers the basics, meeting the baseline for high 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 ('Delete') and resource ('a frame from a Miro board'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete-item' or 'delete-frame-item' (which appears to be itself), leaving room for 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 such as 'delete-item' or other deletion tools in the sibling list. The description lacks context about prerequisites, permissions, or scenarios where this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive mutation, it doesn't disclose critical behavioral traits: whether deletion is permanent or reversible, what permissions are required, how it affects board structure, or error conditions. The description mentions the tool deletes a group but lacks context on consequences beyond what's implied by the verb.
Agents need to know what a tool does to the world before 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 zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient. Every word earns its place by conveying essential information without 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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral risks, permissions, or what happens to items in the group (though deleteItems parameter hints at this). Given the complexity of deletion operations and lack of structured safety hints, more context about consequences and usage would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain format of IDs or default behavior for deleteItems). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a specific group from a Miro board'), making the purpose immediately understandable. It distinguishes itself from siblings like 'delete-board' or 'delete-item' by specifying the target is a group. However, it doesn't explicitly differentiate from 'ungroup-items', which might have overlapping functionality.
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 siblings like 'delete-item', 'delete-board', and 'ungroup-items' available, there's no indication of when group deletion is appropriate versus other deletion operations or whether prerequisites like permissions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 action is 'Delete,' implying a destructive mutation, but doesn't mention critical aspects like whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting linked items), or provides confirmation. For a destructive tool, this is a significant gap in 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, clear sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key information ('Delete a specific image item'), making it easy to parse. Every word earns its place, resulting in optimal 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's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral risks (e.g., irreversibility), permissions, or what happens upon deletion (e.g., success confirmation or error handling). For a mutation tool with zero structured coverage beyond inputs, more context is needed to guide safe usage.
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, with clear documentation for both parameters (boardId and itemId). The description doesn't add any semantic details beyond what the schema provides (e.g., it doesn't explain format or sourcing of IDs). Given the high schema coverage, the baseline score of 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 clearly states the action ('Delete') and the target ('a specific image item from a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other delete operations like 'delete-item' or 'delete-app-card-item' among the siblings, which would require specifying it's specifically for image items.
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 siblings like 'delete-item' (generic deletion) and 'delete-image-item' (specific to images), there's no indication of which to choose or any prerequisites (e.g., needing board access). This leaves the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool deletes an item but doesn't disclose critical behavioral traits: whether deletion is permanent or reversible, what permissions are required, if there are rate limits, or what happens to associated data. For a destructive operation with zero annotation coverage, this leaves significant gaps in understanding 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, clear sentence that directly states the tool's function without unnecessary words. It's front-loaded with the essential information ('Delete a specific item from a Miro board'), making it efficient and easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't address the mutation's impact (permanence, side effects), permission requirements, error conditions, or what happens upon success. For a tool that permanently removes data, more context about behavior and consequences is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema (boardId and itemId). The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter relationships, format examples, or constraints. With high schema coverage, the baseline score of 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 clearly states the action ('Delete') and resource ('a specific item from a Miro board'), making the purpose immediately understandable. It distinguishes itself from other deletion tools like delete-board or delete-card-item by specifying 'item' generically, though it doesn't explicitly differentiate from sibling tools like delete-app-card-item or delete-text-item that target specific item types.
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 deletion tools (e.g., delete-app-card-item, delete-card-item, delete-text-item), there's no indication whether this is a generic deletion tool for any item type or if it has specific constraints. No prerequisites, exclusions, or comparison to other tools 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 behavioral disclosure. It states the tool deletes a mind map node, implying a destructive operation, but doesn't mention if deletion is permanent, reversible, requires specific permissions, or what happens to associated data. This leaves significant gaps 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, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.
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 destructive operation with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, reversibility, or error conditions, which are critical for safe usage in this 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 description coverage is 100%, with clear descriptions for both parameters (boardId and itemId). The description doesn't add any extra meaning beyond what the schema provides, such as format examples or usage tips, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a mind map node from a Miro board'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete-item' or 'delete-mindmap-node' (if that were a sibling), though 'delete-mindmap-node' is specific enough in 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 like 'delete-item' or other deletion tools in the sibling list. It lacks context about prerequisites, such as needing the node to exist or being authorized to delete 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 carries the full burden. It states the tool deletes a shape item, implying a destructive mutation, but doesn't disclose behavioral traits like permissions required, whether deletion is permanent/reversible, error handling, or side effects. For a destructive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (destructive mutation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or response format. For a deletion tool, this leaves critical gaps for an AI agent to use 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%, with both parameters ('boardId' and 'itemId') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when 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 ('Delete') and resource ('a specific shape item from a Miro board'), making the purpose unambiguous. It distinguishes from siblings like 'delete-item' (generic) and 'delete-shape-item' (specific), though it doesn't explicitly contrast them. The verb+resource combination is specific but lacks explicit 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?
No guidance is provided on when to use this tool versus alternatives. Siblings include 'delete-item' (generic deletion) and 'delete-shape-item' (specific), but the description doesn't mention when to choose one over the other or any prerequisites. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool deletes a sticky note, implying a destructive mutation, but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, or has side effects (e.g., affecting other board elements). This leaves significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It's front-loaded and efficiently conveys the core 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.
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 is insufficient. It doesn't cover critical context like what happens after deletion (e.g., confirmation, error handling), permissions required, or how it differs from similar tools. Given the complexity and lack of structured data, more detail is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters (boardId and itemId). The description doesn't add any meaning beyond the schema, such as explaining how to obtain these IDs or their format. Given the high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 target resource ('a specific sticky note item from a Miro board'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete-item' or 'delete-sticky-note-item' (which appears to be the same tool name), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete-item' or other deletion tools in the sibling list. It lacks context about prerequisites, such as needing the board and item IDs, or when deletion is appropriate versus other 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this operation is reversible, what permissions are required, whether it affects associated items, or what happens on success/failure. This leaves significant gaps in understanding 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, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately sized for a simple deletion operation and gets straight 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?
For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address critical context like what 'delete' means operationally (permanent removal?), what happens to tagged items, whether there are confirmation requirements, or what the response contains. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters clearly documented. The description adds no additional parameter information beyond what's already in the schema descriptions, so it meets the baseline expectation but doesn't provide extra value regarding parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a specific tag from a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'detach-tag' or 'delete-item', which could cause confusion about when to use this specific deletion tool versus others.
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 sibling tools like 'detach-tag' (which removes tag associations) and 'delete-item' (which might delete tags among other items), the agent has no indication whether this tool is for permanent deletion versus disassociation, or whether it's the preferred method for tag removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. It states the tool performs a deletion but omits critical details: whether the action is reversible, what permissions are required, if it triggers side effects (e.g., removing associated tags), or what happens on success/failure. This leaves the agent guessing about risks and outcomes.
Agents need to know what a tool does to the world before 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 zero wasted words. It front-loads the core action and resource efficiently, making it easy to parse without unnecessary elaboration.
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 is insufficient. It fails to address behavioral aspects like irreversibility, error conditions, or response format, leaving significant gaps in understanding how to invoke and interpret results safely.
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 clear parameter documentation in the schema (boardId and itemId). The description adds no additional semantic context beyond implying these IDs target a specific item, so it meets the baseline for adequate but not enhanced parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a specific text item from a Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete-item' or 'delete-sticky-note-item', which handle other item types, leaving some ambiguity about specialization.
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 'delete-item' (general deletion) or other type-specific deletion tools. It lacks context about prerequisites, such as needing board access or item existence, which are critical for effective 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 full burden for behavioral disclosure. It states the action ('detach') which implies a mutation, but doesn't clarify permissions needed, whether the operation is reversible, what happens if the tag isn't attached, or any rate limits. This leaves significant gaps 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, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately sized for a straightforward operation and gets directly 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after detachment, whether the tag persists independently, what error conditions might occur, or what the tool returns. The 100% schema coverage helps with parameters, but behavioral context is critically lacking.
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 all three parameters clearly documented in the schema itself. The description doesn't add any additional parameter context beyond what's already in the schema descriptions, so it meets the baseline expectation but doesn't provide extra 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 clearly states the action ('detach') and target resources ('tag from an item on a Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'attach-tag' or other tag-related tools like 'delete-tag', which would be needed for 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 like 'delete-tag' (which removes a tag entirely) or 'update-tag' (which might modify tag properties). There's no mention of prerequisites, error conditions, 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.
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 mentions 'Enterprise only', hinting at access restrictions, but fails to disclose key behavioral traits like whether this is a read-only operation, potential rate limits, pagination behavior (implied by 'cursor' parameter but not explained), or error conditions. The description is too sparse for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Retrieves the list of all legal holds') and includes essential context ('within a case (Enterprise only)'). There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., pagination, permissions), output format, or error handling. While concise, it doesn't provide enough context for an agent to use the tool effectively beyond basic purpose, especially with no structured annotations to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (limit, orgId, caseId, cursor). The description adds no additional parameter semantics beyond implying retrieval is scoped to a case and organization, which is already covered in schema descriptions. Baseline score of 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 clearly states the action ('Retrieves') and resource ('list of all legal holds within a case'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get-legal-hold' (singular) or 'get-legal-hold-content-items', which might retrieve specific holds or their contents, leaving some ambiguity about sibling relationships.
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 minimal guidance by specifying 'within a case (Enterprise only)', indicating a context and restriction, but it lacks explicit when-to-use instructions, alternatives (e.g., vs. 'get-legal-hold'), or prerequisites. No clear usage scenarios or exclusions are mentioned, making it insufficient for optimal 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 states a read operation ('Retrieve'), implying it's non-destructive, but lacks details on permissions, rate limits, error handling, or response format. This is insufficient for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly.
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 annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., tag list format), behavioral aspects like pagination with limit/offset, or error conditions, leaving significant 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 has 100% description coverage, with clear documentation for 'boardId', 'limit', and 'offset'. The description adds no additional parameter semantics beyond what the schema provides, so it meets 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 clearly states the verb ('Retrieve') and resource ('all tags on a Miro board'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-tag' (singular) or 'get-item-tags', which might retrieve tags for specific items rather than the entire board.
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 sibling tools like 'get-tag' (for a single tag) or 'get-item-tags' (for tags on specific items), nor does it specify prerequisites or contexts for 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 provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves logs, implying a read-only operation, but doesn't clarify aspects like permissions required, rate limits, pagination behavior (beyond the cursor parameter in schema), or what the logs contain. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before 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 with a single sentence that directly states the tool's function and restriction. It's front-loaded with the core purpose and wastes no words, making it easy for an agent to parse quickly without unnecessary elaboration.
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 8 parameters, no annotations, and no output schema, the description is inadequate. It lacks details on behavioral traits (e.g., pagination, enterprise context), usage context compared to siblings, and expected return values. The high parameter count and absence of structured support fields mean the description should do more to guide the agent effectively.
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 each parameter well-documented in the input schema. The description adds no additional parameter details beyond what the schema provides, such as explaining relationships between parameters (e.g., how 'boardIds' and 'emails' interact). Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate with extra semantic 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 clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('content change logs of board items'), and it specifies an enterprise-only restriction. However, it doesn't differentiate from sibling tools like 'get-audit-logs' or 'get-specific-board' that might also retrieve logs or board information, which prevents 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 minimal guidance by mentioning 'Enterprise only', but it doesn't explain when to use this tool versus alternatives like 'get-audit-logs' or 'get-specific-board' for related data. There's no mention of prerequisites, exclusions, or specific scenarios for usage, leaving the agent with little contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Retrieves', implying a read operation, but lacks details on permissions, rate limits, response format, or error handling. The 'Enterprise only' note adds some context about access restrictions, but overall behavioral traits are minimally covered, leaving significant gaps 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, efficient sentence with no wasted words. It front-loads the core action and resource, and the 'Enterprise only' note is succinctly appended. Every part earns its place, making it highly concise and well-structured for quick understanding.
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 tool that retrieves job results. It lacks details on what the results contain, how they're formatted, error cases, or dependencies on other tools like 'create-board-export-job'. The 'Enterprise only' note is helpful but insufficient to compensate for the missing behavioral and output 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 has 100% description coverage, with clear documentation for 'orgId' and 'jobId'. The description adds no additional parameter details beyond what the schema provides, such as format examples or relationships between parameters. This meets the baseline of 3 since the schema does the heavy lifting, but no extra value is contributed.
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 ('Retrieves') and the resource ('results of a board export job'), making the purpose specific and understandable. It distinguishes from siblings like 'get-board-export-job-status' by focusing on results rather than status, though it doesn't explicitly compare them. The 'Enterprise only' note adds context but doesn't fully differentiate from all 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?
The description provides no guidance on when to use this tool versus alternatives like 'get-board-export-job-status' or other job-related tools. It mentions 'Enterprise only', which hints at a prerequisite, but offers no explicit when/when-not instructions or comparisons to sibling tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 tool retrieves information, implying a read-only operation, but doesn't clarify permissions required, rate limits, error handling, or what information is returned (e.g., metadata, content). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Retrieve information'), making it easy to parse quickly, and every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a retrieval tool. It doesn't explain what information is returned (e.g., document content, metadata, or status), potential errors, or behavioral traits like authentication needs. This makes it inadequate for an agent to fully understand how to use the tool effectively.
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 information beyond what's in the input schema, which has 100% coverage with clear descriptions for both required parameters (boardId and itemId). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate with additional context like format examples or usage tips.
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 purpose with a specific verb ('Retrieve') and resource ('information about a specific document item on a Miro board'), making it easy to understand what it does. However, it doesn't differentiate from sibling tools like 'get-specific-item' or 'get-app-card-item', which appear to retrieve other item types, so it doesn't fully distinguish itself from 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over similar sibling tools (e.g., 'get-specific-item' for generic items or 'get-app-card-item' for app cards), nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Retrieve information' which implies a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what specific information is returned. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 insufficiently complete. It doesn't explain what information is retrieved (e.g., embed details, metadata), potential side effects, or error handling, leaving significant gaps for a tool that interacts with board items.
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 ('boardId' and 'itemId') clearly documented in the schema. The description adds no additional meaning beyond the schema, such as format examples or contextual usage, so it meets the baseline 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 clearly states the action ('Retrieve information') and resource ('specific embed item on a Miro board'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get-specific-item' or 'get-items-on-board' that might retrieve similar items, so it doesn't achieve full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-specific-item' or 'get-items-on-board' from the sibling list. It lacks any context about prerequisites, exclusions, or comparative use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves information, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what specific information is returned (e.g., metadata, content). This leaves gaps for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, with zero waste or 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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what information is retrieved (e.g., image details, metadata), potential errors, or behavioral context, making it inadequate for a tool that likely returns complex data about an image item.
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 ('boardId' and 'itemId') clearly documented in the schema. The description adds no additional meaning beyond implying these IDs are required to locate the image, matching the baseline 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 clearly states the action ('retrieve information') and resource ('specific image item on a Miro board'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-item' or 'get-items-on-board', which might retrieve similar or broader information.
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-specific-item' (which might retrieve any item type) or 'get-items-on-board' (which lists multiple items). The description lacks context on prerequisites or exclusions, leaving usage unclear relative to 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?
No annotations are provided, so the description carries full burden. It states 'Retrieve all items' but doesn't disclose behavioral traits like pagination behavior (implied by limit/offset parameters), rate limits, authentication needs, or what 'items' encompasses (e.g., types, formats). This leaves significant gaps for a read operation with pagination.
Agents need to know what a tool does to the world before 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 core purpose ('Retrieve all items on a specific Miro board'). There is zero wasted text, making it highly concise and well-structured for quick comprehension.
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 parameters, no annotations, and no output schema, the description is inadequate. It lacks details on return values (what 'items' include), pagination behavior, error conditions, or usage context. The agent must rely heavily on schema and inference, leaving gaps in operational understanding.
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 clear parameter documentation in the schema (boardId, limit, offset). The description adds no additional parameter semantics beyond implying 'all items' relates to boardId. 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 clearly states the verb ('Retrieve') and resource ('all items on a specific Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-item' or 'get-group-items', which also retrieve items but with different scopes or filters.
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 siblings like 'get-specific-item' (for single items) and 'get-group-items' (for items in groups), the agent must infer usage from the name alone, lacking explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves tags but does not disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or handles errors. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, with zero 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?
Given no annotations and no output schema, the description is incomplete. It lacks details on return values, error handling, or behavioral context, which are crucial for a tool with two required parameters and no structured output information.
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 clear descriptions for 'boardId' and 'itemId'. The description adds no additional meaning beyond the schema, such as format examples or constraints. 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 clearly states the action ('Retrieve all tags') and target ('attached to a specific item on a Miro board'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'get-all-tags' or 'get-tag', which might retrieve tags in different contexts, so it misses full 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'get-all-tags' for all tags on a board or 'get-tag' for a specific tag. It lacks explicit context, exclusions, or prerequisites, leaving usage unclear relative to 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. It states this is a retrieval operation (read-only), which is adequate but minimal. It doesn't describe authentication needs, rate limits, error conditions, or what 'information' includes (e.g., metadata, status). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that gets straight to the point. It's appropriately sized for a simple retrieval tool, with no wasted words. The 'Enterprise only' note is relevant and concise. However, it could be slightly more structured by separating scope from action.
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 retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'information' is returned (e.g., fields, format) or any behavioral nuances. While the schema covers inputs well, the lack of output details and minimal behavioral context makes this inadequate for full understanding.
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 all three parameters clearly documented in the schema. The description adds no parameter-specific information beyond what's in the schema (e.g., no examples, format details, or relationships between orgId/caseId/legalHoldId). Baseline 3 is appropriate when 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 verb ('Retrieves') and resource ('information about a specific legal hold'), making the purpose unambiguous. It distinguishes from sibling 'get-all-legal-holds' by specifying 'specific' rather than 'all', though it doesn't explicitly name the sibling. The 'Enterprise only' note adds useful scope but doesn't fully differentiate from 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 provides no guidance on when to use this tool versus alternatives like 'get-all-legal-holds' or 'get-case'. It mentions 'Enterprise only' which indicates a prerequisite, but offers no explicit when/when-not instructions or named alternatives. Usage is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Enterprise only,' hinting at access restrictions, but fails to describe key behaviors like pagination (implied by 'cursor' parameter), rate limits, authentication needs, or what the return format looks like. This leaves significant gaps for a tool with 5 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, efficient sentence with zero waste—it directly states the tool's purpose and a key restriction. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, and usage context, making it inadequate for an agent to fully understand how to invoke and interpret results from this 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 description coverage is 100%, providing full documentation for all parameters (orgId, caseId, legalHoldId, limit, cursor). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without compensating or adding 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 clearly states the action ('retrieves') and resource ('list of content items under legal hold'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get-legal-hold' or 'get-all-legal-holds' beyond mentioning 'content items,' which provides some differentiation but not explicit comparison.
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 minimal guidance with 'Enterprise only,' indicating a usage restriction, but lacks explicit when-to-use advice, alternatives (e.g., vs. 'get-legal-hold'), or prerequisites. No context on when this tool is preferred over others 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?
No annotations are provided, so the description carries full burden. It states 'Retrieve information' which implies a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what specific information is returned (e.g., node properties, children). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what information is retrieved (e.g., node details, children, metadata) or behavioral aspects like permissions. For a tool with no structured behavioral data, this leaves the agent with insufficient context to use it effectively.
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 clear descriptions for both parameters (boardId and itemId). The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for adequate but not enhanced 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 action ('Retrieve information') and target resource ('specific mind map node on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-mindmap-nodes' (plural) or 'get-specific-item', which might retrieve similar information, so it doesn't reach the highest 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. With siblings like 'get-mindmap-nodes' (for multiple nodes) and 'get-specific-item' (for generic items), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 action is to 'retrieve a list,' implying a read-only operation, but doesn't mention any behavioral traits like pagination behavior (implied by the 'cursor' parameter), rate limits, authentication needs, or what happens if no nodes exist. This leaves significant gaps for a tool with pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does, making it easy to parse quickly, though it could benefit from additional context for completeness.
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 parameters implying pagination ('limit', 'cursor'), the description is incomplete. It doesn't explain the return format (e.g., list structure, node details), pagination mechanics, or error conditions, leaving the agent with insufficient context to use the tool effectively beyond basic 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 has 100% description coverage, providing clear documentation for 'boardId', 'limit', and 'cursor'. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the relationship between 'limit' and 'cursor' or default behaviors. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieve') and resource ('list of mind map nodes on a Miro board'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-mindmap-node' (singular) or 'get-items-on-board', which could retrieve similar content, leaving room for confusion 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-mindmap-node' (singular) and 'get-items-on-board' that might overlap, there's no indication of when this list-focused tool is preferred, such as for bulk retrieval or paginated results.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 tool retrieves information, implying a read-only operation, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what the return data includes. For a tool with no annotations, this leaves significant gaps in understanding its 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 very concise with just one sentence, making it easy to parse quickly. However, it could be more front-loaded by explicitly stating the tool's name or key action first, and the parenthetical '(Enterprise only)' might be better integrated for clarity. Overall, it's efficient with minimal 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?
Given the lack of annotations and output schema, the description is insufficient for a tool that retrieves organizational data. It doesn't explain what information is returned (e.g., details like name, settings, or metadata), how to interpret the 'Enterprise only' restriction, or potential errors. For a read operation with no structured output guidance, more context is needed to ensure proper usage.
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, with the single parameter 'orgId' clearly documented as 'id of the organization'. The description doesn't add any extra meaning beyond this, such as format examples or sourcing details, but since the schema is comprehensive, the baseline score of 3 is appropriate as it adequately covers the parameter semantics.
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 purpose with a specific verb ('Retrieves') and resource ('organization information'), making it easy to understand what it does. However, it doesn't differentiate from sibling tools like 'get-organization-member' or 'get-organization-members', which also retrieve organization-related data, leaving some 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?
The description provides minimal guidance with the note '(Enterprise only)', implying usage is restricted to Enterprise contexts, but it doesn't explain when to use this tool versus alternatives like 'get-organization-member' or 'get-organization-members'. No explicit when/when-not scenarios or prerequisites are mentioned, leading to potential confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Enterprise only' indicating access restrictions, but fails to describe key behaviors: whether this is a read-only operation, if it requires specific permissions, pagination details (implied by 'cursor' parameter but not explained), rate limits, or what the returned list structure looks like. For a tool with 7 parameters and no annotations, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose upfront with no wasted words. It's appropriately sized for a list-retrieval tool, though the lack of additional context means it may be too brief rather than 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 complexity (7 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain the return format, pagination behavior, error conditions, or access requirements beyond 'Enterprise only'. For a tool that likely returns structured member data with filtering and pagination, more context is needed to help the agent use it effectively.
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% description coverage, thoroughly documenting all 7 parameters including 'orgId' (required), filtering options ('emails', 'role', 'license', 'active'), and pagination controls ('cursor', 'limit'). The description adds no parameter-specific information beyond what's already in the schema, meeting the baseline score when schema coverage is complete.
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 ('Retrieves a list') and resource ('members for an organization'), making the purpose evident. It also specifies 'Enterprise only' as a scope limitation. However, it doesn't differentiate from sibling tools like 'get-organization-member' (singular) or 'get-all-board-members', leaving some ambiguity about when to choose this specific 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?
The description provides minimal guidance with 'Enterprise only' hinting at access restrictions, but it lacks explicit when-to-use instructions. It doesn't mention alternatives (e.g., 'get-organization-member' for single members) or prerequisites, leaving the agent to infer usage from context without clear 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 full burden for behavioral disclosure. While 'retrieves' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what information is actually returned. The 'Enterprise only' note is helpful but insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose upfront. The 'Enterprise only' qualification is appropriately placed. There's no wasted verbiage, though it could be slightly more informative while maintaining 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 4 required parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what information is retrieved, the format of the response, error handling, or how this differs from similar member retrieval tools. The 'Enterprise only' note is the only contextual information provided.
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 all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. This meets the baseline expectation when schema does the heavy lifting, but adds no extra 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 clearly states the verb ('retrieves information') and resource ('about a specific project member'), making the purpose unambiguous. It distinguishes from sibling tools like 'get-organization-member' by specifying the project context. However, it doesn't explicitly differentiate from 'get-specific-board-member' which might retrieve similar information at board level.
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 minimal guidance - only noting this is 'Enterprise only' without explaining when to use this tool versus alternatives like 'get-organization-member' or 'get-specific-board-member'. No context about prerequisites, when this tool is appropriate, or what distinguishes it from similar retrieval tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a retrieval operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication needs, rate limits, error conditions, or what information is returned (e.g., content, metadata). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core action.
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. It doesn't explain what information is retrieved (e.g., text, color, position) or behavioral aspects like permissions. For a retrieval tool with rich sibling context, this minimal description leaves too many open questions.
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 clear documentation for both parameters (boardId and itemId). The description adds no additional meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate when 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 verb 'retrieve' and the resource 'sticky note item on a Miro board', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-item' or 'get-items-on-board' that might also retrieve sticky notes, which prevents 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 like 'get-specific-item' (which might retrieve any item type) or 'get-items-on-board' (which retrieves multiple items). There's no mention of prerequisites, exclusions, or specific contexts for 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 provided, the description carries the full burden of behavioral disclosure. It states it's a retrieval operation, implying read-only behavior, but doesn't specify authentication requirements, rate limits, error conditions, or what 'information' includes (e.g., tag metadata, associated items). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'information' is retrieved, potential return formats, or error handling. For a tool with two required parameters and no structured output, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear parameter descriptions in the schema itself. The description adds no additional parameter details beyond implying the need for a specific tag, which is already covered by the schema. This meets the baseline for high schema coverage without extra 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 clearly states the action ('Retrieve information') and target ('about a specific tag on a Miro board'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get-all-tags' or 'get-item-tags', which would require a more specific scope comparison.
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 lacks context about prerequisites, such as needing a specific tag ID, and doesn't mention sibling tools like 'get-all-tags' for broader queries or 'get-item-tags' for tag associations.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 the tool retrieves information, implying a read-only operation, but does not specify details like authentication requirements, rate limits, error handling, or the format of returned data. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before 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 directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, making it easy for an agent to parse quickly, with no wasted 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 lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It does not explain what information is returned, potential errors, or behavioral traits like permissions, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
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, clearly documenting both parameters ('boardId' and 'itemId') as unique identifiers. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, so it meets the baseline for adequate but not enhanced parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve information about') and resource ('a specific text item on a Miro board'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get-specific-item' or 'get-items-on-board', which might retrieve similar or broader information, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get-specific-item' or 'get-items-on-board', nor does it mention any prerequisites or exclusions. It lacks explicit usage context, leaving the agent to infer based on tool names 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 provided, the description carries full burden for behavioral disclosure. While 'Remove' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, whether it affects board access, or what happens to the member's content. It lacks critical behavioral context 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, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized and front-loaded with the core functionality.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address behavioral aspects like permission requirements, consequences of removal, or what the tool returns. Given the complexity of removing a board member, more context about the operation's impact is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear parameter documentation, so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema (boardId and memberId are self-explanatory), but it doesn't need to since the schema is comprehensive.
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 ('Remove') and target ('a specific member from a Miro board'), providing a specific verb+resource combination. It doesn't explicitly differentiate from sibling tools like 'remove-project-member', but the distinction is implied through the resource specificity (board member vs project member).
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's no mention of prerequisites (e.g., needing board admin permissions), when not to use it, or how it differs from similar tools like 'update-board-member' or 'remove-project-member' 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 full burden but lacks critical behavioral details. It states the action is a removal (implying mutation/destructive) but doesn't cover permissions needed, whether removal is reversible, side effects, or response format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action and includes a necessary constraint ('Enterprise only') without redundancy, making it optimally 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 tool's complexity (destructive mutation with 4 required parameters), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral traits like authorization needs, consequences of removal, or what the agent can expect upon success/failure, leaving critical gaps 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 100%, with all four parameters clearly documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without extra 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 clearly states the action ('Removes') and target ('a member from a project'), making the purpose evident. It distinguishes from siblings like 'remove-board-member' by specifying 'project' context. However, it doesn't explicitly differentiate from other member-removal tools beyond the project 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 minimal guidance with '(Enterprise only)', indicating a usage constraint, but offers no explicit when-to-use advice, alternatives (e.g., vs. 'remove-board-member'), prerequisites, or error conditions. This leaves the agent with little context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'shares' a board, implying a write/mutation operation, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if it overwrites existing shares, what happens when teamId is omitted, error conditions, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that front-loads the core purpose. Every word earns its place: 'Share a Miro board' establishes the action, 'with specific access level' clarifies a key parameter, and 'optional team assignment' highlights flexibility. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about permissions required, side effects (e.g., notifications sent), error handling, and what the tool returns. The high schema coverage helps with parameters, but behavioral and output context is missing, making it inadequate for safe 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'optional team assignment' (implied by teamId being optional) and 'specific access level' (already in schema). It doesn't provide additional context like what 'private' access means or how team assignment interacts with access levels.
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 ('share') and resource ('Miro board') with specific details about access level and optional team assignment. It distinguishes itself from sibling tools like 'update-board-member' or 'remove-board-member' by focusing on sharing rather than modifying existing permissions. However, it doesn't explicitly differentiate from all potential sharing-related tools that might exist in a broader 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. It doesn't mention prerequisites (e.g., needing board ownership/permissions), when not to use it, or how it relates to sibling tools like 'update-board-member' for modifying existing shares. The agent must infer usage from the tool name and parameters 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 provided, the description carries the full burden of behavioral disclosure. It states the action ('Ungroup') but doesn't explain what 'ungroup' entails (e.g., whether it disassembles a group into individual items, affects item positions, or requires specific permissions). It also omits details like side effects, error conditions, or response format, which are critical for a mutation tool without structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key verb ('Ungroup') and target, making it easy to parse. There is no wasted language, and it fits the tool's straightforward purpose well.
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 (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like what 'ungroup' does to items, the implications of the 'deleteItems' parameter, or what the tool returns. For a mutation tool without structured safety or output information, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (boardId, groupId, deleteItems) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as clarifying the 'ungroup' operation's effect on parameters. This meets the baseline score of 3 for high schema coverage without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ungroup') and the target ('a specific group on a Miro board'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'delete-group' or 'update-group', which handle group removal or modification differently, leaving some ambiguity about when to choose this tool over those 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing group), exclusions (e.g., not for deleting groups entirely), or compare it to sibling tools like 'delete-group' (which removes a group) or 'update-group' (which modifies group properties), leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('update') but doesn't mention permissions required, whether updates are partial or full, error handling, or what the response looks like (since no output schema exists). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste: 'Update an existing app card item on a Miro board'. It efficiently conveys the core purpose without unnecessary elaboration, earning full 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?
Given the complexity (a mutation tool with 5 parameters, no annotations, and no output schema), the description is incomplete. It lacks behavioral context (e.g., permissions, partial updates), usage guidance relative to siblings, and any information about return values or errors, making it insufficient for safe and effective tool 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 100%, so the schema fully documents all 5 parameters (boardId, itemId, data, position, geometry). The description doesn't add any meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples, but the baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('existing app card item on a Miro board'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'update-card-item' or 'update-item-position', which also update items on Miro boards, leaving some ambiguity about when to choose this specific 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'update-card-item', 'update-item-position', and 'delete-app-card-item', there's no indication of prerequisites, constraints, or comparative use cases, leaving the agent to guess based on tool names 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 full burden. While 'Update' implies mutation, it doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified settings. The description mentions 'new settings' but doesn't elaborate on scope or constraints beyond the basic 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, efficient sentence that gets straight to the point with zero waste. It's appropriately sized for a straightforward update operation and front-loads the core 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't address what 'new settings' encompasses, potential side effects, error conditions, or return values. Given the complexity of updating a board with multiple parameters and many sibling update tools, more context is needed for effective 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?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional meaning about parameters beyond implying 'settings' in general. With high schema coverage, the baseline is 3 even without param-specific details 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 clearly states the action ('Update') and resource ('an existing Miro board'), making the purpose immediately understandable. It distinguishes from creation tools like 'create-board' by specifying 'existing', but doesn't explicitly differentiate from other update tools like 'update-board-classification' or 'update-board-member' among the 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling update tools (e.g., update-board-classification, update-board-member), there's no indication of which settings this tool handles or when to choose it over other board-update tools. No prerequisites 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 provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) and is 'Enterprise only' (suggesting permission requirements), but doesn't describe what happens during classification update, whether changes are reversible, what permissions are needed, or what the response looks like. Significant behavioral gaps remain 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 extremely concise - a single sentence that communicates the core purpose and an important constraint ('Enterprise only'). There's no wasted language, and the key information is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what classification means in this context, what happens when applied, potential side effects, or what success/failure looks like. The 'Enterprise only' constraint is helpful but doesn't compensate for the lack of behavioral and output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain relationships between parameters or provide usage examples. Baseline 3 is appropriate when 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 ('Updates') and resource ('board classification for an existing board'), making the purpose understandable. It also specifies 'Enterprise only' which adds important context. However, it doesn't differentiate this tool from similar update tools like 'update-board' or 'update-board-member' among the 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?
The description provides minimal guidance - only that it's for 'Enterprise only' and updates classification. It doesn't explain when to use this versus other board update tools, what prerequisites exist, or any alternatives. No explicit when/when-not usage instructions 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 provided, the description carries full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention required permissions, whether changes are reversible, rate limits, or what happens if only role or status is provided. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that clearly states the tool's purpose. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized for a straightforward update 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format. While the schema covers parameters well, the overall context for safe and effective use is lacking given the tool's complexity as a member management 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%, with all parameters well-documented in the schema itself. The description mentions 'role or status' which aligns with two parameters, but doesn't add meaningful context beyond what the schema already provides about boardId and memberId. The baseline of 3 is appropriate when 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 verb 'update' and the resource 'specific member's role or status on a Miro board'. It distinguishes from siblings like 'add-project-member' or 'remove-board-member' by focusing on modification rather than addition or removal. However, it doesn't explicitly contrast with 'get-specific-board-member' or other update tools, keeping it at 4 rather than 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. It doesn't mention prerequisites like needing admin permissions, nor does it differentiate from similar tools like 'update-board' or 'update-project-member'. Without any usage context, the agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states this is an update operation but doesn't mention whether it requires specific permissions, what happens to fields not included in the update (partial vs. complete updates), whether the operation is idempotent, or what the typical response looks like. For a mutation tool with zero annotation coverage, this represents a significant gap in 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 extremely concise - a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and wastes no space on redundant or verbose explanations. This represents optimal conciseness for a basic tool 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 this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address important contextual aspects like error conditions, authentication requirements, rate limits, or what constitutes a successful update. The combination of being a write operation with minimal behavioral disclosure and no output information creates significant gaps for an AI agent trying to use this tool effectively.
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%, meaning all parameters are well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it doesn't explain relationships between parameters, provide examples of valid data payloads, or clarify parameter interactions. The baseline score of 3 reflects adequate parameter documentation coming entirely from the schema rather than 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 clearly states the action ('Update') and target resource ('an existing card item on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'update-app-card-item' or 'update-item-position', which would require more specific language about what makes this particular card update operation 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. With multiple update-related sibling tools available (update-app-card-item, update-item-position, update-board, etc.), there's no indication of when this specific card update tool is appropriate versus other update operations. No prerequisites, exclusions, or alternative recommendations 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 full burden but only states it's an update operation without disclosing behavioral traits. It doesn't mention permissions required, whether changes are reversible, rate limits, or what happens if parameters are omitted (e.g., partial updates). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context, usage guidelines, and doesn't compensate for the absence of structured safety or output information, leaving significant gaps for an AI 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 100%, so the schema fully documents all 5 parameters. The description adds no meaning beyond what the schema provides, not explaining parameter interactions or update semantics. Baseline 3 is appropriate when 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 ('Update') and resource ('an existing connector on a Miro board'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'update-board' or 'update-card-item' by specifying what aspects of a connector can be updated (e.g., endpoints, style).
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 doesn't mention prerequisites (e.g., needing board and connector IDs), exclusions, or related tools like 'create-connector' or 'delete-connector' from 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool updates a document item but fails to mention critical details such as required permissions, whether the update is partial or full, error handling (e.g., if the item doesn't exist), or the response format. This lack of information makes it inadequate for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly for the core action.
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 5 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral aspects (e.g., permissions, error handling), usage context, and return values, leaving significant gaps that could hinder an agent's ability to invoke the tool correctly and handle 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?
The input schema has 100% description coverage, with each parameter clearly documented (e.g., 'boardId' as the board's ID, 'data' for updated content). The description adds no additional meaning beyond the schema, such as explaining how 'data', 'position', and 'geometry' interact or providing examples. Given the high 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing document item on a Miro board'), making the purpose evident. However, it does not differentiate from sibling tools like 'update-board' or 'update-item-position', which are also update operations on Miro resources, leaving room for ambiguity in tool 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing board and item IDs), exclusions, or compare it to sibling tools like 'update-item-position' (which might handle only position updates) or 'create-document-item' (for new items), leaving the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Update' implies a mutation, it doesn't specify required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It lacks behavioral details, usage context, and output expectations, leaving the agent with significant gaps despite the comprehensive parameter 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 schema already documents all 5 parameters thoroughly. The description adds no additional parameter context beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
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 ('an existing embed item on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'update-app-card-item' or 'update-document-item' beyond the resource type, which prevents 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. With sibling tools like 'update-item-position' that might handle position updates separately, and no mention of prerequisites or constraints, the agent receives minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before 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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success or failure, any side effects, or how partial updates are handled. Given the complexity of updating multiple property types, more context is needed to guide effective 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing the categories of properties ('data, style, or geometry') but doesn't provide additional syntax, constraints, or examples beyond what's in the schema. This meets the baseline 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 clearly states the action ('Update a frame') and the resource ('on a Miro board'), specifying the properties that can be updated ('data, style, or geometry properties'). It distinguishes from siblings like 'create-frame' or 'delete-frame-item' by focusing on modification, but doesn't explicitly differentiate from other update tools like 'update-item-position' which might overlap in functionality.
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. For example, it doesn't mention when to choose 'update-item-position' for only positional changes or 'update-frame-item' for broader updates. There's no information on prerequisites, such as needing board and item IDs, or context for when frame updates are 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 of behavioral disclosure. It states the tool updates a group but doesn't describe what 'update' entails beyond 'with new items'—missing details like whether this overwrites existing items, requires specific permissions, affects other board elements, or has side effects. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose ('Update a specific group on a Miro board') and adds necessary detail ('with new items'). There's no wasted wording, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (mutation with 3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks behavioral details (e.g., update mechanics, permissions), output expectations, and usage context. While the schema covers parameters, the description doesn't compensate for missing annotations or output schema, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (boardId, groupId, data with items). The description adds minimal value by mentioning 'new items', which aligns with the 'items' parameter but doesn't provide additional syntax, format, or constraints beyond what the schema specifies. Baseline 3 is appropriate when 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 ('update') and target ('a specific group on a Miro board'), specifying what gets updated ('with new items'). It distinguishes from sibling tools like 'create-group' and 'delete-group' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other update tools like 'update-app-card-item' or 'update-board' beyond the group focus.
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 (e.g., needing an existing group), exclusions (e.g., not for creating groups), or comparisons to siblings like 'update-item-position' or 'ungroup-items'. The context is implied but not explicitly 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 states the tool updates an existing image item, implying mutation, but fails to mention critical details like required permissions, whether changes are reversible, potential side effects (e.g., affecting other board elements), or rate limits. This leaves significant gaps in understanding 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, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key information ('Update an existing image item'), making it easy for an agent to parse quickly. There is no wasted verbiage or redundant 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 mutation tool with no annotations and no output schema, the description is insufficient. It does not explain what the update operation returns (e.g., success confirmation, updated item details), potential error conditions, or how partial updates (e.g., only changing position) are handled. Given the complexity implied by multiple parameters and sibling tools, more contextual information is needed for effective 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 has 100% description coverage, clearly documenting all 5 parameters (boardId, itemId, data, position, geometry) with their purposes. The description does not add any semantic details beyond what the schema provides, such as explaining how 'data' might interact with other parameters or providing examples. Given the high 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.
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 ('existing image item on a Miro board'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'update-image-item-using-file' or 'update-item-position', which could cause confusion about when to use this specific tool versus 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 provides no guidance on when to use this tool versus alternatives, such as 'update-image-item-using-file' for file-based updates or 'update-item-position' for positional changes. It lacks context on prerequisites, like needing an existing image item, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool updates an image item, implying a mutation, but fails to mention critical details like whether this overwrites the existing image, what happens to metadata, error conditions, or authentication requirements. This leaves significant gaps 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, efficient sentence that front-loads the core action and resource. There is no wasted verbiage, and it directly communicates the essential purpose without 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 mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, error handling), output format, or usage context. Given the complexity of updating an image with a file, more completeness is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond implying 'filePath' is for a local device file, which is already clear from the schema. This meets the baseline 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 clearly states the action ('Update'), the resource ('an existing image item on a Miro board'), and the method ('using file from device'), making the purpose unambiguous. It distinguishes from sibling 'update-image-item' (which likely uses a URL) by specifying the file-based approach, though it doesn't explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update-image-item' (presumably URL-based) or 'create-image-item-using-file'. It also lacks prerequisites such as required permissions or file format constraints, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'update' which implies a mutation, but doesn't disclose behavioral traits like whether it requires specific permissions, if changes are reversible, rate limits, or what happens to other item properties. This leaves significant gaps 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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand quickly.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions or side effects, and while parameters are documented in the schema, the overall context for safe and effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (boardId, itemId, position, parentId) with clear descriptions. The description adds no additional meaning beyond implying the tool updates position or parent, which aligns with the schema but doesn't provide extra syntax or format 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 description clearly states the action ('update') and the resource ('position or parent of a specific item on a Miro board'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'update-frame-item' or 'update-group', which might also involve positional updates, so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing board and item IDs, or compare to other update tools like 'update-item' (if it exists) or tools for creating items, leaving usage context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing shape item,' implying a mutation operation, but doesn't cover critical aspects like required permissions (e.g., edit access to the board), whether updates are partial or overwrite all fields, error handling (e.g., if the item doesn't exist), or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Update') and resource, making it easy to parse. Every word earns its place, achieving optimal conciseness for a basic 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 complexity (a mutation with 6 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain what fields can be updated (e.g., shape type, content, style), how partial updates work, or what the response includes (e.g., success confirmation or updated item data). For a mutation tool without structured support, more detail is needed to guide the agent effectively.
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%, meaning all parameters are documented in the schema itself. The description adds no additional meaning beyond the schema, such as examples of valid shape types (e.g., 'rectangle') or style values. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing shape item on a Miro board'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'update-shape-item' vs 'update-item-position' or 'update-group', which also modify board items, so it lacks sibling differentiation for 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. It doesn't mention prerequisites (e.g., needing an existing shape item), exclusions (e.g., not for creating new shapes), or compare to siblings like 'update-item-position' (which might handle only position updates) or 'create-shape-item' (for new shapes). This leaves 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 of behavioral disclosure. While 'Update' implies a mutation, the description doesn't specify whether this requires specific permissions, what happens to unspecified fields (partial vs. full updates), or the response format. It lacks details on error conditions, rate limits, or side effects, leaving significant gaps 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 complexity (a mutation tool with 6 parameters, no annotations, and no output schema), the description is inadequate. It doesn't explain the update behavior (e.g., partial updates allowed), return values, error handling, or permissions required. For a tool that modifies resources, more contextual information is needed to ensure safe and correct usage.
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 all parameters well-documented in the schema itself (e.g., boardId, itemId, data with content and shape, position, geometry, style). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating 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 clearly states the action ('Update') and the resource ('an existing sticky note item on a Miro board'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from other update tools in the sibling list (like update-app-card-item, update-card-item, etc.), which would require mentioning what specifically gets updated about sticky notes.
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 (e.g., needing board and item IDs), when not to use it (e.g., for creating new sticky notes), or refer to sibling tools like 'create-sticky-note-item' or 'delete-sticky-note-item' for different 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permission requirements, whether changes are reversible, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for this tool and front-loads the essential information. 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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens on success/failure, what permissions are needed, or provide any behavioral context. The agent would need to guess about important aspects of tool behavior when invoking 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 description coverage is 100%, so the schema already documents all four parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify that only title and fillColor can be updated. Baseline 3 is appropriate when 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 ('Update') and resource ('an existing tag on a Miro board'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create-tag' and 'delete-tag' by specifying it's for updating existing tags. However, it doesn't specify what aspects of the tag can be updated, which prevents 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. It doesn't mention prerequisites (e.g., needing an existing tag), when not to use it (e.g., for creating new tags), or refer to related tools like 'create-tag' or 'delete-tag' from the sibling list. The agent must 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 provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't cover permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a tool with a well-documented schema, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format, which are critical for safe and effective use. The high schema coverage helps with parameters but doesn't compensate for the lack of operational 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 the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain the structure of 'data', 'position', 'geometry', or 'style' objects). Baseline 3 is appropriate when 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 verb ('Update') and resource ('an existing text item on a Miro board'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'update-sticky-note-item' or 'update-card-item' that also update items on Miro boards, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing board and item IDs), exclusions, or compare with other update tools like 'update-item-position' or 'update-sticky-note-item', leaving the agent to infer usage from context 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 provided, the description carries the full burden of behavioral disclosure. It states the tool performs an attachment operation but doesn't clarify whether this is a mutation (likely yes), what permissions are required, if it's idempotent, or what happens on success/failure. For a tool that modifies board state, this leaves significant behavioral 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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and 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?
For a mutation tool with no annotations and no output schema, the description is minimally adequate. It identifies the operation but lacks important context about behavioral traits, error conditions, and what constitutes successful execution. The high schema coverage helps, but more behavioral information would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, clearly documenting all three required parameters. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 where 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 ('attach') and resource ('a tag to an item on a Miro board'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling tool 'detach-tag', which is a clear alternative operation on the same resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'detach-tag' or 'update-tag', nor does it mention prerequisites such as needing existing tags or items. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. It states this is a creation tool but doesn't mention whether it requires specific permissions, if it's idempotent, what happens on failure, or what the return value looks like. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and follows a clear subject-verb-object 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?
For a creation tool with 3 required parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidance, and output information. The schema handles parameter documentation well, but the description doesn't compensate for the missing annotations and 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 description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and resource ('new mind map node on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create-text-item' or 'create-sticky-note-item' that also create items on Miro boards, missing the specific mind map node 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing board), compare to similar creation tools in the sibling list, or indicate when other tools might be more appropriate for different types of content creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. It states this is a retrieval operation but doesn't mention whether it requires authentication, has rate limits, returns paginated results, or what format the members data comes in. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before 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 states the core purpose without any wasted words. It's appropriately sized for a straightforward retrieval tool and gets directly to the point.
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 read operation with 100% schema coverage but no annotations or output schema, the description provides the basic purpose but lacks important context about authentication requirements, return format, pagination behavior, and differentiation from sibling tools. It's minimally adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for boardId, limit, and offset parameters. The description doesn't add any additional parameter semantics beyond what's already in the schema (like explaining member data structure or pagination strategy), so it meets the baseline 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 clearly states the verb ('retrieve') and resource ('all members of a specific Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-board-member' or 'get-organization-members', which would require more specific scoping language to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-specific-board-member' (for individual members) or 'get-organization-members' (for broader scope). It also doesn't mention prerequisites such as needing board access permissions or when pagination through limit/offset is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose whether this is a read-only operation (implied by 'retrieve'), potential rate limits, authentication requirements, pagination behavior (though schema hints at it), or what happens when no groups exist. For a tool with 3 parameters and no annotations, 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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a straightforward retrieval tool and front-loads 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?
For a retrieval tool with good schema coverage but no annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks important context about behavioral traits, differentiation from siblings, and output expectations. The schema handles parameters well, but the description doesn't compensate for missing annotation 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?
Schema description coverage is 100%, providing clear documentation for all parameters (boardId, limit, cursor). The description doesn't add any meaningful parameter semantics beyond what's already in the schema, so it meets the baseline for high schema coverage without adding 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 clearly states the action ('Retrieve all groups') and resource ('on a Miro board'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-group' (singular) or 'get-group-items', which could cause confusion 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 about when to use this tool versus alternatives like 'get-group' (for a specific group) or 'get-group-items' (for items within groups). The description simply states what it does without context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Retrieve' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what information is returned (e.g., fields, format). For a tool with no annotation coverage, this leaves significant behavioral 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. 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.
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 (2 simple parameters) and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it should ideally provide more context about return values or behavioral traits. It meets basic requirements but lacks depth for full agent understanding.
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, clearly documenting both parameters (boardId and itemId). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. With high schema coverage, the baseline score of 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 clearly states the verb 'Retrieve' and the resource 'information about a specific app card item on a Miro board', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-card-item' or 'get-specific-item', which appear to retrieve similar resources, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get-card-item', 'get-specific-item', and 'get-items-on-board' available, there's no indication of how this tool differs in scope or when it should be preferred, leaving the agent 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 carries the full burden of behavioral disclosure. It states 'Retrieves' (implying read-only) and 'Enterprise only' (a constraint), but lacks details on permissions needed, rate limits, error conditions, or what the classification data looks like. For a read operation with no annotation coverage, 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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes a key constraint ('Enterprise only') concisely. Every part of the sentence serves a 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 moderate complexity (3 required parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose and a constraint but lacks behavioral details, usage context, and output information. It's complete enough to understand what it does but not how to use it effectively.
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 all three parameters (orgId, teamId, boardId) clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without adding 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 clearly states the action ('Retrieves') and resource ('board classification for a board'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-board' or 'get-board-export-job-status', which also retrieve board-related information but for different data types.
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 mentions 'Enterprise only', which is a constraint but not a usage guideline. There's no indication of prerequisites, when to choose this over other board-related get tools, or any 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 states this is a retrieval operation, implying it's read-only, but doesn't clarify permissions, rate limits, error handling, or what information is returned (e.g., fields, format). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that directly states the tool's purpose without any redundant or unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 (simple retrieval with 2 parameters) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to fully compensate for missing behavioral and return value details, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (boardId and itemId). The description adds no additional semantic context beyond what the schema provides, such as format examples or relationships between parameters. Baseline 3 is appropriate when 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 verb 'retrieve' and the resource 'specific card item on a Miro board', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-item' or 'get-items-on-board', which could also retrieve card items, so it doesn't reach the highest 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 like 'get-specific-item' or 'get-items-on-board', nor does it mention any prerequisites or exclusions. It merely states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 but offers minimal behavioral insight. It states it 'retrieves' data, implying a read-only operation, but doesn't disclose pagination behavior (implied by 'cursor' parameter), rate limits, authentication requirements, or error conditions. The description adds little beyond what's obvious from 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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately front-loaded and earns its place by clearly communicating the core functionality.
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 read operation with 100% schema coverage but no output schema, the description is minimally adequate. It specifies the resource (connectors) and scope (board), but lacks context about return format, pagination behavior, or error handling. Given the absence of annotations and output schema, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for all three parameters (boardId, limit, cursor). The description doesn't add any parameter semantics beyond what the schema provides—it mentions 'specific Miro board' which aligns with boardId but offers no additional context about parameter usage or interactions.
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 ('Retrieve') and resource ('all connectors on a specific Miro board'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-specific-connector' or 'get-items-on-board', which might retrieve similar data with different scopes or filters.
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 sibling tools like 'get-specific-connector' (for a single connector) or 'get-items-on-board' (which might include connectors among other items), leaving the agent to infer usage context from tool names 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 full burden. It states this is a retrieval operation, implying it's likely read-only, but doesn't confirm this or disclose other behavioral traits like authentication needs, rate limits, error conditions, or what 'information' includes (e.g., metadata, content). For a tool with no annotation coverage, this leaves significant gaps in understanding its 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, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse quickly.
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 retrieval tool with 2 parameters and 100% schema coverage, the description covers the basic purpose adequately. However, with no annotations and no output schema, it lacks details on behavioral aspects (e.g., safety, permissions) and return values, which are important for an agent to use it correctly. This makes it minimally viable 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?
Schema description coverage is 100%, with clear descriptions for both parameters (boardId and itemId). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 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 clearly states the verb ('retrieve') and resource ('information for a specific frame on a Miro board'), making the purpose explicit. However, it doesn't distinguish this tool from similar retrieval tools like 'get-app-card-item' or 'get-specific-item' in the sibling list, which would require mentioning what makes frame retrieval unique.
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 siblings like 'get-specific-item' (which might retrieve any item type) and 'get-items-on-board' (which lists multiple items), there's no indication of when this frame-specific retrieval is preferred, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'retrieve information' which implies a read-only operation, but does not disclose behavioral traits like authentication needs, rate limits, error handling, or what specific information is returned (e.g., group metadata, permissions). This leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for its function.
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 annotations and no output schema, the description is minimal but covers the basic purpose. It lacks details on return values, error cases, or operational context, making it adequate but incomplete for a read operation tool in this environment.
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 clear descriptions for 'boardId' and 'groupId'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate as the schema adequately documents 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 verb 'retrieve' and resource 'information about a specific group on a Miro board', making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get-all-groups' (which retrieves multiple groups) or 'get-group-items' (which retrieves items within a group), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get-all-groups' for listing groups or 'get-group-items' for group contents. The description implies usage for a specific group but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation, implying it's read-only, but doesn't mention pagination behavior (implied by 'cursor' parameter), rate limits, authentication needs, or what 'items' encompass. This leaves significant gaps for a tool with 4 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, efficient sentence that front-loads the core purpose. There's zero wasted language, and it immediately communicates what the tool does 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?
For a retrieval tool with 4 parameters and 100% schema coverage but no annotations or output schema, the description is minimally adequate. It states the purpose clearly but lacks behavioral context (pagination, item types) and usage guidelines compared to siblings, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter information beyond what's in the schema (e.g., doesn't explain item types or group relationships). Baseline 3 is appropriate when 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 verb ('Retrieve') and resource ('all items in a specific group on a Miro board'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-all-groups' or 'get-items-on-board', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-all-groups' (which lists groups) or 'get-items-on-board' (which retrieves items without group filtering). There's no mention of prerequisites, exclusions, or comparative 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 carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify permissions required, rate limits, error conditions, or the format of the returned information. For a tool with zero annotation coverage, this is a significant gap in 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, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse and understand quickly.
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 (2 simple parameters) and high schema coverage, the description is adequate for basic understanding. However, with no annotations and no output schema, it lacks details on behavioral traits and return values, which are important for a retrieval operation. This makes it minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (boardId and itemId). The description adds no additional semantic information beyond what the schema provides, such as example values or constraints. With high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'shape item on a Miro board', making the purpose specific and understandable. However, it doesn't distinguish this tool from similar sibling tools like 'get-specific-item' or 'get-app-card-item', which also retrieve specific items, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-specific-item' (which might retrieve any item type) or 'get-items-on-board' (which retrieves multiple items), leaving the agent with no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a retrieval operation, implying it's likely read-only and non-destructive, but doesn't confirm this or mention any constraints like authentication requirements, rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Retrieve information'), making it easy to parse. Every part of the sentence earns its place by specifying the resource and key parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage guidelines, behavioral traits, or output format. Without annotations or an output schema, the agent is left guessing about the response structure and operational constraints, making this incomplete for optimal 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?
Schema description coverage is 100%, with the single parameter 'boardId' fully documented in the schema as 'Unique identifier (ID) of the board that you want to retrieve'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules, so it meets 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 clearly states the verb ('Retrieve information') and resource ('about a specific Miro board'), making the purpose explicit. However, it doesn't distinguish this tool from similar siblings like 'get-board-export-job-results' or 'get-board-content-logs', which also retrieve board-related information but for different aspects.
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 siblings like 'list-boards' (for multiple boards) or 'get-specific-item' (for board items), leaving the agent without context for tool selection. The only implied usage is retrieving a single board by ID, but this isn't explicitly 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 full burden but only states it 'retrieves details' without disclosing behavioral traits like authentication needs, rate limits, error conditions, or what details are returned. This is inadequate for a read operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads 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?
For a simple read operation with 2 parameters and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more context about return values or behavioral constraints to reach higher 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?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what's in the schema (e.g., format of IDs, where to find them), meeting the baseline 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 clearly states the verb ('Retrieve details') and resource ('specific member on a Miro board'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling 'get-all-board-members' or 'get-organization-member', which would require 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 on when to use this tool versus alternatives like 'get-all-board-members' or 'get-organization-member'. The description only states what it does, not when it's 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 of behavioral disclosure. While 'retrieve information' implies a read-only operation, it doesn't specify permissions required, rate limits, error conditions, or the format/scope of returned information. For a tool with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and 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 tool's moderate complexity (retrieving a specific resource), 100% schema coverage for inputs, no annotations, and no output schema, the description is minimally adequate. It clearly states what the tool does but lacks details on behavior, output, or usage context that would be helpful 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 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond implying that 'boardId' and 'connectorId' are needed to locate the connector. This meets the baseline 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 clearly states the verb 'retrieve' and resource 'information about a specific connector on a Miro board', making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'get-connectors' (plural) or 'get-specific-item', but the specificity of 'specific connector' implies a single-item lookup versus a list 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. It doesn't mention sibling tools like 'get-connectors' for listing multiple connectors or 'get-specific-item' for generic item retrieval, nor does it specify prerequisites or contextual constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'retrieve information' which implies a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what information is returned. For a tool with no annotations, 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, efficient sentence that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 (2 required parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks details on return values or behavioral context, which would be helpful since there's no output schema to compensate.
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 clearly documented in the schema. The description adds no additional meaning beyond the schema's parameter descriptions, so it meets the baseline of 3 without compensating or adding 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 clearly states the verb ('retrieve information') and resource ('specific item on a Miro board'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'get-app-card-item' or 'get-card-item', which appear to retrieve specific item types, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-items-on-board' (for listing multiple items) or other specific item-type getters. It lacks explicit when/when-not instructions or named alternatives, offering only basic 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 carries full burden for behavioral disclosure. While 'List' implies a read-only operation, it doesn't mention authentication requirements, rate limits, pagination behavior (beyond what's in the schema), or what 'all available' means in terms of access permissions. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before 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 states exactly what the tool does with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with good schema coverage but no output schema and no annotations, the description is minimally adequate. It states what the tool does but doesn't provide important context about authentication, permissions, or how results are structured. The absence of output schema means the description should ideally mention something about return format, but it doesn't.
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 ('limit' and 'offset') clearly documented in the schema itself. The description adds no parameter information beyond what the schema provides, which is acceptable given the comprehensive schema coverage. This meets the baseline expectation when 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 verb ('List') and resource ('all available Miro boards'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-specific-board' or 'get-items-on-board' that also retrieve board information, so it doesn't reach the highest 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. With siblings like 'get-specific-board' (for single boards) and 'get-items-on-board' (for board contents), there's no indication of when this list-all-boards approach is preferred over more targeted queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 but only states the action without behavioral details. It doesn't disclose whether deletion is permanent, requires specific permissions, has side effects on connected items, or provides confirmation feedback. For a destructive operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before 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 with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
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 is incomplete. It lacks critical context about behavioral traits (e.g., permanence, permissions), expected outcomes, or error conditions. The purpose is clear, but operational guidance 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?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond implying 'connectorId' identifies what to delete and 'boardId' where it's located, which is already covered. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('a specific connector from a Miro board'), distinguishing it from siblings like 'delete-board', 'delete-item', or 'update-connector'. It precisely identifies what gets deleted and where it's located.
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. While the purpose is clear, there's no mention of prerequisites (e.g., needing board access), consequences (e.g., irreversibility), or when to choose other deletion tools like 'delete-item' for generic items.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. While 'Delete' implies a destructive mutation, it doesn't specify whether this operation is reversible, what permissions are required, whether it affects related items, or what happens on success/failure. For a destructive tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before 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 states the core purpose without any wasted words. It's appropriately sized for a straightforward deletion tool and gets directly to the point with no unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical context like what 'delete' means operationally (permanent vs. soft delete), error conditions, authentication requirements, or what the agent should expect after invocation. The combination of destructive nature and lack of structured metadata demands more descriptive guidance.
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 clearly documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions for boardId and itemId. This meets the baseline expectation when schema 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 clearly states the specific action ('Delete') and target resource ('a specific document item from a Miro board'), distinguishing it from other deletion tools like delete-board or delete-item by specifying the document item type. It provides a precise verb+resource combination that leaves no ambiguity about 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 like delete-item (which might handle generic deletions) or other deletion tools for different item types. There's no mention of prerequisites, constraints, or comparison with sibling tools, leaving the agent to infer usage context 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 full burden. It mentions 'Enterprise only', hinting at access restrictions, but lacks details on permissions, rate limits, pagination behavior (implied by 'cursor' param but not explained), or response format. For a read operation with 3 parameters, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Retrieves the list'). It avoids redundancy but could be slightly more informative (e.g., clarifying pagination). Every word earns its place, though it's borderline 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?
Given no annotations, no output schema, and 3 parameters with full schema coverage, the description is adequate but incomplete. It covers the basic purpose and a restriction ('Enterprise only'), but lacks details on behavioral traits, response structure, or error handling. For a list-retrieval tool, this is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying organization scope ('in an organization'), which is already covered by 'orgId'. No syntax, format, or usage examples are provided, meeting the baseline 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 clearly states the verb ('Retrieves') and resource ('list of eDiscovery cases'), making the purpose specific. It distinguishes from siblings like 'get-case' (singular) and 'get-legal-hold' (different resource), though not explicitly. However, it doesn't fully differentiate from 'get-all-legal-holds' (similar pattern) or clarify scope beyond 'Enterprise only', leaving some 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 usage by mentioning 'Enterprise only', suggesting a context restriction, but doesn't explicitly state when to use this tool vs. alternatives like 'get-case' (singular) or 'get-legal-hold' (different type). No guidance on prerequisites, exclusions, or comparisons with siblings is provided, relying on implied 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 carries the full burden. It mentions 'a page' (implying pagination) and 'Enterprise only' (implying access restrictions), but doesn't disclose other behavioral traits like rate limits, authentication needs, response format, or what happens with invalid parameters. For a read operation with no annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('retrieves a page of audit events') and includes key constraints ('from the last 90 days', 'Enterprise only') 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?
Given no annotations, no output schema, and a read operation with 5 parameters, the description is minimally complete. It covers the basic purpose and scope but lacks details on behavioral aspects (e.g., error handling, pagination mechanics) and output format, which are important for a tool with multiple parameters and no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (e.g., 'createdAfter' for ISO 8601 dates, 'cursor' for pagination). The description adds no additional parameter semantics beyond what's in the schema, such as default values for 'limit' or 'sorting', which are already covered. Baseline 3 is appropriate when 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 verb ('retrieves') and resource ('audit events'), specifying it's 'a page' and from 'the last 90 days'. However, it doesn't distinguish this tool from other 'get-' siblings like 'get-board-content-logs' or 'get-legal-hold-content-items', which also retrieve logs but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'Enterprise only', suggesting it's for enterprise-level audit logs, but doesn't explicitly state when to use this versus other log-related tools (e.g., 'get-board-content-logs') or provide alternatives. The context is clear but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 tool retrieves status, implying a read-only operation, but doesn't specify what the status includes (e.g., progress, errors), whether it's idempotent, or any rate limits. The mention 'Enterprise only' adds some context about access restrictions, but overall, the description lacks details on behavioral traits like response format or error handling, making it insufficient for a mutation-free 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, efficient sentence that front-loads the core purpose ('Retrieves the status of a board export job') and adds a contextual note ('Enterprise only') without unnecessary elaboration. Every word serves a purpose, making it appropriately sized and well-structured for quick understanding.
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 is low (simple status retrieval with 2 parameters) and no output schema is provided, the description is minimally complete but lacks depth. It covers the basic purpose and hints at enterprise restrictions, but without annotations or output details, it doesn't fully explain what the status entails or how to interpret results. This makes it adequate for basic use but with clear gaps in guiding effective tool 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 has 100% description coverage, with clear documentation for 'orgId' and 'jobId'. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or relationships between parameters. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's completeness.
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 ('Retrieves') and the resource ('status of a board export job'), making the purpose specific and understandable. It distinguishes from siblings like 'create-board-export-job' by focusing on status retrieval rather than creation. However, it doesn't explicitly differentiate from 'get-board-export-job-results', which might handle similar job-related data, leaving some 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 usage when checking the status of an existing board export job, as suggested by the verb 'Retrieves' and the parameter 'jobId'. It mentions 'Enterprise only', providing some context on availability. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get-board-export-job-results' or prerequisites such as job completion, leaving usage somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 mentions 'Enterprise only,' which adds useful context about licensing or access restrictions. However, it lacks details on permissions needed, error handling, rate limits, or what information is returned, which are important for a retrieval 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, efficient sentence that front-loads the key information ('Retrieves information about a specific eDiscovery case') and adds a necessary constraint ('Enterprise only') without any wasted words. It's appropriately sized for its 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 low complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and a key constraint ('Enterprise only'), but as a retrieval tool with no annotations, it could benefit from more details on behavior or output to be 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?
The schema description coverage is 100%, meaning both parameters (orgId and caseId) are well-documented in the schema itself. The description doesn't add any additional meaning or context about the parameters beyond what the schema provides, so it meets 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 clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('information about a specific eDiscovery case'), making it easy to understand what it does. However, it doesn't explicitly distinguish this tool from its sibling 'get-all-cases' beyond the 'specific' qualifier, which is why it doesn't reach 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'specific eDiscovery case' and 'Enterprise only,' suggesting it's for retrieving individual cases rather than lists. However, it doesn't provide explicit guidance on when to use this versus 'get-all-cases' or other alternatives, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. It states the tool retrieves information (implying read-only), but doesn't specify what information is returned, whether authentication is required, if there are rate limits, or what happens with invalid IDs. The '(Enterprise only)' hint adds some context about access restrictions, but overall behavioral details are insufficient for a mutation-free 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, efficient sentence that communicates the core purpose upfront. Every word earns its place: 'Retrieves information' (action), 'about a specific organization member' (resource), '(Enterprise only)' (important restriction). There's no redundancy or 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?
Given this is a read operation with 2 required parameters and no output schema, the description is minimally adequate. It covers the basic purpose and an important restriction (Enterprise only), but lacks details about return format, error conditions, or authentication requirements. The absence of annotations and output schema means the description should do more to compensate, but it only partially meets this need.
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 clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter details in the description, which applies here.
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 ('Retrieves information') and resource ('about a specific organization member'), making the purpose unambiguous. It distinguishes from sibling tools like 'get-organization-members' (plural) by specifying a single member. However, it doesn't explicitly differentiate from 'get-project-member' or 'get-specific-board-member' which have similar retrieval patterns for different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with '(Enterprise only)', suggesting this tool is restricted to enterprise organizations. However, it provides no explicit guidance on when to use this tool versus alternatives like 'get-organization-members' (for listing all members) or 'get-project-member' (for project-specific members). The agent must infer usage from the tool name and limited contextual hint.
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 and adds valuable behavioral context beyond the basic action. It discloses that deleted boards go to Trash on paid plans and can be restored via UI within 90 days, which informs about reversibility and plan dependencies. However, it doesn't cover error conditions or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and efficiently adds crucial behavioral details in a second sentence. Every sentence earns its place by providing essential information without redundancy or fluff, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with no annotations or output schema), the description is reasonably complete. It explains the deletion outcome and restoration details, but lacks information on permissions, error handling, or response format, leaving some gaps for an AI 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 description coverage is 100%, with the single parameter 'boardId' well-documented in the schema. The description doesn't add any additional meaning or examples beyond what the schema provides, such as format or validation rules, so it meets 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 specific action ('Delete a Miro board') and resource ('by its ID'), distinguishing it from siblings like 'delete-item' or 'delete-frame-item' which target different resources. It precisely identifies what the tool does without being 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing board ownership or specific permissions, or differentiate from similar deletion tools like 'delete-item' in the sibling list. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![mcp-miro MCP server](https://glama.ai/mcp/servers/k-jarzyna/mcp-miro/badges/card.svg)](https://glama.ai/mcp/servers/k-jarzyna/mcp-miro)

Score Badge

Copy to your README.md:

[![mcp-miro MCP server](https://glama.ai/mcp/servers/k-jarzyna/mcp-miro/badges/score.svg)](https://glama.ai/mcp/servers/k-jarzyna/mcp-miro)

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/k-jarzyna/mcp-miro'

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