figma-slides-mcp
Server Quality Checklist
Latest release: v0.1.2
- Disambiguation4/5
Most tools have clearly distinct purposes, with each targeting a specific resource or action. Some overlap exists between creation tools (create_node, create_table, render_svg, render_d3, etc.), but descriptions clarify intended use cases.
Naming Consistency4/5The vast majority follow a verb_noun pattern (e.g., create_slide, delete_node, set_text). A few outliers like batch_operations, connection_status, and render_d3 use nouns or library names, causing minor inconsistency.
Tool Count1/558 tools is an extreme number for an MCP server, far beyond the typical well-scoped range. While the domain is complex, this many tools creates a heavy surface area that is difficult for agents to navigate efficiently.
Completeness5/5The toolset provides comprehensive coverage of slide lifecycle, node manipulation, text, tables, media, rendering, viewport, selection, and export. No significant gaps are apparent, and the inclusion of batch operations and session management rounds out the surface.
Average 3.4/5 across 58 of 58 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It is a bare one-liner that reveals nothing about side effects, error cases, index-out-of-bounds behavior, or whether the row is appended or inserted at a specific position. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is essentially a tautology of the title ('Insert Table Row' vs 'Insert a row into a table'). It wastes the opportunity to add value, and while it is not bloated, it is under-specified to the point of being unhelpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool's context (sibling tools for table manipulation, multiple row/column operations), this description is grossly incomplete. It has no annotations, no output schema, and leaves both parameters unexplained. An agent would have no way to correctly invoke this tool beyond guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter ('tableId' or 'index'). It fails to explain what 'tableId' refers to, what 'index' controls (insertion position?), or whether 'index' is optional. The description adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Insert') and resource ('a row into a table'), clearly indicating the action. It implicitly distinguishes from sibling tools like 'insert_table_column' and 'create_slide_row' by focusing on 'table' and 'row'. However, it does not explicitly name alternatives, so it loses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., an existing table), context, or exclusions. The description simply restates the action without any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description does not disclose whether this replaces the current selection, whether it is additive, or what the side effects are. It only restates the tool's name in different words, offering no behavioral detail beyond the schema's nodeIds parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, which is not overly verbose, but it is under-specified rather than effectively concise. It lacks the structural detail needed to be a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description fails to explain important context such as what the selection is used for, whether the tool has a return value, and how it relates to the editor state. Even though the parameter set is simple, the description is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention nodeIds, its array format, or required status. The agent gets no extra semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select specific nodes' uses a clear action verb ('select') and identifies the resource ('nodes'), and the word 'specific' implies nodeIds are used to target particular nodes. It distinguishes from the sibling 'get_selection' by indicating a setter rather than a getter, though it does not explicitly say it replaces the current 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It does not tell the agent when to prefer set_selection over get_selection or find_nodes, nor 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden but offers only a terse statement of the action. It does not disclose side effects, requirements (e.g., valid slide/theme IDs), or behavior when the operation fails, leaving the agent without critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and merely restates the title, providing no additional structured information. It is concise but under-specified, lacking the detail that would make it useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is still too sparse. It omits return value information, error behavior, and the relationship to available themes, leaving the agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain slideId or themeId. Their meaning is only inferable from their names, which is insufficient for agents to correctly supply parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (apply) and the target (theme to a slide), making the tool's purpose evident. While it doesn't elaborate on the scope or distinguish it from sibling tools like list_themes, the verb and object are specific enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 whether themeId should be obtained from list_themes or how it interacts with other slide-level operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states the action without explaining whether existing content is overwritten, how formatting is affected, or what the response/return value looks like. The mutation semantics are implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is compact, but it is under-specification rather than effective conciseness. It omits crucial details about the five parameters and behavioral semantics, making it too minimal for practical use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, a nested object, and no output schema, the description is severely incomplete. It does not mention coordinate system conventions, whether row/col are zero-indexed, what props accepts, or any return behavior, leaving agents without enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter explanations. It fails to explain the tableId, row, col, or props parameters, and the props object is entirely undocumented. The only implicit reference is to 'text', but even that is not explicitly mapped to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set text of a table cell' uses a specific verb and resource, making the core function clear. It distinguishes from sibling tools like set_text and get_cell_content by targeting table cells specifically, 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/5Does 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 set_text or get_cell_content. The description gives no context about table-specific editing workflows, prerequisites, or cases where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the action without any details about side effects, such as whether deletion is permanent, how it affects row indices or cell references, or any permissions required. This is a significant gap for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is easy to read and front-loaded. However, it is under-specified given the lack of parameter descriptions and behavioral context. It earns its place but does not leverage the brevity to add needed details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 required parameters, no output schema, and no annotations, the description is too sparse to be considered complete. It fails to clarify important aspects like how the row is identified, return behavior, or error conditions. The tool is simple but still requires more context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. It doesn't explain what 'index' represents (e.g., zero-based, row number), or what 'tableId' refers to beyond the name. The description fails to compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a row from a table' clearly identifies the action (remove) and the target resource (a row in a table). It distinguishes from sibling tools like delete_table_column by specifying 'row', and from insert_table_row by stating 'remove'. While it doesn't elaborate on which table or how the row is identified, this is sufficient for basic purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 it's appropriate, prerequisites (e.g., table must exist), or situations where other operations like delete_table_column or clear_slide might be more suitable. No contextual hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only implies mutation via the word 'replace'. It does not disclose whether the operation is destructive, whether it requires existing media, what happens to the old content, or any side effects. For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is appropriately front-loaded, but it is so sparse that it sacrifices necessary context, making it not fully effective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no annotations, and no output schema, the description should reveal the role of 'data' and any constraints. It only provides a high-level action, leaving the tool's proper invocation unclear. The ambiguity of 'data' as an array of numbers makes this significantly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain the 'data' parameter (an array of numbers) or 'nodeId' beyond obvious type names. No parameter-level meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces media content on a video/image node, using a specific verb and resource. It is not ambiguous, though it does not explicitly differentiate from siblings like 'place_image' or 'create_video', which also deal with media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The description only says what it does, with no mention of scenarios, prerequisites, or exclusions. This is a complete lack of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention the irreversible nature of deletion, potential side effects on the table structure, or any other operational details beyond the verb 'Remove'. This leaves agents unaware of important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it largely restates the tool name ('delete table column' vs 'Remove a column from a table'), providing little added value despite being well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given 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 inadequate. It omits parameter details, prerequisites, and consequences, making it impossible for an agent to fully understand the tool's behavior or invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain tableId or index. It adds no meaning beyond the parameter names, leaving ambiguity about index type (zero-based?) or the exact identifier used for tableId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a column from a table' uses a clear verb and resource, and it distinguishes itself from siblings like delete_table_row and insert_table_column by specifying the column deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only states the action without context, prerequisites, or exclusions, offering no help in 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?
There are no annotations, so the description must disclose behavioral traits, but it does not. It fails to mention side effects, reversibility, coordinate system, zoom units, or whether the change is temporary or persistent. The description only restates the core action without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the verb and resource. It is appropriately sized for the tool's simplicity, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of annotations, output schema, and parameter documentation leaves the description incomplete. It does not tell the agent how to interpret the coordinate system or zoom scale, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for parameters, so the description must compensate. It only repeats the parameter names 'center' and 'zoom' without explaining what values they accept (e.g., zoom as a multiplier, center in pixels) or whether both are required. This adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and clearly identifies the resource 'editor viewport' with what is being set ('center and zoom'). It is distinct from most siblings but does not explicitly distinguish itself from 'zoom_to_fit', which also affects the viewport, so it loses a point for lack of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided beyond the basic action. There is no mention of when to use this tool versus a sibling like 'zoom_to_fit', nor any prerequisites or context about how it fits into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the basic action but fails to disclose side effects like whether existing columns shift, whether the operation is reversible, or permission requirements. For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff or redundancy. It is appropriately sized, though it could add more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a mutation tool with no annotations and no output schema. It does not clarify the role of 'index', potential effects on existing data, or return behavior, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it does not explain parameters. The parameter names 'tableId' and 'index' are somewhat self-explanatory, but the description does not clarify that index determines insertion position or its zero-based nature, leaving syntax ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and resource ('a column into a table'), clearly conveying the tool's action. It differentiates from siblings like insert_table_row by specifying 'column'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when inserting a column is appropriate, nor any exclusions or prerequisites such as requiring an existing table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the generic action and gives no details about side effects, whether the slide is moved or copied, failure conditions, or how the move interacts with the existing row order. This is minimal and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and to the point, effectively using the limited words to state the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, this description is too thin. It lacks important contextual details such as whether the move is relative, how the index positions the slide, what happens to the previous row, and any return values. The description is far from complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), and the tool description adds no parameter-specific meaning. The names slideId and rowId are self-explanatory to some degree, but the description does not explain their roles or the optional index parameter. The description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a slide') and the target ('to a different row'), providing a specific verb and resource. However, it does not differentiate this tool from siblings like reorder_slides or reparent_node, so it misses the explicit distinction needed for 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., existence of the row), ordering semantics, or any exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions creation and the text label but does not disclose side effects, permissions, reversibility, return values, or whether existing text is overwritten. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core action in the first sentence and useful examples in the second. It avoids fluff, though the second sentence is fragmentary. It earns its place with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has four parameters including a nested object, no annotations, and no output schema. The description is too sparse to compensate, lacking details on props, parentId usage, supported shape list completeness, and any behavior after creation. An agent would need additional context to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists some shapeType values, adding value there, but does not explain parentId, text, or props. These parameters are left underspecified, and the nested props object is not described at all, making it hard for an agent to pass correct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'shape with built-in text label', distinguishing it from create_node or set_text. The addition of shapeType examples further clarifies the tool's scope, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like create_node or set_text. It implies usage for shapes with text labels but does not state exclusions or mention when to prefer another tool, leaving the agent without decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says 'navigate' without explaining side effects (e.g., whether the slide becomes selected, whether the viewport moves, or what happens if the slideId is invalid). This lack of detail is a significant gap for a tool that affects editor 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is nearly sufficient, but the lack of behavioral transparency and usage guidance leaves gaps. The agent knows the target and action but not the broader context or consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the slideId parameter, but it only uses the vague phrase 'a specific slide.' No additional meaning is added beyond what the parameter name already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Navigate') and the resource ('a specific slide in the editor'), which distinguishes it from sibling tools that get or set slide properties. It lacks explicit mention of changing the current view or selection, but 'navigate' conveys the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_viewport or get_slide_grid. It merely states what the tool does, leaving the agent to infer usage from the name and description without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing side effects. It merely states the action without mentioning whether grouping creates a new node, modifies existing parent-child relationships, or requires specific permissions. This is a significant transparency gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording, earning its place. However, it is under-specified, reflecting a lack of substance rather than deliberate efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse to fully understand the tool's behavior. It does not explain what 'grouping' entails, the role of parentId, or the expected outcome, leaving significant context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (nodeIds and parentId) with 100% coverage, so the description adds no parameter-level meaning. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Group multiple nodes together" clearly states the action (grouping) and the resource (nodes), which distinguishes it from the sibling tool ungroup_node. However, it lacks detail about the resulting structure (e.g., creating a new parent group node) that would fully disambiguate its 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/5Does 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 ungroup_node or reparent_node. The description is purely behavioral with no mention of contexts, 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, the description carries the full burden, but it only states the top-level intent. It discloses no behavioral traits: no mention of whether it animates, modifies the camera across slides, affects selection, or has side effects. This is a significant gap for a tool that alters the viewport.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential scoping distinction. Every word earns its place, and there is no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low parameter count and lack of output schema, the description omits crucial context: it does not state what 'fit' means visually, which slide/viewport is affected, or whether the fit is immediate or animated. Given that no annotations compensate, the description is incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines nodeIds as an array of strings with no description. The description adds meaning by implying that providing specific node IDs fits those nodes, while omitting them fits all content. However, it does not explicitly link 'nodeIds' to the parameter or clarify the empty-array behavior, so it partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('zoom to fit') and the two target scopes ('specific nodes or all content'), distinguishing the core function from siblings like set_viewport that manually position the view. It could more explicitly differentiate from that sibling, but the verb+resource+scope is specific enough for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_viewport or focus_slide. It does not mention exclusions, prerequisites, or that this tool is best for fitting content vs. fine-grained viewport control, so there is no practical 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, leaving the description to carry the transparency burden. It does disclose that the operation is slide-only and may have limited support, but it does not explain the mutation behavior (e.g., what 'node' means, how data is used, whether it modifies the slide, or any side effects). This is insufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It quickly states the core action and caveat. However, its brevity borders on under-specification rather than genuine conciseness, though there is no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation with two parameters, yet the description omits crucial details such as the meaning of 'data', the expected parentId type or relationship, and any return behavior. With no annotations or output schema, an agent would struggle to invoke it correctly without further exploration. The 'limited support' caveat is not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's two parameters (parentId and data) are entirely undocumented with 0% description coverage. The description does not mention or explain either parameter; 'Slides only' only weakly implies parentId should be a slide reference, and 'data' as an array of numbers is left unexplained. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action and resource: 'Create a GIF node'. It adds a scope constraint ('Slides only') that differentiates it from generic node creation tools like create_node. However, the phrase 'may have limited support' is vague and doesn't fully clarify what a GIF node is or how it differs from other media nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: 'Slides only' indicates this tool is intended for slide contexts. It also warns about limited support, suggesting caution. However, it does not explicitly name alternatives or say when to prefer create_gif over create_video or create_node, leaving the usage decision partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the action ('create a table') without mentioning side effects, required permissions, return value, or dependency on parentId. For a mutation tool, this is a significant gap. It does not contradict any annotations, but it adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It conveys the essential purpose and platform restriction efficiently, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is severely underspecified. It lacks parameter explanations, relationship to sibling table tools, and behavior details. The only contextual element is the 'Slides/FigJam only' restriction. This is inadequate for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description mentions none of them. The agent must rely solely on parameter names like parentId, rows, cols, cellWidth, and cellHeight, which is insufficient for correctly invoking the tool. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'create' and a clear resource 'table', with the qualifier 'Slides/FigJam only'. This distinguishes it from sibling tools like insert_table_row, insert_table_column, and set_cell_content, which operate on existing tables. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new table is needed, and the 'Slides/FigJam only' restriction provides a platform exclusion. However, it does not explicitly mention alternatives (e.g., using insert_table_row for adding rows later) or when NOT to use this tool beyond the platform limitation. Guidance is minimal and implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. This description only states the basic operation and does not disclose return format, error handling, or edge cases like out-of-bounds coordinates. It adds no behavioral context beyond what the tool name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easy to parse, appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three required parameters, no annotations, and no output schema, the description is too sparse to be complete. It fails to explain parameter semantics, return values, or usage context, leaving significant gaps that could confuse an agent attempting to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is responsible for compensating, but it does not explain any parameters. It does not clarify whether row/col are zero-indexed, what format tableId expects, or what the return value looks like. This leaves the agent without meaningful parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read text of a table cell' uses a specific verb (read) and resource (table cell), making it clear what the tool does. It also distinguishes itself from the sibling 'set_cell_content' by clearly indicating a read operation rather than a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to read text from a cell, but it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions. It is a self-contained read operation, but there is no mention of alternatives or when-not-to-use, so it relies on implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'Set the order', implying a replace operation, but does not specify whether all row IDs must be included, what happens to omitted rows, or whether the operation is atomic or reversible. For a mutation tool, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the verb and object. It is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, but lacks usage guidance and behavioral transparency. Given no annotations or output schema, the description should clarify whether rowIds must be a complete ordering or a partial update, and what the result is. This gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter rowIds ('Row IDs in desired order'). The description reinforces this by mentioning 'slide rows' but adds little extra meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Set' with the resource 'order of slide rows in the deck', clearly stating the action. However, it does not explicitly differentiate from sibling tools like move_slide_to_row, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to alternatives such as move_slide_to_row or set_slide_transition. The description gives no context on prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without explaining what 'skipped' means, whether the change is reversible, or if it affects presentation mode. This is inadequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal schema descriptions, the tool description is too sparse to fully inform an agent. It lacks context on what it means to be skipped, parameter semantics, and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters at all, and the schema has no descriptions. While slideId and isSkipped are self-naming, the meaning of isSkipped (true/false) and the relationship to the action are not clarified. Schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Mark' with a clear resource 'slide' and state 'skipped', distinguishing it from sibling tools like set_slide_transition or set_slide_theme. It clearly states the action in the context of a presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as delete_slide or hide_slide. There is no mention of use cases, 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 does not mention return type, whether the export is a download/URL/base64, scale behavior, or any side effects. The description only lists formats, leaving important operational details undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the core capability and supported formats. Every word earns its place; there is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, there is no output schema and no annotations, so the description should explain what the caller receives and any relevant conditions. It also fails to clarify how this differs from the screenshot and media-creation siblings. The information provided is minimal and leaves important gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents scale and format with defaults, covering 67% of parameters. The description adds little beyond 'any node' to clarify the required nodeId, but the parameter name and schema context make it reasonably clear. It does not meaningfully compensate for the undocumented nodeId, but the coverage is not critically low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export'), the target resource ('any node'), and the supported output formats ('PNG, JPG, SVG, or PDF'). This is a specific verb+resource pair that distinguishes it from sibling tools like screenshot_slide or create_gif.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over alternatives. Several sibling tools produce image/media outputs (e.g., screenshot_slide, create_gif, create_video), but there is no mention of when export_node is preferred or when another tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core move operation without mentioning side effects, such as whether the node is removed from its old parent, how the optional index affects positioning, or if the operation is reversible. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word earns its place, making it maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation, the schema and description together cover the basics, but the absence of annotations, output schema, and any behavioral caveats leaves the description thin. It does not clarify edge cases like reparenting to the same parent or the meaning of the optional index in context, making it barely adequate for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (nodeId, parentId, index) are fully documented in the schema. The description adds no additional parameter information, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the clear verb 'Move' with the resource 'node' and specifies the target 'a different parent container', which precisely defines the operation. This clearly distinguishes it from sibling tools like ungroup_node, which removes a node from a group rather than moving it to a new parent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 ungroup_node or group_nodes. It lacks any explicit or implicit usage context, leaving the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions the slide is empty and fixed at 1920x1080, but does not disclose what happens to the presentation (e.g., where the slide is added), any side effects, or required permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasteful words. It efficiently conveys the core purpose and a key constraint (fixed resolution).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters and no output schema, and the description covers the basic behavior. However, it lacks guidance on the slide's placement in the presentation and any implications for the surrounding context. The schema fills in parameter details, but the description itself is minimal and leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter documented in the schema (e.g., fills, themeId, rowIndex). The description itself adds no parameter-specific meaning, so baseline 3 is appropriate. The schema descriptions are brief but provide adequate semantic info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new empty slide', and adds the specific constraint 'fixed 1920x1080'. This distinguishes it from siblings like duplicate_slide or create_slide_row, which create different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as duplicate_slide, create_slide_row, or other creation tools. There is no context about prerequisites or placements, so the agent gets no help in selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to disclose safety or side effects, so the description must carry the burden. It only states 'Remove a node,' implying a destructive action, but does not mention irreversibility, what happens to child nodes, connections, or undo behavior. This is significant behavioral information absent from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words or filler. It is appropriately sized for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description is minimally adequate but lacks important contextual details such as error behavior, whether the node must exist, or side effects on related nodes. It does not mention if the operation is reversible or what the expected result is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter (nodeId: 'Node ID to delete'), so the schema already explains the parameter fully. The description adds no additional parameter semantics beyond the schema, but this is acceptable given the high coverage and simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a specific resource ('a node from the canvas'), making the tool's function immediately clear. It also distinguishes itself from sibling tools like ungroup_node, reparent_node, and clone_node by clearly indicating deletion rather than structural changes or duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives. For example, there is no mention of whether to use batch_operations for multiple deletions, or whether ungroup_node should be considered first. The description provides no context about 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 present, so the description must fully disclose behavioral traits. It states the deletion but does not indicate permanence, side effects on slide content or child elements, or whether the action can be undone. For a mutating operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and immediately conveys the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description and schema together cover the basic invocation needs. However, with no annotations, no output schema, and no mention of side effects or error conditions, the description is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with slideId described as 'Slide to delete'. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' and identifies the resource 'a slide from the deck', making the action unambiguous. It also distinguishes itself from sibling tools like clear_slide and delete_slide_row, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings such as clear_slide and delete_slide_row, the description does not explain situations where delete_slide is preferred or when other tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full responsibility. 'Clone a slide with all content' indicates the action but does not disclose side effects such as placement of the new slide, whether the original remains unchanged, or what happens to slide properties and notes. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence, front-loaded with the verb 'Clone'. There is zero waste and it is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema. The description adequately states the action, but it does not mention what the tool returns (e.g., new slide ID) or where the duplicate is inserted. This missing context prevents a higher score, yet it remains minimally usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents slideId with description 'Slide to duplicate', giving 100% coverage. The tool description adds no parameter-specific information beyond the general 'all content' context, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'clone' with resource 'slide' and adds scope 'with all content'. This clearly distinguishes it from create_slide (new slide) and clone_node (clone a node).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. It does not mention sibling tools or exclusions, leaving the agent to infer when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the basic operation and does not disclose critical behaviors such as whether child nodes are recursively cloned, whether the new node gets a new ID, or what happens if parentId is invalid. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly structured sentence that front-loads the core action ('Duplicate a node') and uses no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description should offer more behavioral context. It omits important details like the scope of the duplication (children/properties) and the return value, making it only minimally sufficient for a 2-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description's mention of 'optionally reparenting' adds no information beyond the parentId parameter's description, and neither describes edge cases or value formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'duplicate' with the resource 'node' and adds the optional reparenting behavior, clearly distinguishing it from sibling tools like reparent_node (which changes parent of an existing node) and duplicate_slide (which targets slides).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for copying nodes, but it does not explicitly state when to prefer this over create_node, reparent_node, or other alternatives, nor does it mention exclusions or prerequisites. The 'optionally reparenting' clause hints at a use case but provides no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly says 'Read', which clarifies that the operation is safe and non-mutating. However, it does not explain what 'common' properties are, how invalid property names are handled, or whether the response format differs between 'all' and 'specific' modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that conveys the core function without any filler. Every word is meaningful, and it is immediately front-loaded with the verb 'Read'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is incomplete. It does not explain what the tool returns (format of properties), what 'common' properties are, or what happens if the nodeId is invalid. Sibling tools like get_text_content have more specific scope, but this description does not help the agent decide when to use it or what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'properties' parameter has a description, while 'nodeId' does not. The tool description adds minimal meaning beyond the schema—it reiterates the 'all or specific' behavior but does not clarify the nodeId parameter or compensate for its missing schema description. Since nodeId is self-explanatory, the score stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read' and the resource 'properties of a node', distinguishing it from sibling tools like set_properties (which writes). It also specifies the scope ('all or specific'), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_text_content or get_node_tree. The description gives no contextual clues about appropriate scenarios, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states the action without revealing side effects, persistence, or whether it affects the current slide or all slides. There is no mention of reversibility or any impact on other editor state, making the behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action. Every word is informative—'Switch between grid and single-slide view'—with no filler or redundancy. It is optimally structured for quick parsing by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one enum parameter and no output schema, so the description covers the core functionality adequately. However, it does not provide any contextual guidance about when to use this tool or how it relates to sibling tools like focus_slide or set_viewport. For a tool of this simplicity, missing such guidance is a minor gap, hence a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the 'mode' parameter has an enum and description 'View mode'. The tool description does not add meaning beyond what the schema already provides; it merely restates the two enum values. Baseline 3 is appropriate when schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch between grid and single-slide view' uses a specific verb ('switch') and clearly identifies the resource (slides view) and the two possible modes. It distinguishes from sibling tools like get_slide_grid (which retrieves grid data) and set_viewport (which sets coordinates), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or typical scenarios. For example, it does not contrast with get_slide_grid or focus_slide, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details beyond the action itself, such as effects on existing rows, index handling, or permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the core purpose; however, it lacks usage context and behavioral details, which is acceptable for a simple tool but leaves some gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, covering the 'index' parameter as 'Position in grid'. The description itself does not add extra parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('slide row') and location ('deck grid'), distinguishing it from sibling tools like create_slide or delete_slide_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives, such as delete_slide_row or move_slide_to_row. Usage is only implied by the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the Slides-only scope and supported formats, which is useful. However, it does not explicitly state that this is a mutating operation (though 'create' implies it), nor does it reveal behavior like network fetching for URLs or handling of invalid bytes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs the essential details: action, source, scope, and formats. Every word contributes value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and no output schema, the description is too sparse to be complete. It omits the meaning of the required parentId, the positioning/sizing parameters, and any error or return behavior. The context is insufficient for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, yet the description only adds meaning for url and data via 'from URL or bytes' and the format list. It fails to explain the required parentId or the optional positioning parameters (x, y, width, height), leaving most parameters semantically under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('video node'), and the input sources ('from URL or bytes'). It also specifies the scope ('Slides only') and formats ('MP4/MOV/WebM'), which distinguishes it from sibling tools like create_gif or place_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding videos to slides and specifies format restrictions, but it does not explicitly state when to use this tool versus alternatives. There is no mention of prerequisites or when not to use it, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing effects. It does not mention that setting a transition overrides any existing transition, whether it is reversible, or what happens on invalid input. The list of styles is helpful but does not explain behavioral outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no filler. The imperative verb 'Set' and the enumerative list are immediately informative and space-efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the key parameter values, but omits context about other parameters (curve, timing, duration) and return behavior. Since no output schema exists, the description should hint at what the tool accomplishes beyond setting a style, but it is adequate for a simple setter with schema defaults documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value for the 'style' parameter by enumerating valid values, which the schema only calls 'Transition style'. Other parameters (curve, timing, duration) have defaults in the schema, and although not mentioned in the description, the 80% schema coverage mitigates the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a transition, enumerating the specific allowed styles (DISSOLVE, SLIDE_FROM_*, PUSH_FROM_*, SMART_ANIMATE, NONE). This distinguishes it from sibling tools, none of which handle slide transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, prerequisites, or alternatives. It merely lists transition styles without explaining context, such as requiring a slide to exist or how it relates to presentation mode. There are no exclusions or situational hints.
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 must carry the burden of behavioral disclosure. It offers one useful behavioral trait: 'Font loading is automatic.' However, it does not mention whether existing text is replaced, how errors are handled, or any permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the core purpose, the second adds a relevant behavioral note. Every word serves a function, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with well-documented parameters, but the description lacks context about behavior on missing nodes, whether the operation is an overwrite or append, and how it integrates with font selection. The automatic font loading note helps but does not fully cover the behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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. The description adds no additional meaning to nodeId, text, or fontName beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the text content of a text node, using a specific verb ('set') and resource ('text node'). This distinguishes it from siblings like set_text_range_style (which styles text ranges) and get_text_content (which reads text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 set_text_range_style or create_shape_with_text. The description simply states what it does without any contextual or exclusionary notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main effect—returning children to parent—which adds context beyond the tool name. However, with no annotations, it carries the full burden and does not specify whether the group node itself is removed, if the operation is reversible, or any side effects on nested groups.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is concise and front-loaded, immediately stating the action and consequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one fully-described parameter and no output schema, the description covers the essential action but omits potentially important details like what happens to the group node after ungrouping. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description 'Group node to ungroup' already explains the parameter. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ungroup a group node, returning children to parent' uses a specific verb and resource, and clearly distinguishes this tool from siblings like group_nodes or reparent_node. It precisely states both the action and its effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of when not to use it, or contrast with reparent_node or delete_node. The usage context is merely implied by the action, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description communicates that this is a read operation ('Read'), which is useful given no annotations, but it does not disclose behavior on invalid node IDs, whether style segments are returned inline, or any edge cases like non-text nodes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the action and resource with zero redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description covers the core purpose and result. Without an output schema, it could briefly explain the structure of style segments, but the level of detail is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes nodeId as 'Text node ID' at 100% coverage, and the description adds no extra parameter detail beyond confirming it targets a text node, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Read' and specifies the resource: text content and style segments from a text node, which clearly differentiates from sibling tools like set_text (write) and set_text_range_style (style modification). However, it does not explicitly distinguish itself from get_node_properties, which could also return text-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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. The getter semantics imply it is for retrieving text from a node, but the description does not state when to choose this over get_node_properties or get_cell_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the operation creates a rectangle with IMAGE fill, which is non-obvious. However, it does not address side effects, error handling, or interaction with parent nodes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The action and key behavior are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema or annotations, the description is too brief. It omits coordinate system context, behavior when both url and bytes are supplied, and what the tool returns, making it incomplete for reliable usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage, the baseline is 3. The description adds the phrase 'from URL or bytes,' which clarifies the url and bytes parameters, but does not add further semantic meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (place), the resource (image), the sources (URL or bytes), and the outcome (rectangle with IMAGE fill). This is specific and distinguishes it from siblings like create_svg or create_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for placing images but does not explicitly contrast it with alternatives such as replace_media or create_shape_with_text. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output format (PNG, base64) which is useful, but does not mention potential side effects, permissions, or constraints. It adds some behavioral context but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's function and return format. Every word is meaningful 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description is mostly complete. It covers the core operation and return format, but could benefit from a note about when to prefer this over screenshot_all_slides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both slideId and scale. The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a visual screenshot of a slide as a PNG and returns a base64-encoded image. This specific verb+resource+format combination distinguishes it from sibling tools like screenshot_all_slides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 screenshot_all_slides. The description only states the basic function without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: substring matching for name and AND-combination of criteria. However, it omits behavior around the parentId parameter (e.g., scoping) and what happens with empty criteria, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and then lists the criteria. Every word contributes value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, this is usable but incomplete. It covers the main criteria but leaves parentId undocumented and does not clarify the return type or default behavior. Given the nested structure and missing 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of the criteria fields (substring for name, AND-combination) but completely ignores parentId. Thus it adds partial meaning beyond the schema but misses a key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for nodes' with specific filter criteria (name, type, visible, locked). This is a specific verb+resource that immediately distinguishes it from siblings like get_node_tree or get_selection, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: you would use this when you need to find nodes by the listed criteria. However, there is no explicit mention of when not to use it or alternatives (e.g., get_node_tree for full hierarchy), so it falls short of explicit 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 transparency burden. It discloses the read-only nature and that it returns a list, which is useful, but lacks details like error behavior, pagination, or permission needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action. No redundant phrases; the examples ('polls, embeds') add value without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is adequate but minimal. It omits details about return formatting, empty results, or error conditions, which is more noticeable given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's slideId parameter has no description, and the tool description covers 0% of parameters. The phrase 'on a slide' indirectly maps slideId to the target slide, but gives no format or constraints beyond the name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'interactive elements on a slide' with concrete examples (polls, embeds). This clearly distinguishes it from sibling tools like get_slide_context or get_node_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case—when you need to know what interactive elements exist on a slide—but does not explicitly contrast with similar get tools or state exclusions. 'Read-only' hints it's safe but no alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that all output is editable vector nodes and mentions the execution environment (rough, scratch div, pre-created SVG element). However, it does not explain error handling, security implications of executing JS, or how the script integrates with the Figma canvas—significant gaps for a code-execution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: purpose, use case, available APIs, how to write the script, and an important note about output. Each sentence delivers value, but it is slightly longer than the minimal two-sentence ideal, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (executing custom JS), and the description covers the high-level purpose, use cases, and output type. However, it lacks detailed guidance on how to access the pre-created SVG element, what the 'scratch div' is, how x/y/width/height are interpreted, and what the function returns—leaving gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (2 of 6 params). The description adds context for the 'script' parameter ('Write JS that uses rough.svg(svg) to draw shapes'), but provides no additional meaning for x, y, width, or height beyond their types. It fails to compensate for the undocumented parameters, making it hard to know how to set position/size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders hand-drawn/sketchy graphics using Rough.js, specifying the output as editable Figma nodes. It distinguishes itself from sibling tools like create_svg, render_d3, and render_satori by focusing on sketchy aesthetic and Rough.js specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly suggests use cases: informal diagrams, whiteboard-style visuals, creative/playful graphics. This gives clear context for when to choose this tool. However, it does not explicitly contrast with alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it does not disclose whether setting properties replaces or merges existing values, how partial failures are handled, or whether certain properties are read-only for specific node types. The simple 'Modify properties' phrasing gives no insight into side effects or mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the core action, followed by a concise list of supported properties. Every word adds value, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description covers the main purpose and parameter details adequately. However, it lacks guidance on mutation behavior (e.g., replace vs merge) and return value expectations, which are important for a mutation tool operating on 'any node'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, but the props object is an unconstrained additionalProperties map, so the schema does not enumerate valid keys. The description compensates by listing the exact supported property names, adding meaning beyond the schema's generic 'Properties to set' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Modify' with a clear resource 'properties of any node' and enumerates the supported property names (x, y, width, height, etc.), which gives immediate clarity on its scope. This distinguishes it from sibling tools like set_text or set_text_range_style that handle text-specific mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general visual property edits by listing supported properties, but it does not explicitly state when to use this tool over alternatives like set_text or set_slide_theme. There are no exclusions or alternative recommendations, leaving the agent to infer the intended scope from the property list alone.
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 several key behaviors: round-trip execution, referencing results from earlier commands, and the single undo step. However, it omits important behavioral details such as failure handling or whether the batch is atomic, which are critical for a multi-command 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. The reference example and undo-step note are concise and include no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch wrapper, the description explains the core usage and undo behavior, which is adequate. However, it does not address error semantics (e.g., what happens if a command fails), execution order, or whether the command list is limited to specific commands. Given the complexity of a batch tool, this is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a concrete example of the reference syntax, but the schema already documents the 'params' object with the same pattern. Since schema description coverage is 0%, the description should compensate more; it does not explain the structure of the commands array or the meaning of the 'cmd' field beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes multiple commands in one round-trip, distinguishing it from sibling tools that operate individually. The verb 'Execute' and resource 'multiple commands' are specific, and the phrase 'in one round-trip' highlights its batching purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when multiple commands need to be issued together, and it provides the key mechanism for referencing earlier results. However, it does not explicitly state when not to use this tool or mention alternatives, such as calling individual commands sequentially.
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 import results in editable vector nodes and implies a simplicity limitation, but it doesn't specify how existing content in the parent is handled, whether it replaces or adds nodes, or possible failure modes for complex SVGs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the primary action and followed by use cases and a process note. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the core purpose and typical use cases, but it omits details about parameter semantics, positioning, and error behavior. It is adequate for an agent to understand what the tool does but not fully equipped to invoke it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with only svg and parentId having descriptions. The description does not provide additional meaning for x, y, width, or height, which are optional but lack any documentation. The agent would need to infer their purpose from names alone, and no guidance is given on how they interact with the SVG import.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports an SVG string as editable Figma vector nodes, with specific use cases (icons, logos, simple graphics). This distinguishes it from siblings like place_image or create_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool ('Use for icons, logos, simple graphics') and notes that the agent generates the SVG string directly. It implies this is for vector graphics rather than raster images but doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the key destructive side effect (removing all slides in the row), which is valuable. However, it omits other behavioral context such as irreversibility, permission requirements, or what happens if the row does not exist. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's purpose and scope. There is no redundant text, and it is front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter destructive tool, the description is largely complete: it identifies the action, the target, and the cascading effect. It might benefit from mentioning preconditions or irreversibility, but these are not essential for an agent to use the tool correctly in most contexts. The absence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter rowId, describing it as 'Row to delete'. The description does not add any additional parameter-specific details, so it meets the baseline for high schema coverage but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove) and the resource (slide row), and explicitly includes the cascading effect of deleting all slides in it. This distinguishes it from sibling tools like delete_slide (which removes a single slide) and create_slide_row (which adds a row).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need to delete a slide row and its contents. However, the description does not explicitly mention alternatives, when not to use it, or any prerequisites or conditions. It provides no comparative guidance against delete_slide or other row-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses recursive traversal behavior via the depth parameter and lists return fields, but lacks details about error behavior, ordering, or whether the root node is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no redundant content. Every word contributes meaning, making it an efficient and appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description sufficiently explains the output fields and parameter semantics. Without an output schema, a bit more detail about tree nesting could help but is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal semantic value by linking depth to recursion, but this largely duplicates the schema's 'Max depth' explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as the structural tree, listing the included data (IDs, types, names, bounds). This clearly distinguishes it from sibling tools like get_node_properties or find_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied when needing the full hierarchy, but there is no explicit guidance on when to prefer this over alternatives or when not to use it. The only hint, 'Use depth to limit recursion,' addresses the depth parameter rather than 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the primary operation (read-only retrieval of selected node IDs) but does not specify return format, empty selection behavior, or potential errors. It is adequate for a simple getter but lacks edge-case detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It contains no filler or redundant information, making it efficiently structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description provides essential information about the return type (node IDs). It is fairly complete, though it could additionally clarify the format (e.g., array) or empty-selection behavior, but these are minor gaps 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. The description adds semantic context by indicating that the output is tied to the 'currently selected' nodes, which is relevant to how the tool operates, satisfying the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get currently selected node IDs' uses a specific verb and resource, clearly identifying the tool's function. It distinguishes itself from siblings like set_selection and get_node_properties by specifying it retrieves the current selection's node identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While the description implies it is for retrieving the current selection, it does not mention when one might prefer this over set_selection or get_node_properties, nor 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. The verb 'list' implies a read-only operation, but the description does not explicitly mention safety, return format, or whether the themes come from the current presentation or a global library. It adds little beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words—ideal for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must serve as the only documentation for the return value. It says 'list' but does not specify the structure of the return (e.g., array of strings) or clarify whether 'available' means themes from the current presentation or a broader catalog. This minimal description is adequate but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The empty schema already provides full coverage, and the description adds no parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and a clear resource 'available slide themes', which fully conveys the tool's purpose and distinguishes it from sibling tools like set_slide_theme and list_fonts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives, but the existence of sibling tools such as set_slide_theme implies this is meant to fetch available themes before setting one. This constitutes implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the destructive nature ('Remove all content') and the non-destructive aspect of preserving the slide ('keeping the slide itself'). It adds context beyond the schema by clarifying the slide is not deleted, but it does not mention reversibility, permissions, or effects on slide metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 12 words. It communicates the essential behavior with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description is nearly complete: it states the action, target, and key preservation detail. It might benefit from mentioning side effects or reversibility, but the core semantics are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents slideId as 'The slide to clear' with 100% coverage. The tool's description restates 'slide' but adds no additional meaning regarding the parameter's format, constraints, or behavior. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove all content from a slide, keeping the slide itself.' The verb 'remove' and resource 'slide' are explicit, and the qualifier 'keeping the slide itself' distinguishes it from slide deletion tools like delete_slide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a slide's content needs to be wiped while preserving the slide, but it does not explicitly name alternatives or provide when-to-use guidance. The phrase 'keeping the slide itself' hints at a contrast with delete_slide, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly states the tool retrieves editor type, document name, and page count, implying a read-only operation. However, it does not mention potential error conditions (e.g., no connected file) or whether the data reflects the current state, though this is somewhat implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word contributes to the meaning, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description fully covers the expected return values (editor type, document name, page count) and their source (connected Figma file). This is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly adds no parameter-level information because there are none, leaving the schema fully sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource ('editor type, document name, and page count') and the scope ('from the connected Figma file'). This distinguishes it from sibling tools like get_slide_context or get_node_properties, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention that this is for general editor/file-level info, nor does it suggest using other tools for slide- or node-specific data. The usage is only implied by the resource names, offering minimal decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of explaining side effects. It mentions 'with optional properties' and lists properties, but does not disclose return values, insertion behavior, or potential side effects like overwriting. This is adequate but not rich; it provides some context without deep 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and types, and a brief redirection to alternatives. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete for a simple create tool: lists types, optional props, and alternatives. However, it lacks information about the return value (e.g., new node ID), which would be useful given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the description does not need to add much. It does mention 'optional properties' which aligns with the props param, but overall it adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a node' with an enumerated list of supported types (FRAME, RECTANGLE, etc.), specifying the verb and resource. It also distinguishes from siblings by directing users to dedicated tools for tables and shapes-with-text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'For tables, shapes-with-text, etc., use dedicated tools,' providing a clear when-not-to-use and alternative. The context of it being the general node creation tool is evident from the enumerated types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' and the term 'dump' strongly imply a read-only operation, and the listed content types clarify what is returned. It does not explicitly state that the slide is not modified, but the implication is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the action and scope, and the second provides the intended use case. Each sentence is purposeful, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description lists the major categories of returned content and the intended use case, which is sufficient for an agent to invoke it correctly. It could mention alternative tools or a more detailed return structure, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, slideId, has a schema description ('The ID of the slide to inspect') which is clear and covers 100% of the schema. The tool description adds no additional parameter detail, but the baseline of 3 is appropriate given the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly defines the scope as 'everything on a slide', listing specific content types (text content, shapes, images, positions, styles). This distinguishes it from sibling tools like get_text_content and get_node_tree by emphasizing its comprehensive coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Best for understanding what is on a slide before editing.' This gives context for when to use the tool, though it does not explicitly mention alternatives or when not to use it, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the default behavior (first 50 families without a query) and implies a read-only operation by using 'search' and 'returns.' It doesn't describe side effects (there are none), but it covers the most important behavioral nuance (default limit). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the primary verb and resource upfront. Every word adds value: 'Search available fonts' sets context, and the second sentence explains query behavior and default limit. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the essential information: purpose, filtering, and default pagination. It could mention how results are returned (e.g., array of family names) or case-sensitivity, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are documented with descriptions in the schema. The description adds minimal new meaning—it restates that query filters by family name and notes the default behavior, which the schema already conveys via the limit parameter's default. This meets the baseline of 3 for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search available fonts.' This is a specific verb+resource pair that distinguishes it from all sibling tools, which deal with nodes, slides, or themes rather than fonts. It also immediately clarifies the two modes of operation (with and without a query).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the query parameter ('to filter by family name') and what happens when it's omitted ('returns first 50 families'). This provides clear usage context, though it doesn't mention any alternatives or explicitly state when not to use the tool—simple enough that this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key behavior: capturing thumbnails of all slides and returning an array of base64 PNG images. It doesn't mention side effects or performance caveats, but for a read-only operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and return format. Every word earns its place—no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional parameters, and the description covers the essential return value (base64 PNG array), which is needed since no output schema exists. It is complete enough for the complexity level, though it could briefly mention alternatives or performance limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already explains scale and maxSlides. The description adds no additional parameter context beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture thumbnails of all slides', a specific verb+resource+scope. This distinguishes it from sibling tools like screenshot_slide, which targets a single slide, by explicitly saying 'all slides'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: when you need thumbnails of every slide. It doesn't explicitly name alternatives or exclude single-slide capture, but the context is clear on scope, so it earns a 4 for clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the action and affected properties but does not clarify whether the props object merges with or replaces existing styles, nor any requirements like nodeId referencing a text node. It provides some context but lacks behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with action and resource, followed by a clear list of supported style properties. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is complete (100% coverage), and the description gives purpose and property options. It lacks explicit notes on partial updates or error conditions, but for a focused tool with 4 well-defined parameters, the provided context is sufficient. No output schema reduces the need for return-value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions, but the props parameter is generic ('Style props'). The description adds specific property names (fontSize, fontName, fills, etc.), providing valuable guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool applies styles to a character range and lists specific style properties (fontSize, fontName, fills, etc.). This verb+resource phrasing clearly distinguishes it from siblings like set_text (content) and set_properties (node-level properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for formatting a character range within a text node, and the listed properties differentiate it from nearby tools. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. The verb 'Get' signals a read-only operation, and the description adds the return shape ('rows and slides with their IDs and names'), which is useful context. It does not discuss ordering or behavior on empty decks, but for a simple getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get the full slide deck structure: rows and slides with their IDs and names'. It contains no filler and every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input getter with no output schema, the description sufficiently explains what will be returned (rows and slides with IDs and names). The tool's low complexity means no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing for the description to clarify beyond the baseline. The 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Get the full slide deck structure' and specifies the contents ('rows and slides with their IDs and names'). This distinguishes it from siblings like get_slide_context or get_node_tree by focusing on the full deck-level grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need the complete slide deck structure, but it offers no explicit guidance on when to prefer this over sibling tools such as get_slide_context or get_node_tree. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it explains the script executes in the plugin iframe with D3 v7, available globals (d3, scratch), the extraction/conversion process, and the important detail that all text becomes editable Figma text nodes. It stops short of describing potential side effects or error handling, but covers core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear opening statement, followed by technical instructions. It is a bit long but every sentence adds value: environment details, available globals, output options, and the text-node behavior. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool that executes user-supplied JavaScript, the description provides sufficient context: runtime environment, global variables, output requirements, and the resulting Figma nodes. It lacks caveats about performance or conversion limitations, but given the absence of an output schema, it covers the essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (4/6 params have descriptions). The description adds significant meaning to the 'script' parameter by explaining how to use D3, the scratch div, and the return/render mechanism. While x/y lack descriptions, they are standard coordinates and the schema covers the rest. The description compensates for the most complex parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render a D3.js visualization as editable Figma vector nodes' with a specific verb and resource. It distinguishes itself from siblings by noting it is 'PREFERRED for data visualizations, charts, graphs, diagrams' and 'the best renderer for data-driven graphics.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use this tool ('PREFERRED for data visualizations, charts, graphs, diagrams') and highlights its advantage ('best renderer for data-driven graphics'). It does not explicitly name alternative renderers or exclusion criteria, but the preference statement is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of disclosing behavior. It states that the tool starts a server, waits for a plugin connection, and returns status/instructions if not connected. This is a meaningful disclosure of the tool's side effects and outcome, though it omits lifecycle details like how to stop the server or timeout 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core action, and includes trigger phrases and return behavior. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the essential context: what the tool does, when to call it, and what it returns. This is complete for a simple startup tool and does not require additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and the baseline is 4. The description does not need to explain parameter semantics, and the 100% schema coverage confirms there are no undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Start the WebSocket server and wait for the Figma plugin to connect.' This distinguishes it from sibling tools like connection_status, which likely only checks status rather than initiating a session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit trigger phrases: 'Call this when the user says "start figma session", "connect to figma", or "open slides".' This is clear usage guidance, though it does not explicitly name alternatives or when not to use it, such as distinguishing from connection_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral trait that it does NOT start the server, preventing a common misconception. It could add more detail about return format or latency, but for a simple status check this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, followed by an important exclusion. Zero waste, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is fully adequate: it tells the agent what the tool does, what it doesn't do, and what to do instead. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description doesn't need to explain parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and resource 'Figma plugin connection status'. It clearly distinguishes itself from start_session by explicitly stating it does NOT start the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (check connection) and provides an alternative action ('use start_session first'). This is clear guidance on usage versus the sibling tool.
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 fully discloses behavioral traits: text becomes vector paths (not editable text nodes), CSS gradients and rgba() are unsupported, font fetching adds latency, and the syntax is JSX-object based. It also explains the execution context (iframe, available satori function) and the need to fetch a font first, going well beyond what structured data could indicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, usage guideline, a clearly labeled 'LIMITATIONS' section, and a brief execution note. Every sentence adds necessary information; there is no redundancy or filler. The use of sections and bullet-style limitations improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers key prerequisites (font fetching), syntax (JSX objects), execution environment (iframe, satori function), and limitations (text paths, no gradients, no rgba). It clearly states the outcome ('editable Figma vector nodes') and provides enough detail for an agent to use the tool correctly, despite not describing the exact return value beyond the script returning an SVG string.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the script parameter by explaining how to write it: 'Use the satori() function with JSX-like objects' and 'Must fetch a font first: fetch Inter WOFF, pass as fonts array.' While x/y parameters lack explicit descriptions in both schema and description, the overall guidance for the most complex parameter compensates given moderate schema coverage (67% of parameters have descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders HTML/CSS layouts as editable Figma vector nodes via Satori, using a specific verb and resource. It differentiates from siblings by explicitly pointing to render_d3 for data viz and focusing on complex CSS layouts that are hard to express in SVG.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage criteria are provided: 'Use ONLY when you need complex CSS layouts that are hard to express as SVG' and 'For data viz, prefer render_d3 instead.' The limitations section (e.g., text as paths, no gradients) further helps an agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/luan007/figma-slides-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server