Circuitry MCP Server

Official

by circuitry-dev

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear domains (e.g., codebook, nodes, sheet, layout), but there is significant overlap within domains that could confuse an agent. For example, codebook.addCell and code.create/text.create/sheet.create have overlapping purposes depending on context, and sheet.* vs. spreadsheet.* tools have similar functionalities but target different document types. Descriptions help clarify, but the boundaries are not always distinct.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with dot notation for namespacing (e.g., codebook.addCell, nodes.delete, layout.createSection). All tools use snake_case consistently, and naming conventions are predictable across the entire set, making it easy to infer functionality from names.
Tool Count2/5
With 134 tools, the count is excessive for the server's purpose of interacting with Circuitry's workflow and design features. This many tools creates a steep learning curve and likely includes redundant or overly granular operations that could be consolidated, such as multiple sheet and spreadsheet tools with similar functions. A more focused set of 20-40 tools would be more appropriate.
Completeness5/5
The tool surface is exceptionally complete, covering CRUD/lifecycle operations for all major domains (e.g., nodes, edges, code, sheets, layout, screens). It includes comprehensive workflows from connection management to execution, design, and documentation, with no apparent gaps that would cause agent failures. The tools support everything from basic creation to advanced analysis and fixes.
Average 3.4/5 across 134 of 134 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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 Unlicense - libtelnet variant.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create an image node' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions needed, whether creation is reversible, what happens on failure, rate limits, or what the tool returns. 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 extremely concise at just three words. While it's arguably too brief for adequate tool documentation, it contains zero wasted words and is perfectly front-loaded. Every word serves the core purpose statement, making it maximally efficient in terms of word economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool (creating something) with no annotations, no output schema, and 3 parameters, the description is insufficiently complete. The agent needs to understand what system this creates nodes in, what happens after creation, and behavioral constraints. The description fails to provide this context, leaving significant gaps for a tool that presumably modifies state.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all three parameters (name, url, position) documented in the schema itself. The description adds no parameter information beyond what the schema provides. According to the scoring rules, when schema_description_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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an image node' is essentially a tautology that restates the tool name 'image.create' with minimal elaboration. It doesn't specify what an 'image node' is, what system it's created in, or how it differs from sibling tools like 'html.create', 'text.create', or 'screen.create'. The purpose is vaguely implied but lacks the specificity needed for clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for creating different types of content (html.create, text.create, code.create, etc.), there's no indication of what an 'image node' is used for, what context it applies to, or prerequisites for its use. This leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Update' implies a mutation operation, but it doesn't disclose whether this requires specific permissions, if changes are reversible, what happens to existing configuration not mentioned, or potential side effects. For a tool that modifies chart settings without any annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted text. It's front-loaded with the core action and target, making it easy to parse quickly. While brevity can lead to underspecification, here it's efficiently structured 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 the tool's complexity (mutating chart settings with a nested object parameter) and lack of annotations or output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, or how the configuration object should be structured. For a tool that likely involves detailed settings, more context is needed 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 both parameters ('nodeId' and 'config') documented in the schema. The description adds no additional meaning about these parameters—it doesn't explain what a 'Chart node ID' refers to or what 'Chart configuration' entails beyond the schema's basic labels. This meets the baseline score 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update chart configuration' clearly states the action (update) and target (chart configuration), which is better than a tautology. However, it doesn't specify what aspects of configuration are updated or how this differs from sibling tools like 'chart.create' or 'nodes.updateFlowchart' that might also affect charts. The purpose is understandable but lacks differentiation from related 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. With sibling tools like 'chart.create' (likely for initial setup) and 'nodes.updateFlowchart' (potentially for structural changes), there's no indication whether this is for visual settings, data bindings, or other aspects. The agent must infer usage from the tool name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Set image source', implying a mutation operation, but doesn't disclose behavioral traits like whether this requires specific permissions, if it overwrites existing sources, what happens on invalid inputs, or if it returns confirmation. 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 explain what happens after setting the source (e.g., does it return success, the updated image, or nothing?), error conditions, or side effects. For a tool that modifies state, more context 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?
Schema description coverage is 100%, with clear descriptions for both parameters ('Image node ID' and 'Image URL or base64 data URI'). The description adds no additional meaning beyond what the schema provides, such as format details 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set image source URL or data' clearly states the action (set) and resource (image source), but it's vague about what exactly is being set. It doesn't specify whether this updates an existing image node's source or creates a new image with a source. Compared to sibling tools like 'image.create', the distinction isn't explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing image node), when not to use it, or how it differs from related tools like 'image.create'. 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'update' implies a mutation operation, the description doesn't specify whether this requires specific permissions, what happens to existing data not mentioned in the update, whether the operation is idempotent, or what the response looks like. 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 extremely concise at just one sentence ('Update a node's data/configuration.'), with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in this minimal formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error conditions, response format, or side effects. With 2 parameters and a nested object in the schema, more context about the update operation's semantics would be helpful 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 input schema has 100% description coverage, with clear documentation for both parameters ('nodeId' and 'data'). The description adds no additional semantic context beyond what's in the schema, such as explaining what 'data' should contain or how the merge operation works. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a node's data/configuration' clearly states the verb ('update') and resource ('node'), making the purpose understandable. However, it's somewhat vague about what 'data/configuration' entails and doesn't differentiate from sibling tools like 'nodes.add', 'nodes.get', or 'nodes.updateFlowchart', which could cause confusion about when to use this specific update 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. With many sibling tools like 'nodes.add', 'nodes.get', 'nodes.updateFlowchart', and 'layout.update', there's no indication of prerequisites, appropriate contexts, or exclusions. This leaves the agent guessing about the right tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, what happens if the screen doesn't exist, or the format of the returned data. 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 is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, 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 'Get' operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'Get' returns (e.g., screen details, metadata, or content), potential errors, or usage context. 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 input schema has 100% description coverage, with 'screenId' documented as 'Screen ID or name'. The description adds no additional meaning beyond this, such as examples or constraints. Since schema coverage is high, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get') and resource ('a screen'), but is vague about what 'Get' entails—it could mean retrieve, fetch, or load. It doesn't distinguish from siblings like 'screen.list' (which lists screens) or 'screen.select' (which might select a screen), leaving ambiguity in the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for retrieving screen details by ID/name, or how it differs from 'screen.list' (which lists screens) or 'screen.select' (which might activate a screen). The description lacks 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 the full burden of behavioral disclosure. While 'create' implies a write/mutation operation, the description doesn't address important behavioral aspects like: what happens if a chart with the same name already exists, whether this requires specific permissions, where the created chart appears in the interface, or what the expected response format is. For a creation tool with zero annotation coverage, this represents significant gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point without any wasted words. It's front-loaded with the essential information (create a chart/visualization node) and doesn't include unnecessary elaboration. This is an excellent example of efficient communication.
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 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, where the chart appears, how it integrates with other tools, or provide any context about the charting system. The agent would need to guess about important aspects like whether the chart is immediately visible, editable, or how to reference it later.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds no additional parameter information beyond what's already in the schema - it doesn't explain what 'chart data configuration' should contain, how 'position' coordinates work, or provide examples of valid chart configurations. With complete 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 ('create') and resource ('chart/visualization node'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar creation tools like 'html.create', 'image.create', 'screen.create', or 'text.create' that also create visual elements, leaving some ambiguity about when to choose this specific chart creation 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 multiple creation tools available (chart.create, html.create, image.create, screen.create, text.create, etc.), there's no indication of what makes this chart creation tool distinct or when it should be preferred over other visualization creation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Check connection status' implies a read-only diagnostic operation, but it doesn't specify what information is returned (e.g., connected/disconnected, latency, error details), whether it has side effects, or what authentication/rate limits apply. For a status-checking tool 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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple status-checking tool and front-loads 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 diagnostic tool with no annotations and no output schema, the description should explain what information is returned (e.g., boolean connection state, detailed status object, error conditions). 'Check connection status' is too vague about the return value format. Given the lack of structured output documentation, the description should compensate more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't discuss parameters since none exist. This meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Check connection status to Circuitry', which is a clear verb+object combination. However, it doesn't differentiate from sibling tools like 'circuitry.connect' or 'circuitry.disconnect' - it's unclear if this is a diagnostic tool versus an action tool. The purpose is understandable but lacks sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With siblings like 'circuitry.connect' and 'circuitry.disconnect', it's unclear if this should be used before attempting connection, after disconnection, or as a general health check. The description offers no usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Execute') but doesn't clarify what execution entails (e.g., runs code, may have side effects, requires specific permissions, or returns output). This leaves critical behavioral traits unspecified for a tool that likely performs an operation with potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and target, making it efficient and easy to parse, 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 complexity (likely an execution tool with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't explain what happens during execution, what the output might be, or any error conditions, leaving significant gaps for the agent to understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, fully documenting the single parameter 'cellId' with its description. The description doesn't add any parameter details beyond the schema, but with only one parameter and high schema coverage, this is acceptable. The baseline is 3, but the simplicity (0 params in description, 1 param total) justifies a 4 as the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Execute') and target ('a specific cell in CodeBook'), which clarifies the basic purpose. However, it doesn't differentiate from sibling tools like 'codebook.runAll' or explain what 'execute' entails in this context, making it somewhat vague compared to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'codebook.runAll' or 'execution.start'. The description lacks context about prerequisites (e.g., whether the cell must be in an open CodeBook) or typical use cases, leaving the agent with no 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. While 'Set' implies a mutation operation, it doesn't specify whether this affects existing cells, requires specific permissions, has side effects, or what happens on success/failure. For a configuration 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, clear sentence that states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after setting the target, whether the change is persistent, how to verify it worked, or potential error conditions. 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 schema has 100% description coverage, with the 'target' parameter fully documented in the schema itself ('Execution target: pyodide, this-computer, or eserver:<id>'). The description adds no additional parameter information beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target resource ('Python execution target for new code cells'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'codebook.getExecutionTarget' beyond the verb difference, 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, prerequisites, or consequences. It doesn't mention the sibling 'codebook.getExecutionTarget' for checking current settings or other execution-related tools, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions that 'EServer fetches files and sets up sync,' which hints at network/file operations and ongoing synchronization, but doesn't specify permissions needed, error handling, rate limits, or what 'sync' entails. For a creation tool with mutation implications, 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.
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. It could be slightly more structured by separating behavioral details, but there's no wasted text, and it conveys essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic action and hints at server behavior, but lacks details on prerequisites, error cases, or output format. Given the mutation nature (creation) and sibling tools, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('filePaths' as array of absolute paths, 'layout' with enum values). The description adds minimal value beyond the schema by implying file fetching occurs, but doesn't explain parameter interactions or constraints (e.g., how layout affects node arrangement). Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 code nodes') and resource ('from file paths'), with additional context about EServer fetching files and setting up sync. However, it doesn't explicitly differentiate from sibling 'code.create' (single node creation) or 'code.createBatchGrouped' (grouped batch creation), 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?
No guidance is provided about when to use this tool versus alternatives like 'code.create' (single node) or 'code.createBatchGrouped' (grouped batch). The description mentions EServer behavior but doesn't help the agent choose between similar batch creation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Set the Designer mode' but doesn't disclose behavioral traits such as whether this is a mutating operation, if it requires specific permissions, what happens on success/failure, or side effects. For a tool that likely changes system state, 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 front-loaded with the core purpose in the first sentence, followed by a bulleted list that efficiently details mode options. Every sentence earns its place, with no redundant or verbose language, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mode-setting tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral outcomes, error conditions, or how this tool integrates with the broader designer context (e.g., sibling tools). For a state-changing operation, 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 input schema has 100% description coverage, with the 'mode' parameter fully documented via enum and description. The description adds minimal value by listing the enum values in bullet points, but doesn't provide additional context like default behaviors or implications of each mode beyond what's in the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('Designer mode'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'designer.getMode' or 'designer.getActive', which are related but distinct operations. The description is specific but lacks sibling 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 lists mode options but doesn't explain scenarios for choosing one mode over another, prerequisites, or interactions with other tools like 'designer.getMode'. This leaves 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. It states it 'Get[s] all documents' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires permissions, how results are returned (e.g., pagination, format), or potential rate limits. 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 front-loads the core action ('Get all documents of a specific type') and includes helpful examples in parentheses. There's no wasted verbiage, 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'Get all documents' entails in terms of return values, format, or limitations. For a tool with no structured output information, this leaves significant gaps for an agent to understand 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?
The input schema has 100% description coverage, with the parameter 'type' documented as 'Document type to filter by'. The description adds examples of types (e.g., 'workflow', 'spreadsheet'), which provides additional context beyond the schema. This meets the baseline of 3 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 verb ('Get') and resource ('documents'), specifying it filters by type. It provides examples of document types, making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'documents.list' or 'documents.getRecent', which is why it's not 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 lacks explicit guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'documents.list' (which might list all documents without filtering) or 'documents.getRecent', leaving the agent to infer usage based on the need for type filtering 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 what the tool does ('connect two nodes') but doesn't describe what happens after connection, whether this is a mutating operation, if it requires specific permissions, or what error conditions might occur. For a tool that likely modifies graph structure, this is insufficient 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, efficient sentence that states the core functionality without unnecessary words. It's perfectly front-loaded with the essential information, making it easy for an agent to parse quickly. Every word earns its place in this minimal 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?
For a tool that creates connections between nodes (likely modifying graph structure), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, an agent lacks crucial information about what the tool returns, what side effects occur, or how to handle errors. The description does the bare minimum for a creation/mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all 5 parameters. The baseline score of 3 reflects adequate schema documentation, though the description doesn't provide additional context about parameter relationships or edge cases.
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 ('connect') and resources ('two nodes with an edge'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'edges.delete' or 'edges.deleteBetween', but the verb 'connect' is specific enough to distinguish it from deletion 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. There are no mentions of prerequisites, constraints, or comparisons to similar tools like 'circuitry.connect' or 'nodes.addConnected' from the sibling list. The agent must infer usage context entirely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Delete' implies a destructive operation, the description doesn't specify whether this deletion is permanent, reversible, requires specific permissions, affects connected resources, or what happens upon success/failure. This is inadequate for a destructive 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 maximally concise - a single sentence with zero wasted words. It's front-loaded with the essential information and contains 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 deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes an 'edge' in this context, what happens after deletion, whether there are confirmation requirements, or what the response looks like. The minimal description leaves too many behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'edgeId' clearly documented as 'Edge ID to delete'. The description adds no additional parameter information beyond what's already in the schema, which is acceptable given the 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 ('Delete') and resource ('an edge by ID'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling deletion tools like 'edges.deleteBetween', 'nodes.delete', 'layout.delete', etc., which all perform deletion operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this specific deletion tool versus alternatives like 'edges.deleteBetween' or 'nodes.delete'. There's no mention of prerequisites, constraints, or appropriate contexts for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes edges, indicating a destructive operation, but lacks details on permissions, error handling, confirmation prompts, or what happens if no edges exist between the nodes. This is 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—two sentences that directly state the tool's function and a comparative advantage. Every word serves a purpose, with no wasted information, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a destructive operation with no annotations and no output schema, the description is incomplete. It fails to address critical aspects like return values, error conditions, or side effects, which are essential for safe and effective use in an AI agent 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 ('sourceId' and 'targetId') clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, 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 ('Delete all edges between two nodes') and specifies the resource ('edges'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'edges.delete' or 'edges.connect', 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 minimal guidance by mentioning it's 'more intuitive than needing edge IDs', which implies an alternative approach but doesn't explicitly state when to use this tool over 'edges.delete' or other edge-related tools. No clear when/when-not instructions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get current execution status' implies a read-only operation, but doesn't disclose what 'current' means (e.g., latest execution, active execution), whether it requires specific permissions, what format the status returns, or if there are rate limits. 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 with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information. Every word earns its place in conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and operates in a domain with multiple execution-related tools, the description is insufficient. It doesn't explain what 'execution status' encompasses, what values might be returned, or how this differs from other execution tools. For a tool in this complex ecosystem, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't add parameter information beyond what's in the schema, which is correct for a parameterless tool. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current execution status' clearly states the action (get) and resource (execution status), but it's vague about what 'execution status' means in this context. It doesn't distinguish from sibling tools like 'execution.start' or 'execution.stop', leaving ambiguity about whether this refers to a specific execution or a general system status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With siblings like 'execution.start' and 'execution.stop', the description doesn't indicate if this should be used before/after those operations, or if it's for monitoring ongoing executions. The agent receives no contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 starting execution but fails to describe what happens after initiation (e.g., whether it runs asynchronously, returns an execution ID, or handles errors). For a tool that likely triggers significant system activity, this lack of detail about runtime behavior is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality without any fluff. It's front-loaded with the main action and includes the optional starting point, 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 tool that initiates workflow execution with no output schema and no annotations, the description is incomplete. It doesn't explain what the tool returns (e.g., execution status, ID, or error details), nor does it cover behavioral aspects like side effects or error handling, leaving significant gaps for an AI agent to understand its full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for any gaps since there are none in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start workflow execution') and specifies the resource ('from a specific node or the start node'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'execution.getStatus' or 'execution.stop', but the verb 'Start' is sufficiently distinct from 'get' or 'stop' 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 'codebook.runAll' or 'codebook.runCell', nor does it mention prerequisites or typical use cases. It simply states what the tool does without contextualizing its application within the broader toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 implies a write operation ('save') but doesn't disclose permissions needed, whether it overwrites existing files, error conditions, or what 'save' entails (e.g., format, location). 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, clear sentence with no wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every word earns its place without redundancy or fluff.
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 performs a write operation ('save') with no annotations and no output schema, the description is insufficient. It lacks details on behavior, side effects, success/error responses, and how it interacts with the system (e.g., what constitutes 'current workflow'). Given the complexity implied by sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'path' documented as 'File path (optional for already-saved workflows)'. The description doesn't add param details beyond the schema, but with 0 required parameters and high schema coverage, the baseline is strong. It loses a point for not clarifying 'already-saved workflows' context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save the current workflow' clearly states the action (save) and target (current workflow), avoiding tautology. However, it doesn't specify what 'current workflow' means in this context or differentiate from sibling tools like 'file.export' or 'workflow.getActive', leaving room for ambiguity about scope and uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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., whether a workflow must be open), exclusions, or comparisons to similar tools like 'file.export' or saving mechanisms in other contexts, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify whether this operation is reversible, requires specific permissions, or has side effects (e.g., cascading deletions). It also doesn't describe the return value or error conditions, leaving 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, direct sentence with zero wasted words. It's front-loaded with the core action ('Delete a layout element'), making it immediately scannable and efficient. Every word earns its place, achieving optimal conciseness for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context: what happens after deletion (success/failure indicators), whether it's idempotent, permission requirements, or how it interacts with other layout tools. The high schema coverage doesn't compensate for these behavioral and contextual omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter 'layoutId' documented as 'Layout ID or name'. The description adds no additional parameter semantics beyond what's in the schema. Since the schema fully describes the single parameter, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given complete 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 ('Delete') and resource ('a layout element'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'layout.create', 'layout.update', and 'layout.get' by focusing on removal. However, it doesn't specify what constitutes a 'layout element' beyond the parameter name, 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the layout must exist), consequences (e.g., if deletion is permanent), or relationships with sibling tools like 'layout.create' or 'layout.update'. 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 searches but doesn't describe what 'search' entails - whether it's fuzzy/exact matching, case-sensitivity, performance characteristics, pagination, or what happens when no results are found. For a search 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 with zero wasted words. It's appropriately sized for a search 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 search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes a 'layout element', what the search returns (list of IDs, full objects, metadata), or how results are structured. The combination of missing behavioral context and no output information creates 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 already fully documents all three parameters. The description mentions searching 'by name or type' which aligns with the 'query' and 'type' parameters, but adds no additional semantic context beyond what's in the schema. 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 tool's purpose with a specific verb ('Search') and resource ('layout elements'), and specifies search criteria ('by name or type'). It doesn't explicitly differentiate from sibling tools like 'layout.list' or 'nodes.search', but the focus on layout elements provides some implicit 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 'layout.list' or 'nodes.search'. It mentions search criteria but doesn't explain when searching is preferable to listing or filtering through other means. 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. While 'Set' implies a mutation operation, the description doesn't address important behavioral aspects: what permissions are required, whether changes are reversible, if there are rate limits, what happens to existing style properties not mentioned, or what the response looks like. For a 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 gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear parameters documented in the schema.
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 setting cell styles, whether there are side effects, what permissions are needed, or how this differs from similar styling tools. 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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'style properties' but the schema already describes this with examples. 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 ('Set style properties') and target ('on a specific grid cell'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'layout.setStyle' or 'layout.setCellContent', which appear to be related styling 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. With multiple layout-related tools available (layout.setStyle, layout.setCellContent, layout.getCell), there's no indication of when this specific cell styling operation is appropriate versus broader styling operations or content setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "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's an update operation. It doesn't disclose whether this requires specific permissions, if changes are reversible, what happens to unspecified fields, or any rate limits. 'Update' implies mutation but lacks behavioral details needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('Update a layout element') and enumerates the updatable fields. Every word serves a purpose 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the update returns, error conditions, or behavioral implications. Given the complexity (4 parameters including nested objects) and lack of structured safety hints, more context is needed for reliable 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 fully documents all 4 parameters. The description adds marginal value by listing the updatable fields (name, position, dimensions, style), which aligns with schema properties, but doesn't provide additional syntax, format, or constraints beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a layout element'), and specifies the fields that can be updated (name, position, dimensions, style). It distinguishes this from layout.create and layout.delete among siblings, though not explicitly from layout.setCellContent or layout.setCellStyle which are more specific updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 layout.setCellContent or layout.setCellStyle for partial updates, or layout.create for new elements. The description implies it's for updating existing layouts but doesn't specify prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Add a new node' implies a write/mutation operation, but there's no information about permissions needed, side effects, error conditions, or what happens upon success. The description lacks crucial behavioral context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any fluff. It's perfectly front-loaded and every word earns its place, 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 node creation, what the return value might be, error conditions, or how this integrates with the broader workflow system. The agent lacks crucial context 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?
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. 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 ('Add') and resource ('a new node to the workflow'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'nodes.addConnected' or 'nodes.insertBetween', but the verb 'Add' is specific enough to convey basic intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'nodes.addConnected' or 'nodes.insertBetween'. There's no mention of prerequisites, context requirements, or comparison with sibling tools, leaving the agent to infer usage patterns independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Create a new node' implies a write/mutation operation, the description doesn't address important behavioral aspects: whether this requires specific permissions, what happens if the source node doesn't exist, whether connections are bidirectional, what the return value contains, or error conditions. For a creation/connection tool 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, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for the tool's purpose and front-loads the essential information. Every word earns its place in this concise formulation.
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 and connects nodes (a mutation operation) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, side effects, or how it differs from similar tools. Given the complexity of node/edge operations in this system and the rich sibling toolset, more contextual information would be valuable 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 description mentions creating a node and connecting it to an existing node, which aligns with 'sourceNodeId' and implies 'type'/'name'/'config' parameters for the new node. However, with 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond what's in the schema, 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 ('Create a new node and connect it') and the resource ('to an existing node'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'nodes.add' or 'nodes.insertBetween', which likely have overlapping functionality in node creation/connection contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'nodes.add' (which might create nodes without connections) or 'edges.connect' (which might connect existing nodes). There's no mention of prerequisites, use cases, or exclusions that would help an agent choose appropriately among the many node/edge-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive mutation, the description doesn't disclose whether deletion is permanent/reversible, what happens to connected edges, whether permissions are required, or what the response looks like. 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, clear sentence with zero wasted words. It's appropriately sized for a simple operation 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 destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'delete' entails in this context, what happens to workflow structure, whether there are confirmation steps, or what the tool returns. Given the complexity of workflow systems and the lack of structured safety information, more behavioral 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 already documents the single 'nodeId' parameter. The description doesn't add any additional context about parameter meaning, format, or constraints beyond what the schema provides. The baseline of 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a node from the workflow'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'nodes.delete' vs 'nodes.add' or 'edges.delete', but the verb+resource combination is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 like 'nodes.add', 'nodes.update', 'edges.delete', and 'layout.delete', there's no indication of prerequisites, consequences, or appropriate contexts for node deletion versus other deletion 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 the tool retrieves a node by ID but doesn't describe what happens if the ID is invalid (e.g., error handling), whether it's a read-only operation, permissions required, or the format of the returned node data. For a retrieval 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, clear sentence that front-loads the essential information ('Get a specific node by its ID'). There is no wasted verbiage or redundancy, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what a 'node' is in this context (e.g., part of a workflow, document, or other structure), what data is returned, or error conditions. For a tool with 1 parameter but no structured output information, more context is needed to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by its ID', which aligns with the single parameter 'nodeId' in the schema. Since schema description coverage is 100% (the schema fully documents 'nodeId' as 'The unique ID of the node'), the description adds minimal value beyond what the schema provides. This meets the baseline of 3 for high schema coverage, but it doesn't elaborate on ID format 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 ('Get') and resource ('a specific node'), making the purpose immediately understandable. It distinguishes from siblings like 'nodes.list' or 'nodes.search' by specifying retrieval by ID rather than listing or searching. However, it doesn't explicitly contrast with 'nodes.getByName' or 'nodes.getByType', which are similar retrieval methods but by different criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'nodes.get' over 'nodes.getByName', 'nodes.getByType', 'nodes.list', or 'nodes.search', nor does it specify prerequisites like needing a valid node ID. The agent must infer usage from the name and 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 full burden for behavioral disclosure. It states the tool 'finds' a node, implying a read operation, but doesn't specify what happens if multiple nodes share the same display name, whether it returns partial matches, or what format the result takes. 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 communicates the core functionality without any wasted words. It's perfectly front-loaded with the essential information and contains 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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'finding' entails operationally, what format results take, or how to handle edge cases like non-existent names. Given the context of many sibling tools and the lack of structured behavioral information, more guidance 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 schema has 100% description coverage, with the single parameter 'name' clearly documented as 'The display name of the node'. The description adds no additional parameter information beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and target resource ('a node by its display name'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'nodes.get' or 'nodes.search', but the focus on display name provides some 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 'nodes.get', 'nodes.search', or 'nodes.getByType'. It simply states what the tool does without context about appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Delete' implies a destructive mutation, but doesn't specify if deletion is permanent, requires permissions, affects related data, or what happens on success/failure. For a destructive tool, this lack of detail 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 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?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address critical aspects like return values, error conditions, or behavioral nuances (e.g., confirmation prompts). For a deletion tool, more context 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 input schema has 100% description coverage, with 'screenId' documented as 'Screen ID or name'. The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, 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 the resource ('a screen from the Designer'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'screen.list' or 'screen.update', which would require more specificity about what distinguishes deletion from other screen 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing screen), consequences (e.g., irreversibility), or related tools like 'screen.create' or 'screen.duplicate' for context. The description stands alone 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. It mentions duplication behavior but lacks critical details: whether this is a read-only or destructive operation, permission requirements, rate limits, or what happens to the original screen. For a mutation tool 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, efficient sentence that states the action and scope without unnecessary 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or return values, which are crucial for an agent to use it correctly in a complex environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('screenId' and 'newName'). The description doesn't add any additional meaning beyond implying duplication involves layouts and components, which is inherent in the tool's purpose. 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 ('duplicate') and resource ('a screen with all its layouts and HTML components'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'screen.create' or 'screen.capture', 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 siblings like 'screen.create' and 'screen.capture' available, there's no indication of prerequisites, use cases, or exclusions, leaving the agent to guess based on 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 makes a screen 'active for editing,' implying a state change, but doesn't clarify if this is a read-only operation, requires permissions, affects other screens, or has side effects like UI updates. 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 conveys 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 the tool's complexity (state-changing operation with no output schema) and lack of annotations, the description is insufficient. It doesn't explain what 'active for editing' entails, potential errors, or return values, leaving the agent with incomplete information 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 input schema has 100% description coverage, with 'screenId' documented as 'Screen ID or name.' The description adds no additional parameter details beyond this, so it meets the baseline score of 3 where the schema handles the heavy lifting 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 ('Select a screen') and the outcome ('to make it active for editing'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'screen.get' or 'screen.list', 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 screen), exclusions, or comparisons to other screen-related tools like 'screen.get' or 'screen.update', leaving the agent with minimal 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 'Update' which implies a mutation operation, but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, error handling (e.g., invalid screenId), or side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose. It wastes no words but could be slightly more structured by including key usage notes. Every word earns its place, making it appropriately concise for a simple update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., permissions, side effects), response format, or error conditions. For a tool that modifies resources, this leaves significant gaps for an AI agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters (screenId, name, dimensions, backgroundColor) with descriptions. The description lists the updatable fields (name, dimensions, backgroundColor), which adds minimal value beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting, though the description doesn't compensate with additional semantics like format examples for dimensions or backgroundColor.
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 ('screen properties') with specific fields mentioned (name, dimensions, backgroundColor). It distinguishes from siblings like screen.create, screen.delete, and screen.get by specifying it's for updating existing screens. However, it doesn't explicitly differentiate from screen.duplicate or screen.select, which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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., screen must exist), when not to use it (e.g., for creating new screens), or refer to sibling tools like screen.create for creation or screen.get for retrieval. Usage is implied through the word 'Update' but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address important behavioral aspects like whether this requires specific permissions, what happens if a sheet with the same name exists, whether the creation is reversible, 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 extremely concise (one sentence) and front-loaded with the essential information. Every word earns its place, with no redundant or unnecessary 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 creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, what gets returned, error conditions, or how this tool relates to the broader ecosystem of sheet and spreadsheet tools. The context signals show complexity (4 parameters, nested objects), but the description doesn't provide adequate guidance for proper 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 four parameters thoroughly. The description mentions 'with data' which hints at the data parameter, but adds minimal semantic value beyond what the schema provides. 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') and resource ('new Sheet (spreadsheet) node with data'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'spreadsheet.create' or 'nodes.create', which could create 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. With many sibling tools available (including spreadsheet.create, nodes.create, and other sheet.* tools), there's no indication of when this specific sheet creation method is appropriate versus other creation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, requires specific permissions, affects dependent data (e.g., formulas or charts), or has side effects like shifting other columns. It also omits error conditions (e.g., invalid column index) and response format, leaving significant behavioral 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, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key verb 'Delete' and avoids redundancy or fluff. Every word earns its place, 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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as the effect on the sheet (e.g., data loss, column shifting), error handling, permissions required, or whether the action is undoable. The absence of output schema means the description should ideally hint at return values or success indicators, but it does not. Given the complexity of a delete operation, more behavioral and contextual details are 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 clear documentation of 'nodeId' as 'Sheet node ID or name' and 'colIndex' as 'Column to delete (0-indexed)'. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints (e.g., column must exist). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have enhanced understanding with practical usage notes.
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 column at a specific position'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'sheet.deleteRow', but the specificity of 'column' versus 'row' provides implicit distinction. The description avoids tautology by not merely restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'sheet.deleteRow' or 'sheet.insertColumn'. It lacks context about prerequisites (e.g., whether the sheet must exist or be editable) or exclusions (e.g., cannot delete all columns). There's no mention of related tools or typical workflows, leaving usage entirely to inference from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 destructive action ('Delete') but doesn't mention whether this operation is reversible, what permissions are required, or how it affects spreadsheet structure. The description lacks critical context about consequences like shifting remaining rows or potential data loss, which is essential 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 communicates the core functionality without unnecessary words. It's front-loaded with the essential action and immediately specifies the target resource. Every word earns its place, making it maximally concise while still being clear.
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 insufficient. It doesn't address what the tool returns, error conditions, or the broader impact on the spreadsheet. Given the complexity of row deletion in a spreadsheet context, more information about behavioral consequences and expected outcomes is needed for proper agent 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 description mentions 'specific position' which aligns with the rowIndex parameter, but adds no additional semantic context beyond what's already in the schema descriptions. With 100% schema description coverage, the baseline is 3. The description doesn't explain parameter relationships or provide usage examples that would enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a row at a specific position'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'sheet.deleteColumn' or 'nodes.delete', but the specificity of 'row' provides implicit distinction. The description avoids tautology by not just repeating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'sheet.deleteColumn' or 'sheet.updateRow'. It mentions the specific position requirement but doesn't clarify prerequisites, error conditions, or what happens to adjacent rows after deletion. There's no explicit 'when-not' or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what data is returned without behavioral details. It lacks information on permissions needed, error conditions, rate limits, or whether this is a read-only operation (implied by 'Get' but not explicit). This is inadequate for a tool with potential complexity in accessing spreadsheet data.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves detailed cell data. It doesn't explain the return format, potential nested structures, or error handling, leaving significant gaps for an AI agent to invoke it correctly in complex spreadsheet contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 three parameters (nodeId, row, col). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it 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 ('Get') and resource ('detailed cell info') with specific attributes ('including formula and computed value'). It distinguishes from basic sibling tools like 'sheet.getCell' by specifying the additional data returned, though it doesn't explicitly contrast with 'sheet.getCellFormula' which might overlap partially.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'sheet.getCell' or 'sheet.getCellFormula'. The description implies it returns more comprehensive data but doesn't specify scenarios where this is preferred or any prerequisites 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 the full burden of behavioral disclosure. It states the action ('Insert') but doesn't explain what this entails—whether it shifts existing columns, requires specific permissions, affects formulas, or has side effects. For a mutation tool with zero annotation coverage, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('Insert a column') and specifies the key detail ('at a specific position'). There is no wasted language, 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 the tool's complexity (a mutation operation with 4 parameters) and the absence of both annotations and an output schema, the description is incomplete. It doesn't cover behavioral aspects like effects on the sheet, error conditions, or return values, leaving significant gaps for a tool that modifies data.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 (nodeId, colIndex, data, header). The description implies a 'position' parameter but doesn't add meaning beyond what the schema provides, such as explaining how 'colIndex' interacts with existing columns or what 'data' format is expected. 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 ('Insert a column') and specifies the location ('at a specific position'), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'sheet.insertRow' or 'sheet.deleteColumn', which would require mentioning it's for columns specifically versus rows or deletion 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. It doesn't mention prerequisites (e.g., needing an existing sheet), exclusions, or compare it to similar tools like 'sheet.insertRow' or 'sheet.setData'. Without such context, users 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?
No annotations are provided, so the description carries full burden. It states the action ('Insert') implying a write/mutation, but doesn't disclose behavioral traits like whether it requires specific permissions, if it shifts existing rows down, what happens on invalid inputs (e.g., out-of-bounds rowIndex), or error responses. 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: 'Insert a row at a specific position.' It's front-loaded with the core action and resource, making it easy to parse. 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 the tool's complexity (a mutation with 3 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., side effects, error handling), usage context, or return values. For a write operation in a sheet context, 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%, with clear descriptions for nodeId, rowIndex, and data. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of data format or rowIndex constraints). With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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 ('Insert') and resource ('a row'), specifying it occurs 'at a specific position.' It distinguishes from siblings like sheet.updateRow (which modifies existing rows) and sheet.deleteRow (which removes rows). However, it doesn't explicitly differentiate from sheet.insertColumn, which is a similar insertion operation but for columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 (e.g., sheet must exist), exclusions (e.g., invalid rowIndex values), or comparisons to siblings like sheet.updateRow for modifying rows or sheet.setData for bulk updates. The agent must infer usage from the name and schema 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 mentions the ability to set formulas, which is useful context, but fails to describe important behavioral aspects: whether this is a write operation (implied but not stated), what permissions are required, whether it overwrites existing content, what happens with invalid coordinates, or what the tool returns. For a 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 perfectly concise - two brief sentences with zero wasted words. The first sentence states the core purpose, the second adds important capability information. Every word earns its place, and the structure is front-loaded with the most critical 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 address key contextual questions: what happens on success/failure, what permissions are needed, how it interacts with other sheet operations, or what the return value looks like. The sibling tools list shows many related sheet operations, but the description provides no guidance on when to choose this specific 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 four parameters thoroughly. The description adds minimal value beyond the schema by mentioning formula support ('Can also set formulas (start with =)'), which slightly elaborates on the 'value' parameter. This meets the baseline expectation 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 ('Set a single cell value') and resource ('in a Sheet'), making the purpose immediately understandable. It distinguishes from siblings like sheet.setCells (multiple cells) and sheet.setCellFormula (formula-specific), though not explicitly named. However, it doesn't fully differentiate from spreadsheet.setCell which appears to be a similar tool in a different 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 sheet.setCells (for multiple cells), sheet.setCellFormula (for formulas only), or spreadsheet.setCell (apparently similar). There's no mention of prerequisites, error conditions, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 sets a formula, implying a write/mutation operation, but doesn't disclose behavioral traits such as permissions needed, whether it overwrites existing content, error handling for invalid formulas, or side effects. The formula format constraint is useful 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 two short sentences with zero waste, front-loading the core action and following with a critical constraint. 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on what happens after setting the formula (e.g., does it return success/failure, update the sheet immediately?), error conditions, permissions, or how it interacts with sibling tools. The formula constraint is helpful but doesn't compensate for the broader gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters (nodeId, row, col, formula) with descriptions. The description adds minimal value beyond the schema by emphasizing the formula format ('must start with ='), but doesn't provide additional context like examples beyond the schema's 'e.g., "=SUM(A1:A10)"'. 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 ('Set a formula') and the resource ('for a cell'), with a specific constraint ('Formulas must start with ='). It distinguishes from siblings like 'sheet.setCell' (which likely sets values) and 'sheet.getCellFormula', but doesn't explicitly contrast them. The purpose is clear 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 on when to use this tool versus alternatives like 'sheet.setCell' or 'sheet.setCells' is provided. The description mentions the formula format constraint, but doesn't indicate prerequisites, error conditions, or typical use cases. Usage is implied by the action but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Replace all data' implies a destructive write operation, but it doesn't specify whether this operation is reversible, what permissions are required, whether it clears formatting or formulas, or what happens to existing data. For a tool that completely replaces sheet content, this is inadequate 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 maximally concise at just four words. It's front-loaded with the core action and resource, with zero wasted words. This is an excellent example of efficient communication.
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 write operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'replace all data' entails operationally, what the tool returns, whether headers are optional or required, or how the data array should be structured. Given the complexity of completely replacing sheet content, 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 already documents all three parameters (nodeId, data, headers). The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate but minimal value addition 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 'Replace all data in a Sheet' clearly states the action (replace) and resource (Sheet data), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like sheet.setCell or sheet.setCells, but the 'all data' scope provides some implicit distinction from more targeted 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. There are multiple sibling tools for modifying sheet data (sheet.setCell, sheet.setCells, sheet.fillRange, spreadsheet.setData), but the description doesn't indicate when this bulk replacement operation is appropriate versus more targeted updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Replace an entire row' implies a destructive mutation, but it doesn't specify whether this operation is reversible, what permissions are required, how it handles existing data, or what happens if the row doesn't exist. For a 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, clear sentence that efficiently communicates the core functionality without any unnecessary words. It's perfectly front-loaded and wastes no space on 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 insufficient. It doesn't explain what happens to the replaced data, whether the operation is atomic, what error conditions might occur, or what the tool returns. Given the complexity of row replacement in a sheet context, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters clearly documented in the input schema. The description doesn't add any additional semantic information about the parameters beyond what's already in the schema (nodeId, rowIndex, data). 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 ('Replace') and resource ('an entire row at a specific position'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sheet.setCell' or 'sheet.setCells', which might also update sheet data but at different granularities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 sheet manipulation (e.g., sheet.setCell, sheet.setCells, sheet.fillRange), there's no indication of whether this is for bulk updates, specific use cases, or how it differs from other update methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Add a new sheet' implies a write/mutation operation, the description doesn't disclose important behavioral traits: whether this requires specific permissions, what happens if a sheet with the same name exists, whether the operation is reversible, or what the response looks like. 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 extremely concise - a single sentence that directly states the tool's purpose with zero wasted words. It's front-loaded with the core functionality and appropriately sized for what it communicates.
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 explain what happens after sheet creation, what errors might occur, or provide any context about the spreadsheet ecosystem. With rich sibling tools and complex operations possible, more guidance is needed for proper tool selection and 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 fully documents both parameters (documentId and name). The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what 'standalone spreadsheet' means in relation to the documentId parameter, or provide context about sheet naming conventions. 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 ('Add a new sheet') and target resource ('to a standalone spreadsheet'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'sheet.create' or 'spreadsheet.create', which might create confusion about the exact scope or relationship between these tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple spreadsheet and sheet-related tools in the sibling list (spreadsheet.create, spreadsheet.deleteSheet, spreadsheet.listSheets, sheet.create, etc.), there's no indication of when this specific 'addSheet' operation is appropriate versus other creation or management 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 creates a 'standalone' document, implying it's a new root object, but doesn't describe where it's created (e.g., in current workspace), whether it requires permissions, what happens on success/failure, or if it returns an identifier. For a creation 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 front-loads the core purpose ('Create a new standalone spreadsheet document') and adds only necessary qualification ('with optional initial data'). Every word earns its place with zero redundancy or fluff.
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 incomplete. It doesn't explain what happens after creation (e.g., does it return an ID, become the active document, appear in documents.list?), nor does it cover error conditions or permissions. Given the complexity of document creation in this ecosystem, 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 already documents all three parameters (name, initialData, initialSheetName). The description adds minimal value by mentioning 'optional initial data' which aligns with the schema's optional 'initialData' parameter. It doesn't provide additional context about parameter interactions, defaults, or constraints beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new standalone spreadsheet document'), making the purpose immediately understandable. It distinguishes from sibling tools like 'spreadsheet.addSheet' (which adds to existing documents) and 'sheet.create' (which creates sheets within documents). However, it doesn't explicitly contrast with these alternatives, keeping it from 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 'sheet.create' or 'spreadsheet.addSheet'. It mentions 'optional initial data' but doesn't explain when this is beneficial or what happens if omitted. No prerequisites, dependencies, or typical use cases are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 performs a rename operation, implying mutation, but doesn't disclose behavioral traits like permission requirements, whether the rename is reversible, error conditions (e.g., duplicate names), or what happens on success/failure. For a 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 action. There's zero wasted verbiage—it directly states what the tool does without unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context like what the tool returns (e.g., success confirmation, error details), side effects, or dependencies. The description alone doesn't provide enough information 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%, with all parameters documented in the schema. The description adds no parameter-specific information beyond what the schema provides (e.g., format constraints for 'newName', how 'index' maps to sheets). 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 ('Rename') and resource ('a sheet in a standalone spreadsheet'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'spreadsheet.addSheet' or 'spreadsheet.deleteSheet', but the verb 'rename' is specific enough to imply a different 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 prerequisites (e.g., having an open spreadsheet), exclusions (e.g., cannot rename the active sheet), or related tools like 'spreadsheet.listSheets' for identifying sheets first. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Set a formula' implies a write/mutation operation, the description doesn't address important behavioral aspects like whether this requires specific permissions, what happens if the cell already has content, whether formulas are validated, or what the typical response looks like. 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 gets straight to the point with zero wasted words. It's appropriately sized for a tool with good schema documentation and front-loads the essential information about what the tool does.
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 address behavioral implications, error conditions, or what happens after the formula is set. Given the complexity of spreadsheet operations and the lack of structured safety/behavioral information, the description should provide more context about the tool's effects and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 5 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'cell' and 'spreadsheet' which map to row/col and documentId parameters, but provides no additional context about parameter usage, relationships, 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 ('Set a formula') and target ('for a cell in a standalone spreadsheet'), providing specific verb+resource information. However, it doesn't explicitly differentiate from sibling tools like 'sheet.setCellFormula' or 'spreadsheet.setCell', which appear to have similar functions but potentially different scopes (sheet vs. spreadsheet).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 sibling tools that appear related (e.g., 'sheet.setCellFormula', 'spreadsheet.setCell', 'spreadsheet.setData'), there's no indication of when this specific tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Set' operation (implying mutation/write), but provides no information about permissions required, whether data overwrites existing content, error conditions, or what happens with the optional parameters when not provided. 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 with zero wasted 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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'Set data' means operationally (overwrite? append?), doesn't address error conditions or permissions, and provides no context about the sibling tools that appear to serve similar functions. The agent would struggle to use this tool correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. The description adds no additional parameter information beyond what's already in the schema (documentId is optional and uses active, data is a 2D array, sheetIndex is optional and uses active sheet). 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 ('Set data') and target ('in a sheet of a standalone spreadsheet'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'sheet.setData' or 'spreadsheet.setCell', which appear to serve similar spreadsheet data manipulation purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are multiple sibling tools for spreadsheet data manipulation (sheet.setData, spreadsheet.setCell, sheet.setCells, etc.), but no indication of which scenarios call for this specific tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a 'Get' operation, implying read-only behavior, but doesn't specify if it requires permissions, what happens on errors, or the format of returned content beyond 'markdown'. This leaves 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, 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 lack of annotations and output schema, the description is incomplete for a tool that retrieves content. It doesn't explain what the return value looks like (e.g., markdown string, error handling), which is crucial for an agent to use it effectively. This is a significant gap for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the 'nodeId' parameter as 'Text node ID or name'. The description doesn't add any extra meaning beyond this, such as examples or constraints, which aligns with the baseline score of 3 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 ('Get') and resource ('markdown content from a Text node'), making the purpose understandable. However, it doesn't differentiate from potential siblings like 'text.create' or 'text.setContent' beyond the 'get' verb, which is why it doesn't reach 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. While the description implies it's for retrieving content, it doesn't mention prerequisites, context, or comparisons to other tools like 'text.setContent' or 'nodes.get' that might handle similar data.
Agents often have multiple tools that could apply. Explicit usage guidance like "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) and mentions supported formats, but lacks critical details like required permissions, whether changes are reversible, error conditions, or what happens to existing content. For a mutation tool 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences that efficiently convey the core functionality. It's front-loaded with the primary action and adds useful format information 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 no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error handling, or response format. While it covers the basic purpose and parameters, it lacks sufficient context for safe and effective use by 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 already documents both parameters ('nodeId' and 'content') adequately. The description adds minimal value beyond the schema by implying 'content' accepts markdown/LaTeX, but doesn't provide additional syntax or format details. 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 markdown content') and target ('in a Text node'), with specific format support mentioned ('Supports markdown and LaTeX'). It distinguishes from sibling 'text.getContent' by being a write operation, though it doesn't explicitly differentiate from other text-related tools like 'text.create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing an existing Text node), when not to use it, or direct comparisons to siblings like 'text.create' or 'text.getContent'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Execute all cells' implies a write/mutation operation, but it doesn't disclose whether this is destructive, requires specific permissions, has rate limits, or what happens on completion (e.g., output generation, state changes). The description adds only the 'in order' constraint, leaving critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Execute all cells') and includes only essential qualifiers ('in CodeBook', 'in order'). Every element earns its place, 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 tool's complexity (executing all cells likely involves significant side effects), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'execute' entails (e.g., running code, generating outputs), what happens if cells fail, or what the agent should expect after invocation. For a potentially high-impact tool, this leaves too many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description appropriately doesn't discuss parameters since none exist. It earns a high score for not adding unnecessary parameter information, though a perfect 5 would require explicitly stating 'no parameters required' to eliminate ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute all cells') and target resource ('in CodeBook'), with the qualifier 'in order' providing important sequencing context. It distinguishes from sibling tools like codebook.runCell (single cell) and codebook.getState (read-only), though not explicitly. However, it doesn't specify what 'CodeBook' refers to in this context, keeping it from 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., whether a CodeBook must be open), compare with codebook.runCell for selective execution, or warn about potential side effects of running all cells. The agent must infer usage from the tool name and sibling 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?
No annotations are provided, so the description carries full burden. It states the action ('clear') and fallback behavior, but lacks details on permissions needed, side effects (e.g., whether this affects other operations), error conditions, or what 'clear' entails (e.g., resets to null, default, or recent). For a mutation tool 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, efficient sentence that front-loads the core action ('Clear the explicit target document') and adds necessary context ('falling back to most recently focused primary document') without waste. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool ('clear'), the description is incomplete. It lacks information on what happens after clearing (e.g., return value, state changes), error handling, or dependencies. For a tool that modifies state, more behavioral context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clear') and the resource ('explicit target document'), with a specific fallback behavior ('falling back to most recently focused primary document'). It distinguishes from sibling 'documents.setTarget' by indicating this clears rather than sets, but doesn't explicitly contrast with other document tools like 'documents.getTarget' or 'documents.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?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage when clearing a target document is needed, but doesn't specify scenarios, prerequisites, or contrast with sibling tools like 'documents.setTarget' for setting a target or 'documents.getTarget' for retrieving 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 for behavioral disclosure. 'Stop the current workflow execution' implies a destructive/mutating operation, but doesn't specify whether this is reversible, what happens to in-progress work, whether confirmation is needed, or what the expected outcome looks like. For a potentially destructive 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 communicates the core functionality without any wasted words. It's front-loaded with the essential information and achieves maximum clarity with minimal verbiage.
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 potentially destructive execution control tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'stop' means operationally, what state the workflow enters after stopping, whether data is preserved, or what happens if there's no current execution. The context demands more behavioral detail than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, which is correct. A baseline of 4 is appropriate for zero-parameter tools when the 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 ('Stop') and the target ('the current workflow execution'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'execution.getStatus' or 'workflow.undo' that might also affect execution state, 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 about when to use this tool versus alternatives. With sibling tools like 'execution.start', 'execution.getStatus', and various workflow control tools (undo/redo), there's no indication of appropriate contexts, prerequisites, or exclusions for using this stop function.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Export' implies a read operation that outputs data, but it doesn't specify what 'workflow' refers to (current active workflow? selected workflow?), whether it requires permissions, what the JSON structure contains, or if it's destructive to any state. This leaves significant gaps for a tool with mutation-like implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 action and resource, making it immediately understandable. 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 complexity of exporting a workflow (which could involve structured data) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what 'workflow' means in context, what the JSON output contains, or any behavioral aspects. For a data export tool with no structured output documentation, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no required inputs for a simple export operation. A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export workflow to JSON' clearly states the verb ('Export') and resource ('workflow'), specifying the output format ('JSON'). It distinguishes from siblings like 'file.save' by focusing on export rather than general saving. However, it doesn't explicitly differentiate from other potential export tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 active workflow), exclusions, or comparisons to sibling tools like 'workflow.getStructure' that might retrieve workflow data differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Get' operation, implying read-only behavior, but doesn't specify if it requires permissions, returns errors for invalid IDs/names, or details the return format. More context on behavior is needed 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 with no wasted words. It's front-loaded with the core 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 read tool with one parameter and no output schema, the description is adequate but minimal. It covers the basic purpose but lacks details on behavior, usage context, or return values, leaving gaps that could hinder an AI agent's 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, with 'layoutId' documented as 'Layout ID or name'. The description adds minimal value by restating this parameter concept without providing additional semantics like format examples or constraints beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a layout element'), specifying it can be retrieved by 'ID or name'. However, it doesn't explicitly differentiate from sibling tools like 'layout.getCell' or 'layout.search', which might also retrieve layout-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'layout.list' for multiple layouts or 'layout.search' for filtered searches. The description lacks context about prerequisites 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 the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify what 'details' include, whether it requires specific permissions, or if there are rate limits. 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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the key action and target, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.
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 parameters, no output schema, no annotations), the description is minimally complete but lacks depth. It covers the basic purpose but misses usage guidelines and behavioral details, making it adequate for simple tasks but insufficient for more nuanced agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 ('layoutId' and 'cellIndex') with their types and requirements. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate but not enhanced parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and target ('about a specific cell in a grid layout'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sheet.getCell' or 'spreadsheet.getCell', which serve similar functions in different contexts, 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. It doesn't mention prerequisites, such as needing an existing layout, or compare it to related tools like 'layout.get' or 'layout.analyze', 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 states the tool lists elements, implying a read-only operation, but doesn't disclose behavioral traits like whether it returns all elements at once or paginates, what format the output is in, or any permissions required. The description is minimal and lacks context on how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 ('List all layout elements') and adds necessary scope details. There is no wasted language, and it's appropriately sized for a simple tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally complete. It covers what the tool does and the parameter's role, but lacks details on output format, behavioral traits, or usage context. For a list operation, this is adequate but leaves gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'screenId' documented as optional and specifying default behavior ('uses current screen if not provided'). The description adds no additional meaning beyond the schema, such as examples or constraints. With high schema coverage, the baseline is 3, as the schema handles 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 ('List') and resource ('layout elements'), specifying scope ('on the current or specified screen'). It distinguishes from other layout tools like layout.get or layout.search by focusing on listing all elements, but doesn't explicitly differentiate from siblings like nodes.list or html.list in terms of resource type. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention when to prefer layout.list over layout.search or layout.get, nor does it indicate prerequisites or context for use. Usage is implied by the action and resource, but no explicit guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Set style properties' which implies a mutation operation, but doesn't clarify permissions needed, whether changes are reversible, error conditions, or what happens to unspecified properties. The list of style properties adds some context but lacks behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a bulleted list of available properties. Every sentence earns its place, and it's appropriately sized 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 mutation tool with no annotations and no output schema, the description provides basic purpose and parameter semantics but lacks behavioral transparency and usage guidelines. The list of style properties helps, but doesn't fully compensate for missing context about how the tool behaves or when to use 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 both parameters ('layoutId' and 'style'). The description adds value by listing specific style properties (e.g., 'backgroundColor', 'padding', 'widthMode'), which provides semantic meaning beyond the generic 'Style properties to set' in the schema. This meets the baseline for good 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 ('Set style properties') and target ('on a layout element'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'layout.setCellStyle' or 'layout.update', which might have overlapping functionality, 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 'layout.setCellStyle' or 'layout.update', nor does it mention prerequisites or exclusions. It only lists available style properties without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't specify whether this requires specific permissions, what happens with invalid coordinates, whether it returns formatted values or raw data, or any error conditions. This leaves significant behavioral gaps for a data 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 communicates the core functionality without any wasted words. It's appropriately sized for a straightforward data 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 simple read operation with full parameter documentation in the schema, the description provides adequate basic context. However, without annotations or an output schema, it doesn't address important behavioral aspects like return format, error handling, or performance characteristics that would help an 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 input schema has 100% description coverage, with all three parameters clearly documented. The description doesn't add any additional parameter semantics beyond what's already in the schema, so it 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 ('Get') and resource ('a single cell value from a Sheet'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'spreadsheet.getCell' or 'layout.getCell', which appear to perform similar functions in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 sibling tools that appear to retrieve cell data (e.g., 'spreadsheet.getCell', 'layout.getCell', 'sheet.getCellFormula'), there's no indication of which context or data type this tool is designed for.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 important behavioral aspects like whether this is a read-only operation (implied but not stated), what happens if the cell has no formula, error conditions, or performance characteristics. The description adds minimal context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place, and there's no unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 3 parameters and no output schema, the description is minimally adequate. However, without annotations and with no output schema, it should ideally explain what gets returned (just the formula string? error if no formula?) and any constraints. The completeness is borderline given the tool's simplicity but leaves questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value. The description doesn't explain the relationship between parameters or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('formula string for a cell'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'sheet.getCell' or 'spreadsheet.getCellFormula', which appear to serve similar functions in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 similar tools in the sibling list (sheet.getCell, spreadsheet.getCellFormula), there's no indication of which context or system this tool operates within or when to choose it over other formula-retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying it's a read operation, but doesn't mention whether it requires specific permissions, what format the column data is returned in, if there are size limits, or if it's paginated. For a data retrieval 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 immediately conveys the core functionality. There's no wasted language or unnecessary elaboration, 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?
For a simple read operation with 2 parameters and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it doesn't provide enough information about what the tool returns (e.g., array of values, formatted data, error conditions). The agent knows what to input but not what to expect as output.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 input schema. The description adds minimal value beyond the schema by mentioning 'by index or letter' for the col parameter, which is already covered in the schema's description. Since the schema does the heavy lifting, 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 ('Get') and resource ('an entire column from a Sheet'), specifying the retrieval operation. It distinguishes itself from siblings like sheet.getCell or sheet.getRows by focusing on columns. However, it doesn't explicitly differentiate from sheet.getColumnCount, which is a related but different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sheet.getCell (for single cells), sheet.getRows (for rows), or sheet.getDataPaginated (for ranges). The description mentions the parameter options (index or letter) but doesn't help the agent choose between this tool and other data retrieval methods available 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?
No annotations are provided, so the description carries the full burden. It states a read operation ('Get'), implying it's non-destructive, but fails to disclose behavioral traits like error handling, performance implications, or return format. 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, clear sentence with no wasted words, making it front-loaded and efficient. Every part of the sentence directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only operation) and lack of output schema, the description is minimally adequate but incomplete. It covers the basic purpose but misses details on behavior and usage, which are needed for full contextual 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%, so the input schema fully documents the 'nodeId' parameter. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, resulting in the baseline score 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 ('Get') and resource ('number of columns in a Sheet'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'sheet.getRowCount' or 'sheet.getHeaders', 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, such as 'sheet.getRowCount' for row counts or 'sheet.getHeaders' for column details. It lacks context on prerequisites or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't specify whether this requires permissions, what format the headers are returned in, or if there are any limitations (e.g., maximum sheet size). It lacks details about the return structure or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 function without unnecessary words. It's front-loaded with the essential information and contains no redundant or verbose elements.
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 one parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more context about the return format (e.g., array of strings, JSON structure) or usage constraints. The lack of sibling differentiation is a notable gap given the many sheet-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'nodeId' clearly documented as 'Sheet node ID or name'. The description doesn't add any parameter information beyond what's in the schema, which is acceptable given the high schema coverage. However, it doesn't clarify what constitutes a valid 'nodeId' or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('column headers of a Sheet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'sheet.getCell' or 'sheet.getColumn', which also retrieve sheet data but target different elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 that retrieve sheet data (e.g., 'sheet.getCell', 'sheet.getColumn', 'sheet.getDataPaginated'), there's no indication of when headers specifically are needed or what distinguishes this tool from other data retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Get' implies a read operation, the description doesn't specify whether this requires permissions, what happens with invalid coordinates, whether it returns formatted values or raw data, or any error conditions. For a read 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 gets straight to the point with zero wasted words. It's front-loaded with the core functionality and appropriately sized for a simple retrieval tool. Every word earns its place in conveying the essential 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 good schema coverage but no output schema, the description is minimally adequate. It states what the tool does but lacks important context about return values, error handling, and differentiation from similar tools. The absence of annotations means the description should do more to explain behavioral aspects, but it doesn't fully 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?
With 100% schema description coverage, the schema already documents all four parameters thoroughly. The description adds no additional parameter information beyond what's in the schema - it doesn't explain coordinate systems, document identification, or sheet selection. 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 ('Get') and resource ('a single cell value from a standalone spreadsheet'), making the purpose immediately understandable. It distinguishes this tool from other spreadsheet tools like spreadsheet.setCell or spreadsheet.getData by specifying 'single cell' retrieval. However, it doesn't explicitly differentiate from sheet.getCell, which appears to be a similar sibling 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 sibling tools like sheet.getCell, spreadsheet.getData, and spreadsheet.getCellFormula available, there's no indication of when this specific tool is appropriate versus those alternatives. The description lacks any context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't mention whether this is a read-only operation, if it requires specific permissions, how it handles large datasets, or error conditions. The phrase 'Get data' implies reading, but no safety or performance details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with 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?
For a simple read operation with full schema coverage but no output schema or annotations, the description is minimally adequate. It covers what the tool does but lacks details on behavior, alternatives, or output structure, leaving gaps for an AI agent to infer 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 parameters are documented in the schema. The description adds no additional semantic context about parameters beyond implying data retrieval from a sheet. It doesn't explain defaults, constraints, or interactions between optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get data') and resource ('from a sheet in a standalone spreadsheet'), specifying the return format ('as a 2D array'). It distinguishes from siblings like spreadsheet.getCell or sheet.getDataPaginated by focusing on bulk data retrieval, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like spreadsheet.getCell (for single cells), sheet.getDataPaginated (for paginated data), or sheet.getRows (for row-based access). The description lacks context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool switches sheets, implying a navigation or focus change, but doesn't describe effects (e.g., whether it alters data, requires permissions, or has side effects like updating UI state). For a tool with potential user-interface implications, this lack of detail is a significant gap, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's function and parameters. It's front-loaded and appropriately sized for a simple navigation tool, with no 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 the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic action but lacks details on behavioral effects, error conditions, or integration with sibling tools. Without annotations or output schema, more context on what 'switching' entails would improve completeness, but it's not entirely inadequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: documentId as optional and using active context, and indexOrName as sheet index or name. The description adds minimal value beyond the schema, only reiterating 'by index or name' without providing additional context like 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 ('Switch to a different sheet') and resource ('within a spreadsheet'), specifying the method ('by index or name'). It distinguishes from siblings like spreadsheet.listSheets (which lists sheets) or spreadsheet.renameSheet (which modifies sheet names), but doesn't explicitly contrast with spreadsheet.getActiveDocument or other navigation tools. The purpose is specific and actionable, though sibling differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open spreadsheet), exclusions, or compare with related tools like spreadsheet.getActiveDocument or sheet.getCell for context switching. Usage is implied by the action, but no explicit context or alternatives 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 but offers minimal behavioral insight. It implies a read-only operation ('Get info'), but doesn't specify what 'info' includes, whether it's real-time or cached, error conditions, or permissions needed. This leaves significant gaps for a tool that likely interacts with active system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and target, making it immediately understandable. 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?
Given the complexity of likely returning structured workflow data, no output schema, and no annotations, the description is insufficient. It doesn't explain what 'info' entails (e.g., metadata, nodes, status), return format, or error handling. For a tool in a rich workflow system with many siblings, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose instead. A baseline of 4 is applied as it efficiently handles the zero-parameter case without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get info') and target ('currently visible workflow'), which is specific and understandable. However, it doesn't differentiate from sibling tools like 'workflow.getFlowcharts' or 'workflow.getStructure', which also retrieve workflow information but with different scopes or details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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., requires an active workflow), exclusions, or compare it to siblings like 'workflow.getStructure' for broader context or 'designer.getActive' for similar 'active' concepts in other domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 the algorithm (dagre) and outcome (clean flowchart appearance), but doesn't describe side effects (e.g., whether it modifies node positions in-place, requires specific permissions, or has performance implications). For a tool that likely mutates layout data, this is insufficient 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 concise and front-loaded, consisting of two sentences that directly state the tool's function and outcome. There is no wasted language, and it efficiently communicates the core purpose without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a layout tool with potential mutations), lack of annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, usage context, and output format. This leaves gaps for an agent to understand full implications, especially since sibling tools suggest a rich workflow 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 schema description coverage is 100%, so the schema already documents all three parameters (nodeIds, direction, spacing) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'nodeIds' interact with connected nodes or default behaviors. 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 tool's purpose: 'Auto-layout specific nodes using dagre (longest-path algorithm). Positions nodes and optimizes edge handles for clean flowchart appearance.' It specifies the action (auto-layout), target (nodes), algorithm (dagre), and outcome (clean flowchart appearance). However, it doesn't explicitly differentiate from sibling tools like 'layout.create' or 'layout.update', which might also handle layout-related 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. It doesn't mention prerequisites, such as needing existing nodes or a workflow context, or compare it to other layout-related tools in the sibling list (e.g., 'layout.create', 'layout.update'). 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. It states the tool closes a view and returns to a canvas, which implies a UI navigation action, but doesn't disclose critical traits like whether this is a read-only operation, if it requires specific permissions, what happens to unsaved changes in the CodeBook, or if it triggers side effects. For a tool 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 conveys the tool's purpose and outcome without any wasted words. It's front-loaded with the main action and result, making it easy for an agent to parse quickly. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does but lacks details on behavioral context (e.g., side effects, permissions) and usage guidelines. For a UI navigation tool in a workflow environment, more context on when and why to use it would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none. Baseline for 0 parameters is 4, as no additional semantic information is needed beyond 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 ('Close') and the target ('CodeBook view'), and specifies the outcome ('return to workflow canvas'). It distinguishes from siblings like codebook.open, codebook.isOpen, and codebook.getState by focusing on closing rather than opening, checking, or retrieving state. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a CodeBook view is open and the user wants to return to the workflow canvas, but it doesn't provide explicit guidance on when to use this tool versus alternatives. No prerequisites (e.g., CodeBook must be open), exclusions, or comparisons to other tools are mentioned. This leaves the agent with minimal contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read-only operation ('List'), but doesn't specify if it requires permissions, how results are formatted (e.g., list vs. structured data), or if there are limitations (e.g., pagination, performance). For a tool with zero annotation coverage, this is insufficient to inform the agent about expected 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 essential information ('List all edges'), making it easy for an agent to parse quickly. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate. It states what the tool does but lacks context about the workflow environment, edge representation, or result format. Without annotations or output schema, the agent must infer these details. For a read-only list operation, this is borderline acceptable but leaves gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description appropriately doesn't discuss parameters, as none exist. It could theoretically mention that no inputs are needed, but this is implied by the schema. A baseline of 4 is appropriate for zero-parameter tools where the schema fully documents the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all edges in the current workflow'), making the purpose immediately understandable. It distinguishes from siblings like 'edges.connect' and 'edges.delete' by focusing on listing rather than modifying edges. However, it doesn't specify what 'edges' represent in this context (e.g., connections between nodes), 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 active workflow), compare to similar tools like 'nodes.list' or 'workflow.getStructure', or indicate when listing edges is appropriate (e.g., for inspection vs. modification). This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the Designer mode dependency, which is useful context, but fails to disclose critical behavioral traits such as whether the deletion is permanent, requires specific permissions, has side effects on connected elements, or what happens on success/failure. For a destructive operation 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 front-loaded with the core action and resource, followed by a contextual note. It consists of two concise sentences with zero waste, making it 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?
Given the tool's complexity as a destructive operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like reversibility, error handling, or return values, which are crucial for safe usage. The context provided is minimal and doesn't compensate for the missing structured 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?
The schema description coverage is 100%, with the parameter 'id' documented as 'Component ID' in the schema. The description doesn't add any meaning beyond this, such as explaining how to obtain the ID or its format. 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 ('HTML component from the drawing layer'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'nodes.delete' or 'layout.delete', which might also delete elements in related contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context with 'In Designer mode, operates on currently selected screen,' which implies usage depends on the application mode. However, it lacks explicit guidance on when to use this tool versus alternatives like 'html.update' or other deletion tools, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context beyond the schema: it explains that full-width types auto-snap to screen width and semantic elements auto-position (e.g., header at top). However, it lacks critical details like whether this is a mutation (implied by 'create'), permission requirements, error handling, or what happens on success/failure. The description partially compensates for missing annotations but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, then lists layout types with bullet points for readability, and adds behavioral notes. Every sentence adds value (e.g., explaining auto-snap and auto-position). It could be slightly more concise by integrating the bullet points into prose, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects) and no output schema, the description is moderately complete. It covers the core purpose and parameter context (layout types and behaviors), but lacks details on mutation effects, error cases, or return values. With no annotations, it should do more to explain behavioral aspects, but it's adequate for a creation tool with good schema 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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it categorizes layout types (semantic sections, grid layouts, etc.) and notes auto-behaviors for some types, which helps interpret the 'type' parameter. However, it doesn't explain other parameters like 'position' or 'dimensions' beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Create a layout element on a screen.' It specifies the verb ('create'), resource ('layout element'), and context ('on a screen'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'layout.createSection' or 'layout.update', leaving some ambiguity about when to choose this over 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 lists layout types and their behaviors (e.g., auto-snap, auto-position), but doesn't mention when to choose 'layout.create' over other layout tools like 'layout.createSection' or 'layout.update', or prerequisites such as needing an existing screen. Usage is implied through parameter details 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 full burden for behavioral disclosure. While 'List' implies a read-only operation, the description doesn't specify whether this requires permissions, what format the list returns (e.g., paginated, filtered), or any side effects. It mentions 'active workflow' which adds some context, but lacks details on error conditions, performance characteristics, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 states exactly what the tool does with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place by specifying scope ('all nodes', 'active workflow').
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 0 parameters and no annotations, the description is adequate but has clear gaps. It doesn't explain the return format (no output schema exists), potential limitations, or how it differs from sibling tools. The mention of 'active workflow' adds useful context, but overall it's minimalistic for a tool in a complex ecosystem with many sibling operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to explain parameters, and it correctly doesn't mention any. It adds value by specifying 'all nodes in the active workflow', which clarifies the implicit scope beyond what the empty schema indicates. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all nodes in the active workflow'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'nodes.get' or 'nodes.search', but the scope ('all nodes') provides some implicit distinction. The description avoids tautology by specifying what is being listed beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'nodes.get', 'nodes.search', or 'nodes.getByType'. It mentions 'active workflow' which gives some context, but doesn't explain prerequisites, limitations, or comparative use cases with sibling tools. There's no explicit 'when' or 'when not' to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions 'modify nodes/edges,' it doesn't clarify permissions needed, whether changes are reversible, rate limits, or what the response looks like (since there's no output schema). 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 extremely concise with two sentences that are front-loaded and waste no words. Every sentence directly contributes to understanding the tool's purpose and basic usage, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters with nested objects, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain what happens after the update, error conditions, or behavioral nuances, leaving the agent with insufficient 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 already documents all four parameters thoroughly. The description adds minimal value by hinting at the purpose of 'nodeIds' ('from createFlowchart response') but doesn't provide additional semantics 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 an existing flowchart') and the resource ('flowchart'), making the purpose immediately understandable. It distinguishes from sibling 'nodes.createFlowchart' by specifying it's for updates rather than creation, though it doesn't explicitly differentiate from other update tools like 'nodes.update' or 'screen.update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Pass nodeIds from createFlowchart response to modify nodes/edges,' which implies this tool should be used after creation. However, it doesn't specify when to use this versus other update tools (like 'nodes.update' or 'layout.update') or provide explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation but doesn't mention whether it returns all screens at once, if there's pagination, what format the output takes, or any performance considerations. 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 gets straight to the point without any fluff. It's front-loaded with the core purpose and every word earns its place, making it optimally concise for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers the basic purpose adequately. However, without annotations or output schema, it should ideally mention something about the return format (e.g., list of screen objects) or scope limitations to be more complete. It meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't waste space discussing parameters, maintaining focus on the tool's purpose. A baseline of 4 is justified since no parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all screens') and resource ('screens (pages/artboards) in the current Designer document'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'screen.get' or 'screen.capture', 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 'screen.get' (for individual screens) or 'screen.capture' (for screenshots). It lacks any context about prerequisites, timing, or comparisons with sibling tools, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'useful for planning chunked reads,' which hints at a read-only, non-destructive operation, but it doesn't explicitly state permissions, rate limits, or error behaviors. For a 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 concise and front-loaded: the first sentence states the core purpose, and the second adds contextual value without redundancy. Every sentence earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is somewhat complete but lacks depth. It covers the basic purpose and a usage hint, but without annotations or output schema, it should ideally provide more behavioral context (e.g., return format, error cases) to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'nodeId' clearly documented as 'Code node ID or name.' The description doesn't add any extra parameter details beyond what the schema provides, such as format examples or constraints. 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 tool's purpose: 'Get the number of lines in a code node.' It specifies the verb ('Get') and resource ('code node'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'code.getCode' or 'code.setLines', which might have overlapping contexts, so 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 provides implied usage guidance with 'Useful for planning chunked reads of large files,' suggesting a context for when this tool is beneficial. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'code.getCode' for content retrieval) or any exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 what the tool does but doesn't describe important behavioral aspects: whether this returns all matching nodes or is paginated, what format the results take, whether it requires specific permissions, or if there are rate limits. 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 perfectly concise - a single sentence stating the purpose followed by a parenthetical list of valid types. Every word earns its place, with no redundant information. The structure is front-loaded with the core functionality first, making it immediately scannable and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with good schema coverage but no output schema or annotations, the description is adequate but incomplete. It explains what the tool does and provides parameter semantics, but lacks information about return format, pagination, error conditions, or performance characteristics. Given the tool's relative simplicity, it's minimally viable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'type' well-documented in the schema. The description adds value by providing a comprehensive list of valid type values (e.g., 'datagrid' for Sheet, 'code', 'agent'), which clarifies the parameter's semantics beyond the schema's generic description. This earns the baseline 3 score for good schema coverage with some added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'nodes of a specific type', making the purpose immediately understandable. It distinguishes this tool from general listing tools like 'nodes.list' by specifying type-based filtering. However, it doesn't explicitly differentiate from 'nodes.search' which might also filter by type, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing available node types, suggesting this tool should be used when you need nodes filtered by type rather than all nodes. However, it doesn't explicitly state when to use this versus alternatives like 'nodes.list' (for all nodes) or 'nodes.search' (for more complex filtering), nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates this is a read operation ('Get') and mentions what data is returned, but doesn't disclose important behavioral traits like whether this requires specific permissions, if it's cached or real-time data, error conditions, or response format. For a state retrieval 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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides usage context. There's no wasted language or redundancy, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does and provides some context, but without annotations or output schema, it should ideally disclose more about the return format, permissions needed, or behavioral characteristics. The description is complete enough for basic understanding but lacks depth for confident agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the parameter requirements (none). The description appropriately doesn't discuss parameters since none exist, and it adds value by explaining what state information is retrieved. This meets the baseline expectation for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'CodeBook state', specifying what information is retrieved (cell order, selected cell, execution status). It distinguishes from siblings like codebook.runCell or codebook.addCell by focusing on state retrieval rather than execution or modification. However, it doesn't explicitly differentiate from codebook.getExecutionTarget, which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context with 'Useful for understanding the current notebook context', suggesting when this tool might be helpful. However, it doesn't explicitly state when to use this versus alternatives like codebook.getExecutionTarget or execution.getStatus, nor does it provide any exclusions or prerequisites 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 full burden but only mentions creation methods. It doesn't disclose whether this is a read-only or destructive operation, what permissions are needed, whether it's idempotent, what happens on conflicts, or what the return value looks like. For a creation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste - the first states the purpose, the second provides critical usage guidance. Every word earns its place, and the information is front-loaded appropriately.
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 incomplete. It doesn't explain what a 'code node' is in this system, what happens after creation, whether there are side effects, or what the tool returns. The parameter guidance is helpful but insufficient for full contextual 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%, so the schema already documents all parameters thoroughly. The description adds value by explaining the OR relationship between filePath and name+content, which clarifies the mutual exclusivity not evident from the schema alone. This earns the baseline 3 for good schema coverage with some added semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a code node') and distinguishes between two creation methods (bidirectional file sync vs. direct creation). It doesn't explicitly differentiate from sibling 'code.createBatch' or 'code.createBatchGrouped', but the verb+resource+method specificity is strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each parameter combination (filePath for sync, name+content for direct creation). It doesn't mention when NOT to use this tool versus alternatives like 'code.createBatch' or 'code.setCode', but the usage context is well-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. It mentions the output is a 'formatted string' and that it shows specific document attributes, but doesn't disclose important behavioral aspects like whether this is a read-only operation, what format the string uses, if there are any rate limits, or how it handles edge cases like no open documents. 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 perfectly concise with two sentences that each earn their place. The first sentence explains what the tool does and what information it provides. The second sentence explains when to use it. There's zero wasted language or redundancy, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a zero-parameter tool with no annotations and no output schema, the description provides adequate basic information about what the tool returns (a formatted string with specific document attributes) and its purpose (understanding multi-document context). However, it doesn't describe the format of the returned string or provide examples, which would be helpful since there's no output schema. For a context-reporting tool, more detail about the output format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing nonexistent parameters. It gets a baseline 4 since there are no parameters to document, and the description focuses on what the tool does rather than trying to explain parameters that don't exist.
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: 'Get a formatted string listing open documents for system prompts' with specific details about what information it shows (document names, types, panes, current target). It distinguishes itself from sibling tools like documents.list by specifying the formatted output for system prompts, though it doesn't explicitly contrast with all document-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Use this to understand the multi-document context' suggests it's for getting contextual awareness rather than raw document data. However, it doesn't explicitly state when to use this versus alternatives like documents.list or documents.getByType, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool retrieves metadata and pane locations, which adds some context beyond the basic purpose. However, it doesn't cover critical aspects like whether this is a read-only operation, potential performance impacts, error conditions, or the format of the returned data. 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 front-loaded with the core purpose in the first sentence, followed by a useful context sentence. Both sentences earn their place by adding value: the first defines the action, and the second explains when it's beneficial. There is no wasted language, making it efficient 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 (0 parameters, no output schema), the description is minimally adequate. It covers the purpose and some usage context but lacks details on behavioral traits like safety, performance, or output format, which are important since no annotations or output schema exist. It meets the basic needs but leaves room for improvement in transparency, especially for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't need to add parameter details since there are none, which is appropriate. It implicitly confirms there are no required inputs by not mentioning any, aligning with the schema. A baseline of 4 is applied as it handles the zero-parameter case adequately without redundancy.
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: 'Get all open documents with their metadata.' It specifies the verb ('Get'), resource ('open documents'), and scope ('all'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'documents.getByType' or 'documents.getRecent', which is why it doesn't reach 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by stating it's 'Useful for discovering what documents are available and which pane they are in.' This suggests when to use it (for discovery and pane information), but it doesn't explicitly mention when not to use it or name alternatives like 'documents.getByType' for filtered queries. The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 it's a listing tool ('List'), which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data, or handles errors. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a brief usage note. Every word earns its place with no redundancy or fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose and a usage hint, but lacks details on output format, error handling, or integration context, which could be helpful for an AI agent despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, which is appropriate here. A baseline of 4 is applied since the schema fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List formula functions organized by category (Math, Logic, Text, Lookup, Date, etc.)'. It specifies the verb ('List') and resource ('formula functions'), with examples of categories provided. However, it doesn't explicitly differentiate from sibling tools like 'sheet.listFunctions' or 'spreadsheet.listFunctions', 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage guideline: 'Useful for discovering available functions', which implies when to use it. However, it doesn't provide explicit alternatives (e.g., vs. 'sheet.listFunctions') or exclusions. The guidance is implied rather than comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 the return includes '100+ Excel-compatible function names' and provides examples, but doesn't disclose important behavioral aspects like whether this is a read-only operation, if it requires authentication, rate limits, or pagination behavior for large result sets.
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 efficiently structured with a clear opening sentence followed by categorized examples. While the example list is extensive, each category earns its place by illustrating the breadth of functions returned. The information is front-loaded with the core purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description provides reasonable coverage of what the tool returns through examples. However, without annotations or output schema, it lacks details about return format, error conditions, or whether this is a static list versus dynamic lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool returns, which is valuable context for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('List') and resource ('all available formula functions for spreadsheets'), and distinguishes it from sibling tools like spreadsheet.listFunctionCategories by focusing on individual function names rather than categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 spreadsheet.listFunctionCategories or sheet.listFunctions. The description simply states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits such as whether it returns real-time data, requires specific permissions, has rate limits, or what 'simplified structure' entails (e.g., format, depth, or exclusions). The description adds minimal context 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 two concise sentences that are front-loaded with the core purpose and usage context. Every word earns its place, with no redundancy or unnecessary elaboration, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic purpose and usage but lacks details on behavioral aspects (e.g., return format, performance, or limitations). For a read-only tool with zero parameters, it's adequate but leaves gaps in understanding the full context of what 'simplified structure' means or how it behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't need to compensate for any gaps, and the baseline for this scenario is appropriately set at 4, as it's complete without requiring additional parameter 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 verb ('Get') and resource ('simplified structure of all flows in the workflow'), and provides a specific purpose ('to understand what user has drawn'). It doesn't explicitly differentiate from sibling tools like 'workflow.getFlowcharts' or 'workflow.getNodeSummary', but the focus on 'simplified structure' offers some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to understand what user has drawn'), suggesting it's for comprehension rather than manipulation. However, it doesn't explicitly state when to use this tool versus alternatives like 'workflow.getFlowcharts' or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that this sets a target for 'subsequent operations,' which implies statefulness and persistence, but doesn't clarify if this affects all tools or only specific ones, what happens if no target is set, or any error conditions. For a state-changing 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 two sentences that are front-loaded with the core purpose and followed by a brief usage context. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (state-setting with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and basic usage but lacks details on behavioral implications, error handling, or integration with other tools. For a tool that likely influences many sibling operations, more context would be beneficial to ensure 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 input schema has 100% description coverage, with the single parameter 'docId' documented as 'Document ID to target.' The description doesn't add any additional meaning beyond this, such as format examples or sourcing instructions. With high schema coverage, the baseline score of 3 is appropriate, as the schema already 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 ('Set an explicit target document') and resource ('document'), making the purpose understandable. It distinguishes from some siblings like 'documents.getTarget' or 'documents.clearTarget' by specifying it's for setting rather than getting or clearing. However, it doesn't explicitly differentiate from all document-related tools, such as 'documents.getByType' or 'documents.list', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'when working with multiple documents to ensure operations go to the correct one.' This implies it should be used to manage document targeting in multi-document scenarios. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about what information is retrieved (context types and HTML component existence), which is helpful. However, it doesn't cover potential behavioral traits like error conditions, permissions needed, or response format, leaving gaps for a read operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and usage. Every sentence adds value without redundancy. It could be slightly more structured by separating purpose and guidelines, but it's efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and lack of annotations and output schema, the description is somewhat complete but has gaps. It explains what information is retrieved but doesn't detail the return format or potential limitations. For a tool with no structured output documentation, more context on the response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional parameter information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about the active drawing document.' It specifies the verb ('Get information') and resource ('active drawing document'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'drawing.getImage' or 'designer.getActive', which would be needed for 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'Use to determine context (notepad/designer/workflow) and whether HTML components exist.' This suggests when to use it—for context determination—but doesn't explicitly mention when not to use it or name alternatives among the many sibling tools, such as 'designer.getActive' for designer context or 'html.list' for HTML components.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Set' implies a mutation operation, it doesn't disclose whether this requires specific permissions, if changes are reversible, what happens to existing content, or any rate limits. The description adds minimal behavioral context 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 perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides usage guidance. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides basic purpose and some usage guidance but lacks important behavioral context like error conditions, permissions needed, or what the tool returns. The 100% schema coverage helps, but more context would be beneficial for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (like 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 ('Set HTML content') and resource ('for a grid cell'), making the purpose immediately understandable. It distinguishes from sibling 'layout.setCellStyle' by focusing on content rather than styling, though it doesn't explicitly contrast with all layout tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to 'Use html.create for more complex components,' offering a clear alternative for more advanced use cases. However, it doesn't specify when to use this tool versus other layout tools like layout.setCellStyle or layout.update.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 mentions efficiency but does not disclose whether this is a mutation operation, what permissions are required, how errors are handled, or the impact on existing data. For a tool with 8 parameters and no annotations, 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 front-loaded with the core purpose and efficiently explains the formula pattern syntax in a single, clear sentence. Every word earns its place, with no redundant or verbose language, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description is incomplete. It adequately covers the formula pattern aspect but lacks details on behavioral traits, error handling, and output expectations. While the schema provides parameter documentation, the description does not compensate for the absence of annotations and output schema, leaving 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 already documents all parameters thoroughly. The description adds value by explaining the formula pattern syntax with {row}/{col} placeholders and Excel-style indexing, which clarifies semantics beyond the schema's basic descriptions. However, it does not elaborate on other parameters like nodeId or fill directions, relying on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fill a range with a formula pattern') and resource ('sheet'), distinguishing it from sibling tools like sheet.setCell or sheet.setCells by emphasizing pattern-based filling for computed columns/rows. The mention of efficiency for computed columns/rows further clarifies its specialized use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for computed columns/rows with formula patterns, providing some context, but does not explicitly state when to use this tool versus alternatives like sheet.setCellFormula or sheet.setCells. No exclusions or prerequisites are mentioned, leaving gaps in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pagination and suitability for large sheets, which is useful context. However, it lacks critical details such as whether this is a read-only operation, what the output format looks like (e.g., JSON array, error handling), performance characteristics, or any rate limits. For a data retrieval 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of only two sentences that directly address the tool's purpose and usage guidelines. Every word earns its place, with no redundant or vague language. It efficiently communicates key information 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 the tool's complexity (data retrieval with pagination), no annotations, and no output schema, the description is moderately complete. It covers the purpose and when to use it but lacks details on behavioral traits, output format, and error handling. For a tool with three required parameters and no structured output documentation, it should provide more context to fully guide an agent, such as what the returned data looks like or how to handle empty pages.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'nodeId', 'page', and 'pageSize'. The description adds minimal value beyond the schema, as it doesn't provide additional semantics like examples or edge cases. However, it implicitly reinforces the pagination aspect, which aligns with the parameters. 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 tool's purpose: 'Get sheet data with pagination.' It specifies the verb ('Get') and resource ('sheet data'), and distinguishes itself from non-paginated alternatives like 'sheet.getData' or 'spreadsheet.getData' by explicitly mentioning pagination. However, it doesn't explicitly differentiate from all sibling tools, such as 'sheet.getRows' or 'sheet.getCell', which might also retrieve data but with different scopes or methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Best for large sheets (100K+ rows).' This gives a specific threshold and implies that for smaller sheets, other tools might be more appropriate. However, it doesn't explicitly name alternative tools or specify when not to use it, such as for real-time updates or single-cell retrieval, which could be handled by siblings like 'sheet.getCell' or 'sheet.getRows'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, performance characteristics, error conditions, or what happens with empty sheets. 'Get' implies reading, but explicit safety/behavior details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose, resource, and output format with zero wasted words. Front-loaded with the core action ('Get all formulas') followed by essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 100% schema coverage but no annotations or output schema, the description adequately covers the basic purpose. However, it lacks details about return format structure, error handling, or performance considerations 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 the single parameter 'nodeId' well-described as 'Sheet node ID or name'. The description adds no additional parameter context beyond what the schema provides, maintaining the baseline score 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 ('Get all formulas') and resource ('in a Sheet'), with precise output format ('as a map of cell keys to formula strings'). It distinguishes from sibling tools like sheet.getCellFormula (single cell) and spreadsheet.getCellFormula (different resource scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all formulas from a sheet, but provides no explicit guidance on when to use this vs. alternatives like sheet.getCellFormula for single formulas or sheet.getDataPaginated for non-formula data. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the read-only nature ('Get') and the return behavior ('Returns null if cell has no formula'), which are helpful. However, it doesn't mention error conditions (e.g., invalid documentId), performance characteristics, or authentication requirements that would be valuable for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two clear sentences: the first states the core purpose, the second specifies the null return behavior. Every word earns its place, and the information is front-loaded with no 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 read-only tool with 100% schema coverage but no output schema, the description is reasonably complete about what the tool does and its return behavior. However, it lacks context about error handling, the meaning of 'standalone spreadsheet', and how this differs from similar tools in the sibling list, leaving some gaps for 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?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain what 'standalone spreadsheet' means for documentId selection or how sheetIndex interacts with the active sheet). The baseline score of 3 reflects adequate but minimal value added over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the formula'), target resource ('from a cell in a standalone spreadsheet'), and outcome ('Returns null if cell has no formula'). It distinguishes itself from siblings like 'spreadsheet.getCell' or 'sheet.getCellFormula' by focusing exclusively on formula retrieval rather than general cell content or sheet-specific 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 'spreadsheet.getCell' (which might return cell values) or 'sheet.getCellFormula' (which operates on sheets rather than spreadsheets). It mentions 'standalone spreadsheet' but doesn't explain why this context matters or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a read operation ('Get'), supports optional line ranges, and handles large files. However, it doesn't mention error handling, permissions, rate limits, or what happens if the nodeId is invalid. The description adds useful context but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by concise explanations of optional parameters and a clear example. Every sentence earns its place with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is somewhat complete but has gaps. It explains the input behavior well but doesn't describe the output format (e.g., structure of returned code), error cases, or how it interacts with siblings. It's adequate for basic use but lacks depth for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the semantics of offset and limit (e.g., '0-indexed', 'returns lines 100-149'), which clarifies usage beyond the schema's basic descriptions. It doesn't add info for nodeId, but the example compensates well.
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: 'Get code from a Code node.' It specifies the verb ('Get') and resource ('code from a Code node'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'code.getLineCount' or 'code.setCode', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by explaining when to use offset/limit parameters ('for large files') and the behavior with and without them. However, it doesn't explicitly state when to use this tool versus alternatives like 'code.getLineCount' or 'code.setCode', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool is for reading ('Get existing flow nodes'), which implies it's non-destructive, but doesn't disclose other behavioral traits like permissions needed, rate limits, or what format the data returns. For a read operation 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?
Two sentences, front-loaded with the core purpose and followed by usage guidance. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no annotations and no output schema, the description covers purpose and usage well but lacks details on return values or behavioral constraints. It's adequate as a minimum viable description 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on usage context. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get existing flow nodes') and purpose ('to modify'), distinguishing it from creation tools. However, it doesn't explicitly differentiate from other read operations like 'workflow.getStructure' or 'nodes.get', which could be similar siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool ('Use before updateFlowchart to see what exists'), linking it to a specific sibling operation. This gives clear context, though it doesn't mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return format (name, type, connections) and the tool's purpose (for diagram understanding), which is valuable behavioral context. However, it doesn't mention potential limitations like what happens with invalid node IDs, whether it's a read-only operation, or any performance considerations. For a tool with zero annotation coverage, this provides basic but incomplete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second explains the return value and context. There's zero wasted language, and information is front-loaded appropriately.
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 simple single parameter with full schema coverage, the description provides adequate but minimal context. It explains what the tool returns and its purpose, but doesn't cover error conditions, authentication needs, or what 'connections' specifically means. For a read operation with one optional parameter, this is minimally complete but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the default behavior ('optional - defaults to all' is in the schema, but the description reinforces this by implying it returns information about nodes generally). However, it doesn't provide additional semantic context beyond what the schema already documents about the 'nodeIds' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'simplified details about nodes', specifying what information is returned (name, type, and connections). It distinguishes from sibling tools like 'nodes.get' or 'nodes.getByName' by emphasizing simplified details for diagram understanding rather than full node data. However, it doesn't explicitly contrast with all sibling node-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('enough for Claude CLI to understand the diagram'), suggesting this is for diagram comprehension rather than detailed node operations. It doesn't provide explicit when-to-use vs. when-not-to-use guidance or name specific alternatives among the many sibling tools (e.g., 'nodes.get', 'nodes.getByType', 'workflow.getStructure'). The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 reverts to a previous state, implying mutation, but lacks details on permissions, limitations (e.g., only one undo level), error conditions, or what 'previous state' entails. For a mutation tool with zero annotation coverage, this is inadequate, as it doesn't disclose key behavioral traits like side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and scope, followed by usage guidance. Every word earns its place with no redundancy or fluff, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0 parameters, the description is minimal but covers purpose and usage. However, for a mutation tool ('undo'), it lacks details on behavioral aspects like what happens on failure or if no changes exist, making it incomplete for safe agent invocation. It's adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine, but it could have mentioned any implicit context (e.g., requires an active workflow). Baseline is 4 since no parameters exist, and the description doesn't detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('undo') and target ('last workflow change'), specifying it reverts nodes, edges, and drawing data. It distinguishes from siblings like 'workflow.redo' by focusing on reversal, though not explicitly named. However, it's slightly less specific than a perfect 5, which would explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('when changes need to be reverted or the user asks to undo'), which helps guide when to invoke this tool. It implies an alternative ('workflow.redo' from siblings) but doesn't explicitly name it or detail when-not scenarios, keeping it from a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), but lacks details on permissions, error conditions, or return format. While it hints at a simple query, more behavioral context (e.g., what 'execution target' entails) would improve 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 no wasted words. It's front-loaded with the core purpose and efficiently conveys the tool's function 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 the tool's simplicity (0 params, no annotations, no output schema), the description is adequate but could be more complete. It explains what the tool does but lacks context on why this matters or what the returned 'execution target' represents, which might help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info, but that's appropriate here. Baseline is 4 for zero-param tools, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current Python execution target for new code cells'), making the purpose specific and unambiguous. It distinguishes from sibling tools like 'codebook.setExecutionTarget' by focusing on retrieval rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to know the execution target, but provides no explicit guidance on when to use this tool versus alternatives or prerequisites. For example, it doesn't specify if this should be used before running code cells or in conjunction with 'codebook.setExecutionTarget'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 correctly indicates this is a read operation ('Get'), but doesn't mention potential side effects, authentication requirements, rate limits, or what happens if no mode is set. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered about how the tool actually functions 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, efficient sentence that states exactly what the tool does. It's front-loaded with the core purpose and includes the specific possible return values. There's zero wasted language or redundancy, making it maximally concise while still informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no parameters and no output schema, the description provides adequate basic information about what the tool returns (the current mode and possible values). However, it doesn't explain the format of the return value, whether it's a string/enum, or what happens in edge cases. Given the lack of annotations and output schema, more behavioral context would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema is fully described). The description appropriately doesn't discuss parameters since none exist. It earns a 4 rather than 5 because it could have explicitly mentioned 'no parameters required' to be perfectly clear, but the absence of parameter discussion is reasonable for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current Designer mode', specifying the exact action and what it retrieves. It distinguishes from sibling tools like 'designer.setMode' by indicating this is a read operation rather than a write operation, and from other 'designer.get*' tools by focusing specifically on the mode rather than active state or design context.
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 by mentioning 'current Designer mode' and listing possible modes (design, layout, html, preview), suggesting it should be used when the agent needs to know the current mode state. However, it doesn't explicitly state when to use this tool versus alternatives like 'designer.getActive' or 'designer.getDesignContext', nor does it provide exclusion criteria or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about partial updates ('Only provided fields will be updated') and Designer mode behavior, but doesn't cover critical aspects like permissions, error handling, or what happens on success/failure. For a mutation tool with 11 parameters, 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 extremely concise with just two sentences, both of which add value: the first explains the core update behavior, and the second provides crucial Designer mode context. There's zero wasted text, and it's front-loaded with the main 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 complexity (mutation tool with 11 parameters, nested objects, no annotations, and no output schema), the description is incomplete. It covers the partial update behavior and Designer mode nuance well, but lacks information about return values, error conditions, or system-wide effects. This is adequate but has clear gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples or constraints. This meets the baseline 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 verb ('Update') and resource ('existing HTML component'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'html.create' or 'html.get' beyond the update action, which is why it doesn't reach 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('In Designer mode, operates on currently selected screen') and references an alternative tool ('use screen.select first if needed'). It lacks explicit exclusions or comparisons to other update tools like 'layout.update' or 'nodes.update', preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the resolution process ('Uses heuristics to match...') which is useful context, but doesn't mention important behavioral aspects like whether this is a read-only operation, what permissions might be required, error conditions, or what the output looks like. For a tool with no annotations, this leaves significant gaps in understanding how it 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 perfectly concise and well-structured. Two sentences efficiently convey the purpose, method, and usage guidance. Every word earns its place with no redundancy or unnecessary elaboration. The information is front-loaded with the core purpose stated 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?
Given the tool's complexity (resolving user references using heuristics), no annotations, and no output schema, the description is somewhat incomplete. It explains what the tool does and when to use it, but doesn't describe the output format or important behavioral constraints. For a resolution tool with no structured output documentation, more context about what gets returned would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents both parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. It mentions 'selected node content' which relates to the 'selectedNodeId' parameter, but this is already covered in the schema description ('greatly improves resolution accuracy').
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: 'Resolve which flow/nodes the user is referring to based on their message.' It specifies the verb (resolve) and resource (flow/nodes), and mentions the matching heuristics (selected node content, node names, code/text content keywords). However, it doesn't explicitly differentiate from sibling tools like 'workflow.getFlowcharts' or 'workflow.getNodeSummary' that might also retrieve workflow information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Call this instead of fetching entire workflow for context.' This gives a specific alternative to avoid (fetching entire workflow) and implies it's for interpreting user references. However, it doesn't explicitly state when NOT to use it or name specific alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that screens can be resized taller if content overflows, which is useful behavioral context. However, it doesn't mention important aspects like whether this operation requires specific permissions, what happens on duplicate names, or what the response looks like (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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three focused paragraphs. The first states the purpose, the second explains parameter context, and the third provides a helpful tip. However, the tip paragraph could be more concise, and the structure isn't perfectly front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description provides adequate context about what the tool does and parameter usage. However, it lacks information about what happens after creation (return values, error conditions) and doesn't fully address behavioral aspects like permissions or side effects, leaving some gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds some value by explaining device presets with examples and clarifying that 'custom' requires explicit dimensions, but doesn't provide significant additional semantics beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new screen') and resource ('in the Designer'), with additional context about what a screen represents ('page/artboard'). It distinguishes from sibling tools like screen.update, screen.delete, and screen.duplicate by focusing exclusively on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for creating screens with device presets or custom dimensions) and includes a helpful tip about using layout.analyze afterward. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among siblings like screen.duplicate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it returns null if no spreadsheet is focused, which is crucial for error handling. However, it lacks details on permissions, rate limits, or what specific info is returned (e.g., document ID, name). This leaves gaps in understanding the tool's full 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 front-loaded and efficient: two sentences with zero waste. The first sentence states the purpose, and the second provides usage context. Every sentence earns its place, making it easy to scan 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 no annotations, no output schema, and 0 parameters, the description is somewhat complete for a simple tool. It covers purpose and basic behavior (returns null if no active spreadsheet) but lacks details on return format (what 'info' includes) and error cases beyond null. This leaves room for improvement in fully guiding the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline for 0 params is 4, as it avoids unnecessary details, but it doesn't reach 5 since it doesn't explicitly note the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get info about the active standalone spreadsheet document.' It specifies the verb ('Get info') and resource ('active standalone spreadsheet document'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'spreadsheet.getCell' or 'spreadsheet.listSheets,' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to check if user is working on a spreadsheet.' This indicates when to use the tool—to verify active spreadsheet status. It doesn't explicitly mention when not to use it or name alternatives, such as using other spreadsheet tools if a document is already confirmed active, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a check operation, implying it's read-only and non-destructive, which is helpful. However, it lacks details on behavioral traits like error handling, return format, or any side effects, leaving gaps in transparency 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 two sentences, front-loaded with the core purpose and followed by usage guidance. Every word earns its place, with no redundancy or fluff, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the purpose and usage context, but lacks details on return values or error cases, which could be helpful for an AI agent despite the low complexity. It meets basic needs but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add any parameter information, which is appropriate. A baseline of 4 is applied since it doesn't need to compensate for any schema gaps, but it's not a 5 because it doesn't enhance beyond 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 tool's purpose: 'Check if redo is available.' It specifies the verb ('Check') and the resource ('redo availability'), making it understandable. However, it doesn't explicitly differentiate from its sibling 'workflow.canUndo' beyond the 'redo' vs 'undo' distinction in the name, which is why it's not 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Call before redo to verify there are changes to restore.' This gives a specific scenario for when to use the tool. However, it doesn't mention when not to use it or explicitly name alternatives like 'workflow.redo' as a follow-up, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's behavior (creating groups with headers, layout options) and adds context like naming conventions and examples, but does not cover aspects such as error handling, permissions, or response format. This provides moderate transparency but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core functionality and followed by important details and an example. Most sentences earn their place, but the example could be slightly more concise. Overall, it is well-structured with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating grouped code nodes) and no output schema, the description is fairly complete. It covers the tool's purpose, usage guidelines, parameter semantics, and provides examples. However, without annotations or output details, it could benefit from more on behavioral aspects like error cases or response structure, but it is largely adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'groups' and 'layout' parameters. The description adds meaning by explaining the purpose of groups (organized with labels and files) and layout options (side-by-side or stacked), and provides naming conventions and examples that clarify parameter usage beyond the schema. This enhances understanding effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates code nodes organized in named groups with flow node headers, specifying that groups can be arranged horizontally or vertically. It distinguishes from siblings like 'code.create' and 'code.createBatch' by emphasizing the grouping and header features, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage through an example (organize files by folder structure like 'Controllers', 'Services', 'Models') and naming conventions for Next.js files, but does not explicitly state when to use this tool versus alternatives like 'code.create' or 'code.createBatch'. No exclusions or clear alternatives are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that values starting with '=' are treated as formulas, which is important behavioral information. However, it doesn't mention permission requirements, whether updates overwrite existing content, error handling, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste - the first establishes purpose and efficiency benefit, the second provides crucial formula handling information. Perfectly front-loaded with all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides good basic information but lacks details about permissions, error conditions, response format, and how it differs from similar tools like sheet.setData. The formula handling note is valuable but doesn't fully 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 the schema already fully documents both parameters (nodeId and cells). The description adds value by explaining formula handling ('Values starting with "=" are treated as formulas'), which provides semantic context beyond the schema's structural definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Set multiple cells'), the resource ('cells'), and the scope ('in one call - efficient for sparse updates'), distinguishing it from sibling tools like sheet.setCell (singular) and sheet.setData (bulk data setting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('efficient for sparse updates') and mentions formula handling, but doesn't explicitly state when NOT to use it or name specific alternatives like sheet.setCell for single updates or sheet.setData for dense updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait—the constraint against deleting the last sheet—which is crucial for safe operation. However, it doesn't mention other potential behaviors like error handling, permissions required, or whether the deletion is permanent, leaving gaps 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 action and includes a critical constraint. There's no wasted language, and it's appropriately sized for the tool's complexity, 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 moderate complexity (a destructive operation with a constraint), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers the main purpose and a key limitation, but lacks details on error cases, return values, or broader context like how this interacts with other spreadsheet tools, 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?
The input schema has 100% description coverage, so the schema already documents both parameters ('documentId' and 'index') adequately. The description doesn't add any additional meaning or context about these parameters beyond what's in the schema, such as explaining what 'index' refers to (e.g., zero-based). Baseline 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('a sheet'), and the scope ('from a standalone spreadsheet'), distinguishing it from siblings like 'sheet.deleteColumn' or 'sheet.deleteRow' which operate at a different granularity. It's specific and unambiguous 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the constraint 'Cannot delete the last sheet,' which implicitly guides when not to use this tool. However, it doesn't explicitly mention alternatives like 'spreadsheet.renameSheet' for modifying sheets instead of deleting, or prerequisites such as needing an existing spreadsheet with multiple sheets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a write/mutation operation ('Set'), but doesn't mention permission requirements, whether changes are reversible, error conditions, or what happens if the cell already has content. The formula syntax tip is helpful but insufficient for comprehensive behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides essential usage guidance. There's zero wasted language or redundancy, and the information is front-loaded appropriately.
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 5 parameters and no annotations or output schema, the description is adequate but has clear gaps. It covers the basic operation and formula syntax, but doesn't address error handling, permission requirements, or what the tool returns. Given the complexity of spreadsheet operations and lack of structured behavioral annotations, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 - it mentions the = prefix for formulas which is already in the value parameter's schema description. No additional parameter context or semantics are provided beyond what's in the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Set a single cell value'), the target resource ('in a standalone spreadsheet'), and distinguishes it from sibling tools like spreadsheet.setCellFormula (which sets formulas specifically) or spreadsheet.setData (which sets multiple cells). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Set a single cell value') and includes a specific usage tip about formula syntax ('Use = prefix for formulas'). However, it doesn't explicitly mention when NOT to use it or name alternatives like spreadsheet.setCellFormula for formula-specific operations or spreadsheet.setData for bulk updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool does (lists functions) and provides examples of function categories, but doesn't disclose behavioral traits like response format, pagination, or any limitations. For a read-only listing tool with zero annotation coverage, this is adequate but lacks depth.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The bulleted list of function categories adds useful detail without being verbose, though it could be slightly more streamlined by grouping categories more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete but could improve by specifying the output format (e.g., list of objects with function names and categories) or any limitations. It covers the what but not the how of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's output scope. This meets the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all available formula functions' with the specific verb 'List' and resource 'formula functions'. It distinguishes from sibling tools like 'spreadsheet.listFunctions' by specifying it's for 'Sheets' and listing example function categories, making it highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when needing to see all formula functions supported by Sheets, including standard Excel/Google Sheets functions. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to understand its application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's behavior as a read operation (list/show) and specifies what information is returned (sheet names, row counts, column counts). However, it doesn't mention potential limitations like pagination, error conditions, or whether it requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the main purpose and follow with specific details about what information is shown. Zero wasted words, appropriately sized for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one optional parameter and no output schema, the description provides adequate context about what the tool does and what information it returns. It could be more complete by mentioning the return format or any constraints, but given the tool's simplicity, it's mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description doesn't add parameter details beyond what the schema provides (documentId is optional, uses active if not provided). However, since there's only one optional parameter, the description's focus on the tool's core functionality without parameter clutter is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all sheets in a standalone spreadsheet document', specifying the exact scope. It distinguishes from sibling tools like spreadsheet.getData or spreadsheet.getCell by focusing on sheet metadata rather than content, and from spreadsheet.addSheet by being read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing sheet metadata (names, row/column counts) rather than content, but doesn't explicitly state when to use this versus alternatives like spreadsheet.getData for content or spreadsheet.listFunctions for functions. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions markdown and LaTeX support, which adds useful behavioral context beyond the schema. However, it doesn't disclose other important traits like whether creation is idempotent, what permissions are needed, or what happens on failure. For a creation tool with zero annotation coverage, this leaves gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by bullet points for use cases and a specific alternative. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (creation with 3 parameters), no annotations, and no output schema, the description does a good job by covering purpose, usage, and some parameter semantics. It could be more complete by addressing behavioral aspects like error handling or return values, but it provides sufficient context for basic use, especially with the schema's 100% 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%, so the schema already documents all three parameters (name, content, position). The description adds some value by clarifying that content supports markdown with LaTeX syntax ($...$ and $$...$$), which elaborates on the schema's description. However, it doesn't explain the 'position' parameter or provide additional context beyond what the schema offers, 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 tool creates a 'Text (documentation) node' with markdown and LaTeX support, specifying the verb (create) and resource (text node). It distinguishes from some siblings like 'code.create' by emphasizing documentation and mathematical content, though it doesn't explicitly differentiate from all text-related tools like 'text.setContent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it lists ideal use cases (documentation, formulas, rich text, plans) and gives a clear alternative for CodeBook context ('Use codebook.addCell('text') instead'). This directly addresses when to use this tool versus an alternative, which is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it initiates a connection request, triggers a permission dialog requiring user approval, and is a prerequisite for other tools. However, it doesn't mention potential outcomes (success/failure states), timeout behavior, or what happens after approval. For a zero-parameter authentication tool, this provides basic but incomplete 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 perfectly concise and well-structured: two sentences that directly state the action and its prerequisite role. Every word serves a purpose with no redundancy. It's front-loaded with the core purpose and follows with critical usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and when to use it. However, for an authentication tool, it could benefit from mentioning what 'connection' enables or typical next steps after calling it. The absence of output schema means the description doesn't clarify what the tool returns upon success/failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, and it appropriately doesn't mention any. Since there are no parameters to document, this earns a high score as the description focuses on behavior rather than redundant parameter explanations.
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: 'Request connection to Circuitry. Shows permission dialog in Circuitry for user approval.' It specifies the verb ('Request connection') and resource ('Circuitry'), and mentions the user interaction aspect. However, it doesn't explicitly differentiate from sibling 'circuitry.disconnect' or 'circuitry.status' beyond being the initial connection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this first before using other tools.' This clearly indicates when to use it (as an initial step) and implies it's a prerequisite for other operations. It effectively distinguishes it from alternatives by establishing its role in the workflow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a read operation (implied by 'Get'), returns a document target, and specifies fallback logic. However, it lacks details on error handling, permissions, or rate limits, which are important for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds necessary detail in the second. Every sentence earns its place by explaining the return behavior without waste, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieval with fallback logic), no annotations, and no output schema, the description is adequate but incomplete. It explains what is returned but not the format or structure of the return value, which could hinder an agent's ability to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately focuses on behavior and output without redundant param details, earning a high score as it adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Returns') and resources ('current target document'), and distinguishes it from siblings like 'documents.setTarget' and 'documents.clearTarget' by focusing on retrieval rather than modification. It explains what is returned (explicitly set target or fallback to most recently focused primary document).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'for operations' and the fallback behavior, which helps understand when to use it (e.g., to retrieve a target before performing other actions). However, it does not explicitly state when not to use it or name alternatives like 'documents.getRecent' or 'documents.getByType', missing full sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool lists components and specifies the context (current drawing layer, Designer mode with selected screen), which adds useful behavioral context. However, it lacks details on permissions, rate limits, or what the output looks like (e.g., format, pagination), leaving gaps in transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by a clarifying detail. Every word earns its place by providing essential context without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple list operation), no annotations, no output schema, and 0 parameters, the description is adequate but has clear gaps. It explains what the tool does and the context, but without annotations or output schema, it should ideally mention the return format or any limitations. It meets minimum viability but lacks completeness for full transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate. A baseline of 4 is applied as it compensates adequately for the lack of parameters by focusing on context and usage, though it doesn't exceed expectations by adding extra semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'HTML components in the current drawing layer', making the purpose specific and unambiguous. It further distinguishes from siblings by specifying the context of 'Designer mode' and 'currently selected screen', which helps differentiate it from other list tools like nodes.list or layout.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'in the current drawing layer' and 'In Designer mode, lists components on currently selected screen.' This gives explicit guidance on the operational context. However, it does not mention when not to use it or name specific alternatives among siblings, such as html.get or html.getByName for retrieving individual components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it creates a flowchart (implying a write operation), returns nodeIds for updates, and details node and edge properties with defaults and conventions (e.g., shape defaults, color meanings). It lacks information on permissions, error handling, or rate limits, but covers core functionality well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, followed by detailed parameter explanations. Every sentence adds value, but it could be slightly more concise by integrating some details into bullet points or reducing redundancy in the parameter explanations.
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 complexity (5 parameters with nested objects) and no annotations or output schema, the description is largely complete. It covers the tool's purpose, return value implications, and detailed parameter semantics for nodes and edges. However, it does not address all parameters (e.g., startPosition, spacing, autoLayout) or potential error cases, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the semantics of nodes and edges beyond the schema: it defines shape options with defaults, color conventions (e.g., red for problems), and edge handle usage for decisions. This clarifies parameter usage effectively, though it does not cover startPosition, spacing, or autoLayout parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a flowchart with nodes and edges on the canvas') and distinguishes it from sibling tools by mentioning the return value ('Returns nodeIds mapping for subsequent modifications via nodes.updateFlowchart'), which differentiates it from other nodes.* tools like nodes.add or nodes.update.
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 the return value for 'subsequent modifications via nodes.updateFlowchart', suggesting a workflow context. However, it does not explicitly state when to use this tool versus alternatives like nodes.add or chart.create, nor does it provide exclusions or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral effect ('Restores nodes, edges, and drawing data to the next state'), which indicates a mutation operation. However, it lacks details on permissions, side effects, or error conditions, leaving gaps 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 two concise sentences with zero waste, front-loading the core action ('Redo the last undone change') and efficiently explaining the restoration scope. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is adequate but minimal. It explains what the tool does but lacks details on return values, error handling, or prerequisites, making it complete enough for basic use but with clear gaps for advanced scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Redo the last undone change') and the resources affected ('nodes, edges, and drawing data'), distinguishing it from sibling tools like 'workflow.undo' and 'workflow.canRedo'. It precisely defines the tool's function 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by referencing 'last undone change', suggesting it should be used after an undo operation. However, it does not explicitly state when not to use it or name alternatives, though the presence of 'workflow.undo' and 'workflow.canRedo' as siblings provides some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral effect ('Switches to notebook-style linear view'), which is useful context about UI state change. However, it doesn't mention potential side effects, permissions needed, or error conditions, leaving gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the main action and follow with additional detail. Every word contributes to understanding the tool's purpose and effect, with no wasted text or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and the UI change, but for a tool that likely alters application state, it could benefit from mentioning prerequisites (e.g., requires an active workflow) or confirmation of success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's action. A baseline of 4 is applied since it efficiently handles the zero-parameter case without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Open CodeBook view') and the resource ('for the current workflow'), with the additional detail of switching to 'notebook-style linear view' that distinguishes it from other codebook tools like codebook.close or codebook.isOpen. It uses precise verbs and specifies the exact UI transformation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for the current workflow'), suggesting it should be used when a workflow is active, but it doesn't explicitly state when not to use it or name alternatives among siblings. It provides clear context but lacks explicit exclusions or comparisons to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the core behavior (replacing lines) and efficiency aspect, but lacks details on permissions, error conditions, or what happens if lines exceed bounds. For a mutation tool with zero annotation coverage, this is a moderate gap, though the efficiency context is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose and efficiency benefit, followed by a precise explanation of parameter interaction. Both sentences earn their place with no wasted words, making it highly efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by clarifying the tool's niche versus 'setCode' and explaining parameter semantics. However, it lacks details on return values or error handling, which would be beneficial given the absence of 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%, so the schema already fully documents the three parameters. The description adds some semantic context by explaining how 'startLine' and 'lines' interact ('Lines at startLine through startLine + lines.length - 1 will be replaced'), but this is largely implied 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.
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 ('Replace a range of lines in a code node') and distinguishes it from a sibling tool ('More efficient than setCode for partial updates'). It identifies both the verb (replace) and resource (lines in a code node), making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus an alternative: 'More efficient than setCode for partial updates.' This directly tells the agent to prefer this tool over 'code.setCode' when only updating a portion of the code, which is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves details (implying read-only) and mentions Designer mode behavior, but lacks information on permissions, rate limits, error handling, or return format. It adds some context but is incomplete for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a crucial usage note. Every sentence earns its place by providing essential information without redundancy, making it highly efficient 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 (read operation with one parameter) and no output schema, the description is mostly complete. It covers purpose, usage guidelines, and a key behavioral note, but could improve by hinting at the return structure or error cases. However, it's sufficient 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 (the 'id' parameter is described as 'Component ID'), so the baseline is 3. The description does not add further meaning beyond the schema, such as explaining ID format or examples, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full details of an HTML component including HTML, CSS, and JS content.' It distinguishes from siblings like html.list (lists components) and html.getByName (gets by name rather than ID), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs. alternatives: 'In Designer mode, searches currently selected screen - use screen.select first if needed.' This provides clear context for usage, including a prerequisite action (screen.select) and a specific mode (Designer mode), which helps the agent avoid errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the case-insensitive search behavior, the Designer mode constraint (searching only the currently selected screen), and the fact that it retrieves components by display name rather than ID. This provides good operational context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences that each earn their place: first states the core purpose, second adds search behavior and use case, third provides critical Designer mode constraint. No wasted words, and key information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description provides good contextual completeness. It covers purpose, usage context, behavioral constraints, and parameter examples. The main gap is the lack of information about return format or what happens when no component is found, but given the tool's simplicity and lack of output schema, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'name' already documented as 'Component display name (e.g., "Login Form")'. The description adds minimal additional semantic value beyond what's in the schema, mentioning examples like 'Login Form' or 'Navigation Menu' but not providing new parameter insights. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('HTML component'), and distinguishes it from sibling tools like 'html.get' (which likely requires ID) by specifying 'by its display name' and 'without needing to know the ID'. This makes the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to find components like "Login Form" or "Navigation Menu" without needing to know the ID') and includes an important behavioral constraint ('In Designer mode, searches currently selected screen'). However, it doesn't explicitly mention when NOT to use it or name alternatives like 'html.get' (which may require ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('Get'), but doesn't specify whether it requires authentication, has rate limits, or what format the row count is returned in. The description adds some context about the tool's purpose but lacks details about behavioral 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 perfectly concise with just two sentences. The first sentence states the core purpose, and the second provides usage guidance. Every word earns its place with zero wasted text, 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.
Completeness4/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 one well-documented parameter, the description is reasonably complete. It explains what the tool does and when to use it. The main gap is the lack of output information (no output schema), but for a tool that presumably returns a simple count, this is less critical than for complex operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'nodeId' clearly documented as 'Sheet node ID or name.' The description doesn't add any additional parameter information beyond what's already in the schema, so it 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 verb ('Get') and resource ('number of rows in a Sheet'), making the purpose explicit. It distinguishes this tool from other sheet-related tools like 'sheet.getRows' or 'sheet.getColumnCount' by focusing specifically on row count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'for planning pagination/chunked reads.' This gives clear context about its intended application scenario, helping the agent understand when this tool is appropriate versus alternatives that might retrieve actual row data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the indexing behavior (0-indexed, inclusive) which is valuable context beyond the schema. However, it doesn't mention performance characteristics, error conditions, or return format details that would be helpful for a read operation 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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality with precise technical details, and the second provides crucial comparative guidance. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description provides good context about when to use it versus alternatives and the indexing behavior. However, it doesn't describe what format the rows are returned in or any pagination/performance considerations that would be helpful given the 'large sheets' 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 fully documents all three parameters. The description adds no additional parameter information beyond what's in the schema. 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.
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 ('Get a range of rows') and resource ('from a Sheet'), with precise technical details (0-indexed, inclusive). It explicitly distinguishes from sibling tool 'getData' by stating 'Use for large sheets instead of getData,' providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use for large sheets') and when to use an alternative ('instead of getData'). This directly addresses the agent's decision-making by naming the specific sibling tool to compare against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool checks availability but doesn't disclose behavioral traits like what 'available' means (e.g., based on recent actions, user permissions), potential errors, or response format. It adds some context about the verification purpose but lacks depth on operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place by providing essential information without waste, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but could be more complete. It explains the purpose and usage but doesn't cover potential return values or edge cases (e.g., what happens if no workflow is active). For a simple check tool, it meets minimum needs but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as it avoids unnecessary details and focuses on the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('if undo is available'), distinguishing it from sibling tools like 'workflow.undo' and 'workflow.canRedo'. It explicitly defines what the tool does in a precise manner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Call before undo to verify there are changes to revert.' It directly addresses the alternative (calling 'undo' without checking) and specifies the prerequisite condition, offering clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavioral effect ('Ends the current MCP session'), which implies a destructive action, but lacks details on permissions, side effects, or what happens to active operations. This is adequate for a simple disconnect tool but misses deeper 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 front-loaded with the core action in the first sentence and adds a helpful follow-up about reconnection in the second. Every sentence adds value without redundancy, making it efficient 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 simplicity (0 parameters, no annotations, no output schema), the description is complete enough for a disconnect operation. It covers purpose, usage, and reconnection guidance, though it could benefit from more behavioral details like session cleanup or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, focusing on the tool's purpose and usage, which aligns with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Disconnect from Circuitry') and the resource ('current MCP session'), distinguishing it from siblings like 'circuitry.connect' and 'circuitry.status'. It explicitly mentions ending the session, which is a distinct purpose compared to other tools that manage connections or check status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool ('Ends the current MCP session') and includes a clear alternative ('Call circuitry.connect to reconnect'), helping the agent understand the context and sequence of operations without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the tool 'creates a linked node in the workflow and inserts it in the cell order,' which describes the mutation behavior. However, it doesn't mention permissions, error conditions, or what happens if CodeBook isn't open. For a creation tool with zero annotation coverage, this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear opening sentence, a bulleted list of cell types with brief explanations, and a final sentence for usage guidance. Every sentence adds value, and there's no wasted text. It's front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (creation tool with 3 parameters), no annotations, and no output schema, the description does well by explaining cell types and usage context. However, it doesn't describe the return value or error behavior, which would be helpful for a mutation tool. It's mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters well. The description adds value by listing and explaining the supported cell types in detail (e.g., 'Python/JavaScript code with execution' for code cells), which provides context beyond the enum values. However, it doesn't elaborate on 'afterCellId' or 'executionTarget' beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new cell to CodeBook') and specifies the resource ('cell'). It distinguishes from siblings by explicitly mentioning alternatives for workflow canvas (code.create, text.create, sheet.create). The verb 'add' is specific and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('preferred way to add nodes when CodeBook is open') and when to use alternatives ('For workflow canvas, use code.create, text.create, or sheet.create instead'). This gives clear 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's read-only nature ('Check') and implies it returns a boolean-like status, but doesn't specify the exact return format (e.g., true/false, open/closed state) or error conditions. It adds useful context about the CodeBook notebook view but lacks details on permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve a distinct purpose: the first states the tool's function, and the second provides critical usage guidance. There is no wasted language, and the most important information (checking if CodeBook is active) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-checking tool with no parameters and no output schema, the description is nearly complete. It explains what the tool does and when to use it, though it could slightly improve by specifying the return type. Given the low complexity and lack of structured output documentation, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage context, which aligns with the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('CodeBook (notebook view)'), and distinguishes it from sibling tools like 'codebook.open' and 'codebook.close' by focusing on status checking rather than state manipulation. It explicitly defines what 'active' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('When CodeBook is open') and when to use an alternative ('node creation should use codebook.addCell for proper cell insertion'), directly naming the sibling tool 'codebook.addCell' as the preferred alternative for a specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It effectively describes the return structure (fonts, colorPalette, buttons, patterns, theme) and the tool's read-only nature (implied by 'Get'), but lacks details on potential limitations (e.g., rate limits, authentication needs, or error conditions). However, it adds value by explaining the extracted data categories and their use in design 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 well-structured and front-loaded: the first sentence clearly states the purpose, followed by usage guidelines and a detailed breakdown of returned context in bullet points. The tip at the end adds practical value without redundancy. Every sentence earns its place, and there is no wasted text.
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 (0 parameters, no output schema, no annotations), the description is largely complete: it explains what the tool does, when to use it, and details the return structure. However, without an output schema, it could benefit from more specifics on return formats (e.g., data types), but the bullet points provide sufficient context for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately omits parameter details, focusing instead on the tool's purpose and output. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to explain non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Get design context (fonts, colors, patterns, buttons) extracted from all screens.' It specifies the exact resources (fonts, colors, patterns, buttons) and the scope (all screens), distinguishing it from siblings like 'designer.getActive' or 'designer.getMode' which focus on different aspects of design state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to understand the user's design style before generating HTML components.' It also names a specific alternative ('html.create') and includes a tip linking usage to that sibling tool, clearly differentiating it from unrelated siblings like 'screen.capture' or 'layout.analyze'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns documents ordered by recency, excludes specific document types, and reveals the purpose (showing what the user was last working on). However, it doesn't mention potential limitations like pagination, error conditions, or authentication requirements, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first explains what the tool does and its exclusions, the second provides the usage context. Every word contributes meaning without redundancy, making it front-loaded and appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 optional parameter, no output schema, no annotations), the description is largely complete. It explains the tool's purpose, behavior, and usage context effectively. However, without an output schema, it could benefit from briefly mentioning the return format (e.g., list of document objects) to fully compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 (the 'limit' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema, 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.
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 ('Get recently focused documents'), resource ('documents'), and scope ('ordered by most recent first, excludes chat, browser, and terminal documents'). It explicitly distinguishes this tool from sibling tools like 'documents.getByType' and 'documents.list' by specifying its unique focus on recent user activity with exclusions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'use this to determine which document the user is referring to.' It also implicitly suggests alternatives by mentioning exclusions (chat, browser, terminal documents), which helps differentiate it from other document retrieval tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses key behavioral traits: the tool returns a base64 PNG image, which implies it's a read-only operation (though not explicitly stated as safe). It doesn't mention potential side effects, rate limits, or authentication needs, but for a simple image capture tool, the description is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and output format, the second provides usage context. It's front-loaded with essential information and appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no output schema, no annotations), the description is complete enough. It explains what the tool does, when to use it, and the return format. For a simple image capture tool, this covers the necessary context without being overly verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents both parameters ('maxSize' and 'backgroundColor') with their defaults. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline 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.
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 ('Get the drawing layer as an image') and resource ('drawing layer'), distinguishing it from sibling tools like 'drawing.getActiveDocument' or 'image.create'. It uses precise terminology ('base64 PNG') and explains the purpose ('for visual interpretation').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when user sketches an idea and you need to "see" what they drew.' This provides clear context for invocation, differentiating it from tools that might manipulate drawings rather than capture them visually.
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 effectively discloses key behavioral traits: it removes an existing edge and creates new edges through inserted nodes, and specifies the structural impact (e.g., 'Source → NewNode → Target'). However, it lacks details on error handling, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by specific usage instructions in two clear sentences. Every sentence earns its place by providing essential operational guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the basic operation and parameters well but lacks information on return values, error conditions, or prerequisites. It is adequate for a tool with good schema coverage but incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic difference between 'node' (single insertion) and 'nodes' (chain insertion) with concrete examples, enhancing understanding beyond the schema's technical descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Insert node(s) between two connected nodes') and the resource ('existing edge'), distinguishing it from sibling tools like 'nodes.add' or 'edges.connect' by focusing on insertion between existing nodes with edge reconfiguration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides when-to-use guidance by specifying two distinct usage patterns (single insertion vs. chain insertion) and includes an alternative rule ('use OR nodes, not both'), though it does not mention when to choose this tool over other node-creation or edge-modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool updates code content, can show a diff UI with 'showDiff: true', and syncs to source files for EServer-sourced nodes. However, it doesn't mention potential side effects like error handling or permissions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with every sentence earning its place. It front-loads the core purpose, then provides usage guidelines and critical warnings in a bulleted format, making it easy to parse without unnecessary verbiage.
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 (mutation with 3 parameters) and lack of annotations or output schema, the description does a good job covering purpose, usage, and key behaviors. However, it doesn't detail the return value or error conditions, which could be important for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the 'showDiff' option's purpose ('to show inline diff UI for user to review/accept changes') and clarifying that 'code' should be the modified content from 'code.getCode'. This provides context beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Update code content in a code node') and distinguishes it from sibling tools. It explicitly contrasts with 'nodes.delete' for deleting entire nodes and references 'code.getCode' as a prerequisite step, making the purpose distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It specifies to use this for 'remove/add/change the X function' requests, not for deleting nodes, and gives concrete examples ('remove the power function' vs. 'delete the node') with corresponding alternative tools ('code.getCode' and 'nodes.delete').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the tool's behavior: it checks Designer mode status, returns document info if active, and returns null if not active. This covers the key behavioral aspects needed for a read-only status-checking 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 perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does, and the second provides crucial usage guidance. There's no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-checking tool with no parameters and no output schema, the description provides complete context about what it does, when to use it, and what it returns. The only minor gap is not explicitly mentioning the format of the 'current document info' returned, but this is reasonable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check if Designer mode is active' and 'get current document info') and distinguishes it from siblings by mentioning its role in determining Designer mode status before using screen.* or layout.* tools. It goes beyond a simple tautology of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this before calling screen.* or layout.* tools') and provides context on its purpose in checking Designer mode activity. This gives clear guidance on its role in the workflow relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool analyzes and fixes layout issues, can auto-apply fixes with 'autoFix: true', and returns 'appliedFixes' when autoFix is used. It also mentions using a selected screen if 'screenId' is not specified. However, it lacks details on error handling, performance implications, or what happens without autoFix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage guidelines, issues detected, workflow), uses bullet points for readability, and every sentence adds value without redundancy. It is appropriately sized and front-loaded with the core purpose, making it efficient and easy to scan.
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 no annotations and no output schema, the description does a good job covering the tool's purpose, usage, and parameters. It provides a workflow and links to siblings, but lacks details on output format (e.g., what 'appliedFixes' contains) and error cases. For a tool with 2 parameters and moderate complexity, it's mostly complete but could benefit from output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the practical use of 'autoFix: true' to automatically apply fixes and return appliedFixes, and implies 'screenId' is optional with a default (selected screen). It doesn't provide additional syntax or format details beyond the schema, but the context enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Analyze and fix layout issues after editing components') and distinguishes it from siblings by explicitly contrasting with 'layout.createSection' for initial creation. It provides concrete examples of issues detected (overlaps, misplacement, overflow, clipping), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'Use for' and 'Don't use for' sections, clearly stating when to use this tool (after edits to fix issues) versus alternatives (use 'layout.createSection' for initial creation). It also provides a workflow with step-by-step guidance, including when to use sibling tools like 'screen.capture' for verification.
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 full burden and does well by disclosing: 1) returns ALL matches with confidence scores, 2) content search limitations by node type (sheet: headers+100 rows, code: 1000 chars, etc.), 3) performance consideration for large sheets (>1000 rows skipped by default), and 4) that AI should decide relevance. It lacks details about error conditions or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with purpose statement first, followed by use cases, content search details, and performance considerations. Every sentence adds value - no redundant information. The bullet-point format for use cases and content types improves readability without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters and no output schema, the description provides excellent context about what gets searched, performance considerations, and return format (matches with confidence scores). It lacks details about the exact structure of returned results and any error scenarios, but covers most essential information an agent would need to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining: 1) natural language support for query parameter, 2) practical implications of includeLargeSheets (performance trade-off), and 3) context about what 'searchContent' actually searches (content limitations by type). However, it doesn't explain the 'types' parameter's valid values or 'limit' parameter's practical constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches workflow nodes by name or content and returns matches with confidence scores. It distinguishes itself from siblings like nodes.getByName (specific lookup) and nodes.list (no search) by emphasizing broad search functionality across multiple node types with relevance scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples ('the validation node', 'sheet with customer data', 'authentication code') and clear guidance on when to use includeLargeSheets parameter. It implicitly distinguishes from other search tools like layout.search by focusing on node content rather than layout elements.
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 full burden and does well by disclosing key behavioral traits: it captures visual content as a PNG, returns base64-encoded data, and specifies that Claude can analyze the output visually. However, it doesn't mention potential limitations like screen size constraints, performance implications, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by bulleted usage examples and output format details. Every sentence earns its place, and the information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides good coverage of purpose, usage context, and output format. However, it could be more complete by mentioning potential error conditions or limitations, such as what happens if the specified screen doesn't exist or if capture fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for its single parameter, but the description adds valuable context about the parameter's behavior: 'uses selected screen if not specified.' This clarifies the default behavior when screenId is omitted, which isn't captured in the schema description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('capture') and resource ('Designer screen'), specifying the output format ('PNG image'). It distinguishes from siblings like screen.get, screen.list, or screen.update by focusing on visual capture rather than metadata retrieval or modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: 'Use this to verify layouts and catch visual issues like: - Clipped content - Poor contrast - Overlapping elements - Sizing problems.' This gives clear guidance on when to use this tool versus other screen-related tools that handle creation, deletion, or metadata operations.
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. It discloses key behavioral traits: it's a read operation (implied by 'Get'), returns structured data about selections, and specifies that it returns an empty array if nothing is selected. However, it doesn't mention error handling, performance, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage context and return behavior. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 (simple read operation with no parameters), no annotations, and no output schema, the description is mostly complete. It explains what the tool does, when to use it, and the return behavior. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of the array), but it's adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on purpose and behavior. A baseline of 4 is applied since it compensates well for the lack of parameters by providing clear context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('currently selected nodes and what is selected within them'), with specific examples of node types (cells in sheets, text in code/text/agent nodes). It distinguishes from siblings like 'workflow.getActive' or 'workflow.getNodeSummary' by focusing on selection context rather than active workflow or node summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'to understand what the user is referring to when they say "this", "what does this do?", "explain this", etc.' This provides clear context for usage, and the mention of returning an empty array if nothing is selected helps set expectations, though it doesn't name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and excels by adding rich context beyond basic functionality. It details critical behavioral traits such as CSS structure rules to prevent bugs, mobile UI sizing guidelines, and post-creation steps like using 'layout.analyze' for fixes. This provides comprehensive insights into how the tool behaves and should be used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like DESIGNER MODE, WORKFLOW context, and CRITICAL CSS STRUCTURE, but it is lengthy and includes some information that might be excessive (e.g., specific pixel sizes for iPhone 15). While informative, it could be more concise by focusing only on essential guidance without overloading details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no annotations, no output schema), the description is highly complete. It covers purpose, usage guidelines, behavioral traits, parameter semantics, and post-invocation steps. It addresses multiple contexts (Designer vs. Workflow) and provides practical advice, making it sufficient for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantic context beyond the schema. For example, it explains the 'target' parameter's workflow context and advises to 'ASK USER if unclear,' and it clarifies the 'container' parameter's semantic meaning in Designer mode. However, it doesn't cover all parameters in depth, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create HTML content in Circuitry.' It specifies the verb ('Create') and resource ('HTML content') and distinguishes it from sibling tools like 'layout.createSection' by explaining when to use each, making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines, including when to use this tool versus alternatives (e.g., 'Use `layout.createSection` instead!' for Designer screens), context for two target options ('drawing' or 'node'), and prerequisites like asking the user if unclear. It clearly outlines when and how to apply the tool in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It excels by detailing behavioral traits: it ensures proper parent-child structure and vertical stacking, prevents zoom scaling bugs with specific CSS rules, requires opaque backgrounds for headers/footers, handles auto-positioning based on container, and returns both layoutId and htmlId for future reference. This covers creation, styling constraints, and output behavior comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose and key benefits. It uses bold text and code blocks effectively to highlight critical information. While it's detailed, every sentence earns its place by providing essential guidelines, examples, and warnings. A slight deduction to 4 due to the length, but it remains focused and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 10-parameter tool with no annotations and no output schema, the description is highly complete. It covers the tool's purpose, usage scenarios, behavioral details, parameter semantics, and output information (returns layoutId and htmlId). It addresses potential pitfalls and provides practical examples, making it sufficient for an agent to understand and invoke the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the semantic use of the 'container' param for auto-positioning (header, footer, content) and providing context for 'position' and CSS-related parameters through examples and guidelines. However, it doesn't deeply elaborate on all 10 parameters, keeping it at a 4 for meaningful but not exhaustive enhancements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it's the 'PREFERRED METHOD for creating HTML in Designer mode' that 'Creates both a layout container AND an HTML component inside it together.' It distinguishes itself from siblings like 'layout.create' or 'html.create' by emphasizing the combined creation with proper structure and positioning, which is specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it's preferred for HTML creation in Designer mode, specifies when to use the 'container' param for auto-positioning (header, footer, content), and offers alternatives like manual positioning with 'position.x'. It also includes critical exclusions, such as avoiding styles on :host to prevent bugs, ensuring headers/footers have opaque backgrounds, and centering narrow cards.
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:

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

Score Badge

Copy to your README.md:

[![circuitry-mcp-server MCP server](https://glama.ai/mcp/servers/circuitry-dev/circuitry-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/circuitry-dev/circuitry-mcp-server)

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/circuitry-dev/circuitry-mcp-server'

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