keynote-mcp

by ByAxe

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes targeting specific presentation elements or actions, but some overlap exists between 'add_build_in' and 'add_builds_to_slide' (both handle build animations) and between various 'add_' tools for different content types, which could cause minor confusion. Descriptions generally clarify differences, such as 'add_build_in' for single elements versus 'add_builds_to_slide' for multiple.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'add_slide', 'delete_element', 'get_presentation_info', and 'set_slide_layout'. All tools use snake_case without deviation, making the naming predictable and easy to understand across the entire set.
Tool Count2/5
With 42 tools, the count is excessive for a presentation management server, likely leading to complexity and potential redundancy. While the domain is broad, many tools could be consolidated (e.g., multiple 'add_' tools for different content types), making the set feel heavy and overwhelming for typical agent use.
Completeness5/5
The tool set provides comprehensive coverage for Keynote presentation management, including full CRUD operations for slides and elements, animation handling, export capabilities, and metadata access. No obvious gaps exist; it supports creation, editing, styling, and presentation workflows end-to-end.
Average 2.9/5 across 42 of 42 tools scored. Lowest: 1.7/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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't indicate whether this is a read-only operation, what permissions might be required, what format the slide count returns in, whether it works on open presentations or saved files, or any error conditions. For a tool with zero annotation coverage, this minimal description is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely concise at just two words, this description is under-specified rather than efficiently structured. It lacks the necessary context that would make brevity valuable. The single phrase doesn't provide enough information to be truly helpful, though it doesn't waste words on irrelevant content. It's minimal but insufficient rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of presentation tools (with 35+ sibling tools), no annotations, and no output schema, this description is completely inadequate. It doesn't explain what the tool returns, what context it operates in, how it relates to other presentation tools, or any behavioral characteristics. For a tool in a rich ecosystem with no structured safety or output information, this minimal description fails to provide necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'doc_name' fully documented in the schema as 'Document name (optional, defaults to front document)'. The description adds no parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get slide count' is a tautology that essentially restates the tool name without adding meaningful context. It doesn't specify what resource the slide count is retrieved from (presentation/document) or clarify the scope beyond what's implied by the name. While it includes a verb ('Get'), it lacks specificity about the target resource and doesn't distinguish this tool from sibling presentation-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an open presentation), doesn't specify what context it operates in, and doesn't differentiate it from other slide-related tools like 'get_slide_info' or 'get_presentation_info'. The agent receives no usage context beyond the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Set slide layout' implies a mutation operation, but the description doesn't reveal whether this requires specific permissions, whether changes are reversible, what happens to existing slide content when layout changes, or what the expected outcome looks like. For a mutation tool with zero annotation coverage, this is dangerously inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only three words, this is a case of harmful under-specification rather than effective brevity. The description doesn't front-load important information or provide any structured explanation. Every word earns its place only in the most minimal sense, failing to convey necessary operational context for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the tool's complexity as a mutation operation with no annotations and no output schema. It doesn't explain what 'setting a slide layout' entails, what valid layout values are, how this affects existing content, what permissions are required, or what happens on success/failure. For a tool that modifies presentation state, this level of incompleteness is unacceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information whatsoever, but the input schema has 100% description coverage with clear documentation for all three parameters. The schema adequately explains that 'doc_name' defaults to the front document, 'slide_number' is required, and 'layout' is a required string type. Since schema coverage is high, the baseline score of 3 is appropriate despite the description adding zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set slide layout' is essentially a tautology that restates the tool name without adding meaningful context. It specifies the verb 'set' and resource 'slide layout', but doesn't explain what this operation actually does or how it differs from similar tools like 'set_presentation_theme' or 'get_available_layouts'. The purpose remains vague beyond the literal interpretation of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or relationships to sibling tools like 'get_available_layouts' (which might provide valid layout values) or 'set_presentation_theme' (which affects overall presentation styling). This leaves the agent with no contextual decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only or mutation operation, what permissions are required, whether it overwrites existing files, what happens on failure, or any rate limits. The single sentence lacks all critical behavioral context for a tool that presumably modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Save a presentation') but under-specified rather than efficiently informative. While it avoids unnecessary words, it fails to front-load critical details like the tool's basic function beyond the name, making it inefficient for an agent's understanding. It earns a middle score for brevity but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (a mutation operation with no annotations or output schema), the description is incomplete. It doesn't explain what 'save' entails, the result (e.g., success confirmation, file path), or error conditions. For a tool in a presentation suite with many siblings, this minimal description leaves significant gaps in understanding its role and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter, documenting that 'doc_name' is optional and defaults to the front document. The description adds no parameter information beyond this, but with high schema coverage and zero parameters explicitly mentioned, the baseline is 4. No additional semantic value is provided or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save a presentation' is a tautology that restates the tool name 'save_presentation' without adding specificity. It doesn't clarify what 'save' means in this context (e.g., saving changes to an open presentation, exporting to a file, or persisting to cloud storage) or distinguish it from sibling tools like 'export_pdf' or 'close_presentation' that might involve similar persistence actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a presentation must be open first), exclusions (e.g., not for new presentations), or related tools like 'export_pdf' for different output formats or 'close_presentation' for ending sessions without saving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Set presentation theme' implies a mutation operation, but it doesn't specify whether this requires specific permissions, if it affects all slides or just the current one, whether changes are reversible, or what happens on success/failure. This leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. It is front-loaded and directly states the tool's action, though this brevity comes at the cost of clarity and completeness. Every word earns its place, even if the overall content is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'theme' is, how it affects the presentation, or what the tool returns. While the schema covers parameters, the lack of behavioral context and output information makes this inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('doc_name' and 'theme_name') fully described in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining valid theme names or default behaviors. However, with high schema coverage, the baseline score is 3, as the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set presentation theme' is essentially a tautology that restates the tool name with minimal elaboration. While it identifies the action ('set') and resource ('presentation theme'), it lacks specificity about what a 'theme' entails in this context and doesn't distinguish this tool from sibling tools like 'get_available_themes' or 'set_slide_layout'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or relationships to sibling tools like 'get_available_themes' (which might list valid theme names) or 'set_slide_layout' (which might affect slide appearance differently).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Select a specific slide' implies a read or navigation action but doesn't specify if it changes state (e.g., sets active slide for edits), requires permissions, or has side effects. It lacks details on what 'select' entails, such as whether it's reversible or affects other operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's action, making it easy to parse quickly. This is an example of optimal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a selection action with 2 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'select' means in context (e.g., does it return data or change state?), leaving gaps in understanding the tool's behavior and outcomes. More detail is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('doc_name' and 'slide_number') with descriptions. The description adds no additional meaning beyond the schema, such as explaining how selection works with default documents or slide numbering. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select a specific slide' states a clear verb ('Select') and resource ('slide'), but it's vague about what 'select' means operationally (e.g., does it highlight, navigate to, or set as active?). It doesn't distinguish from siblings like 'get_slide_info' or 'get_slide_content', which might retrieve slide data without selecting. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_slide_info' or 'get_slide_content' that might retrieve slide details, there's no indication of when selection is needed (e.g., for subsequent edits or navigation). Usage is implied only by the tool name, not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a mutation (likely yes, but not confirmed), what happens if the slide doesn't exist, if changes are saved automatically, or any error conditions. For a tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool (implied by 'Add'), the description is incomplete. It lacks information on behavioral context (e.g., persistence, errors), return values, and how it fits with sibling tools. For a tool that modifies presentations, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond what's in the schema (e.g., no examples, formatting rules, or constraints beyond schema details). Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('bullet list to a slide'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_numbered_list' or 'add_text_box' beyond the obvious difference in list type, missing explicit comparison that would warrant a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_numbered_list' or 'add_text_box'. The description lacks context about prerequisites (e.g., needing an open presentation), exclusions, or comparisons to sibling tools, leaving usage decisions unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Add' implies a mutation operation, but the description doesn't disclose whether this requires specific permissions, what happens if the slide doesn't exist, whether the addition is permanent or requires saving, or what the tool returns. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters and no annotations or output schema, the description is inadequate. It doesn't address behavioral aspects like error conditions, side effects, or return values. While the schema covers parameters well, the description fails to provide the contextual information needed for safe and effective use of this write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide usage examples, or clarify edge cases. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('a code block to a slide'), making the purpose immediately understandable. It distinguishes this tool from siblings like add_text_box or add_bullet_list by specifying 'code block' as the content type. However, it doesn't explicitly differentiate from all possible siblings (e.g., it doesn't mention how it differs from add_build_in or add_builds_to_slide).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for adding content to slides (add_text_box, add_bullet_list, add_quote, etc.), there's no indication of when a code block is appropriate versus other content types. It also doesn't mention prerequisites like needing an open presentation or specific slide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions adding an image but fails to describe critical behaviors: whether this is a mutation (likely yes, but not stated), what happens if the image path is invalid, if there are size/format restrictions, or what the tool returns. This leaves significant gaps for an agent to understand the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core purpose, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 4 parameters), lack of annotations, and no output schema, the description is insufficient. It does not cover behavioral aspects like error handling, return values, or usage context, leaving the agent with incomplete information to operate the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters (slide_number, image_path, x, y) with descriptions. The description adds no additional semantic context beyond what's in the schema (e.g., it doesn't explain coordinate systems or image format requirements), meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('an image to a slide'), making the purpose immediately understandable. However, it does not differentiate this tool from sibling tools like 'add_shape' or 'add_text_box' that also add content to slides, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'add_shape' for non-image content) or any prerequisites (e.g., requiring an open presentation). It only states what the tool does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions adding a numbered list but doesn't cover critical aspects like whether this modifies an existing presentation, requires an open presentation, has side effects, or what happens on failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks information about prerequisites (e.g., needing an open presentation), behavioral details (e.g., how failures are handled), and output expectations, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what's in the schema, such as explaining interactions between parameters or typical use cases. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('numbered list to a slide'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'add_bullet_list' or 'add_text_box', which would require mentioning the numbered format specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_bullet_list' or 'add_text_box'. The description only states what it does, without context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Add a quote to a slide' implies a mutation operation, but it doesn't specify whether this requires an open presentation, what happens if the slide doesn't exist, or how the quote is formatted (e.g., as a text element). It lacks details about permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward tool and front-loads the essential information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'adding a quote' entails (e.g., creates a text element), what the result looks like, or any dependencies (e.g., requires an open presentation). Given the complexity of presentation editing and the lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no parameter-specific information beyond what's in the schema, providing only the high-level purpose. This meets the baseline for high schema coverage but doesn't enhance understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('a quote to a slide'), making the purpose immediately understandable. It distinguishes from siblings like add_text_box or add_title by specifying 'quote' as the content type, though it doesn't explicitly contrast with similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like add_text_box or add_title. The description doesn't mention prerequisites (e.g., needing an open presentation) or contextual constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create a rectangle shape' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether this requires specific permissions, if it modifies existing slides, what happens on failure, or if there are rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Create a rectangle shape') and briefly notes key optional parameters. There's zero wasted text, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, shape ID), error conditions, or dependencies like requiring an open presentation. For a 7-parameter tool that modifies presentations, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description mentions 'optional position, size, and opacity,' which loosely maps to x, y, width, height, and opacity parameters, but adds no meaningful semantics beyond what the schema provides (e.g., no clarification on coordinate systems or unit details). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a rectangle shape') and specifies the resource type ('shape'), which distinguishes it from sibling tools like add_image or add_text_box. However, it doesn't explicitly differentiate from other shape-related tools that might exist (though none are listed in siblings), making it clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or comparisons to other tools like add_build_in or add_image. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this requires write permissions, if it modifies the presentation in real-time, what happens on errors, or if there are rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function without any wasted words. It's appropriately sized for a simple tool and earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., slide ID, success status), error conditions, or dependencies like needing an open presentation, which are critical for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters (doc_name, position, layout) with their types and optional status. The description adds no additional meaning beyond what's in the schema, such as examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('new slide to the presentation'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'duplicate_slide' or 'set_slide_layout', which could also involve slide creation or modification, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or comparisons to tools like 'create_presentation' for initial setup or 'duplicate_slide' for copying existing slides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions adding a subtitle but doesn't clarify if this is a mutation (likely yes), what permissions are needed, whether it overwrites existing subtitles, or what happens on success/failure. This leaves significant gaps for a tool that modifies presentations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or side effects (e.g., whether it modifies an existing subtitle). Given the complexity of modifying presentations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples or edge cases), meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('subtitle to a slide'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_title' or 'add_text_box' that also add text elements to slides, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_title' or 'add_text_box', nor does it mention prerequisites such as requiring an open presentation. It simply states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Add' implies a write/mutation operation, but the description doesn't cover critical aspects like whether this requires specific permissions, if it modifies an existing slide permanently, what happens on failure, or typical response behavior. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a straightforward tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 7 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral traits, error conditions, or return values, leaving the agent with insufficient context for reliable invocation beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself (e.g., coordinates, color format). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate with additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('text box to a slide'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other content-adding siblings like add_bullet_list or add_shape, which would require specifying what makes a text box unique (e.g., editable text container vs. other elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or comparisons with similar tools like add_title or add_subtitle that might also involve text. This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Add a title to a slide' implies a mutation operation, but it doesn't specify whether this requires specific permissions, if it modifies existing content, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any unnecessary words. It's perfectly front-loaded and wastes no space, making it highly efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or dependencies on other tools (like needing an open presentation). Given the complexity of modifying presentation content, more context about behavior and outcomes is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain coordinate systems or font defaults in more detail). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('title to a slide'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'add_subtitle' or 'add_text_box' by specifying it's for titles, though it doesn't explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_subtitle' or 'add_text_box', nor does it mention prerequisites such as needing an open presentation or specific slide context. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates something, implying a write operation, but doesn't mention permissions, side effects (e.g., file saved automatically), error conditions, or what happens after creation (e.g., whether the presentation opens automatically). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the essential action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., presentation ID, success status), error handling, or behavioral nuances. Given the complexity of creating a presentation and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all three parameters. The baseline score of 3 reflects adequate parameter documentation solely through the schema, with no additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new Keynote presentation'), making the purpose immediately understandable. It doesn't specifically differentiate from siblings like 'open_presentation' or 'list_presentations', but the verb 'Create' is distinct enough from those operations 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to create before adding slides), exclusions (e.g., not for editing existing presentations), or comparisons to sibling tools like 'open_presentation' for working with existing files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention if deletion is permanent, requires specific permissions, affects other elements, or has side effects like layout shifts, which is critical for a destructive operation in a presentation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste—it directly states the tool's purpose without extra words. Every part of the sentence contributes to understanding the action and targeting mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive operation with no annotations or output schema, the description is incomplete. It lacks details on behavioral impact, error conditions, or what happens post-deletion, which are essential for safe and effective use in a presentation environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the parameters are used for targeting, which the schema already covers. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target ('an element by type and index from a slide'), distinguishing it from other deletion tools like 'delete_slide'. However, it doesn't specify what constitutes an 'element' beyond the schema's enum, missing a brief clarification that could differentiate it further from siblings like 'remove_build_in'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for precise element removal versus bulk operations or how it relates to siblings like 'clear_slide' or 'remove_build_in', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete a slide' implies a destructive, irreversible mutation, but it doesn't specify permissions required, whether deletions are permanent, error conditions (e.g., invalid slide number), or what happens to subsequent slide numbering. For a destructive tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words—it's maximally concise and front-loaded. Every word ('Delete a slide') earns its place by conveying the core action without fluff or ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects (e.g., permanence, side effects), error handling, or return values. For a mutation tool in a presentation context with many siblings, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Since schema description coverage is 100% (both parameters are documented in the schema), the baseline score is 3. The description doesn't explain interactions between parameters (e.g., how 'doc_name' defaults work) or usage nuances, but the schema adequately covers the basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a slide' clearly states the verb (delete) and resource (slide), making the purpose immediately understandable. It distinguishes from siblings like 'delete_element' (more specific) and 'clear_slide' (different action), though it doesn't explicitly differentiate them. The purpose is unambiguous but lacks sibling-specific nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_element' or 'clear_slide', nor does it mention prerequisites (e.g., needing an open presentation) or exclusions. It's a bare statement of function with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('duplicate') but doesn't mention whether this is a mutation, what permissions are needed, if it's reversible, or how it affects the presentation structure. This is a significant gap for a tool that modifies content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances like how duplication interacts with slide numbering. This leaves gaps in understanding the tool's full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond implying a slide is duplicated, which is redundant with the tool name. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('duplicate') and resource ('a slide'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_slide' or 'move_slide' that also manipulate slides, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_slide' or 'move_slide'. The description lacks context about prerequisites, such as needing an open presentation, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('Edit'), but doesn't disclose behavioral traits such as whether changes are saved automatically, if it requires specific permissions, what happens on invalid indices, or error handling. The description is minimal and lacks crucial operational context for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or return values, leaving significant gaps for an AI agent to understand how to use it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as explaining 'item_index' as 1-based (already in schema) or interactions between parameters. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit') and resource ('text item's content'), specifying it operates 'on a slide'. It distinguishes from siblings like 'add_text_box' or 'delete_element' by focusing on modifying existing text items. However, it doesn't explicitly contrast with tools like 'move_element' or 'resize_element' that might also affect text items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this should be used instead of 'delete_element' followed by 'add_text_box', or clarify prerequisites like needing an open presentation. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Export' implies a write operation that creates a file, but the description doesn't mention whether this requires a presentation to be open, what happens if the output path exists, or any performance/rate considerations. For a file-creation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and immediately states the output format. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-export tool with no annotations and no output schema, the description is insufficient. It doesn't explain what gets exported (current slide? entire presentation?), whether the presentation must be open first, what happens on failure, or what the return value might be. Given the complexity of file operations and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'output_path' clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides (no format examples, path validation rules, or special considerations). With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'export' and the resource 'presentation as PDF', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'screenshot_slide' or 'save_presentation', which might also produce files. The description is specific about the output format (PDF) but doesn't clarify scope (current slide vs entire 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an open presentation), comparison to 'screenshot_slide' (which might produce image files), or 'save_presentation' (which might save in native format). The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves a list but doesn't describe what the list contains (e.g., layout names, IDs, previews), whether it's paginated, or if it requires specific permissions. The description is minimal and lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list contains, its format, or any behavioral constraints. For a tool that likely returns structured layout data, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'doc_name' documented as optional with a default. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of available slide layouts'), making the tool's purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'get_available_themes' or 'get_slide_info', but the specificity of 'slide layouts' provides adequate differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or relationships with sibling tools like 'set_slide_layout' or 'get_available_themes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what information is retrieved but doesn't disclose behavioral aspects such as whether it requires an open presentation, what happens if no document is specified, error conditions, or response format. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and lists key attributes. There's no wasted verbiage or redundant information, making it easy to parse quickly while conveying essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a read operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'presentation info' entails beyond three attributes, how results are structured, or any dependencies (e.g., needing an open presentation). For a tool in a rich sibling set, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'doc_name' documented as optional with a default. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('presentation info') along with specific attributes retrieved (name, slide count, theme). It distinguishes from siblings like 'get_slide_info' or 'get_slide_count' by focusing on overall presentation metadata rather than slide-specific details. However, it doesn't explicitly contrast with all similar siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_slide_info', 'get_slide_count', or 'list_presentations'. The description implies it retrieves presentation-level metadata, but there's no explicit context about prerequisites, timing, or exclusions. Usage must be inferred from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, what permissions are needed, how errors are handled, or the format of the return value (e.g., numeric values, units). The description implies a safe read operation but lacks critical details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and avoids unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., units like pixels, aspect ratio format) or error conditions, leaving gaps for a tool that retrieves technical specifications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single optional parameter 'doc_name'. The description adds no parameter-specific information beyond what the schema provides, such as examples or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('presentation resolution') with specific attributes (width, height, aspect ratio). It distinguishes from sibling tools like 'get_slide_size' by focusing on resolution rather than slide dimensions, though the distinction could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_slide_size' or 'get_presentation_info'. The description lacks context about prerequisites, such as whether a presentation must be open, or when resolution retrieval is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits such as permissions needed, error handling, rate limits, or what happens if the slide doesn't have notes. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what the return value looks like (e.g., text format, structure), error conditions, or how it interacts with other tools in the context. This leaves the agent with insufficient information for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('slide_number' and 'doc_name') adequately. The description doesn't add any meaning beyond what's in the schema, such as explaining the format of presenter notes or how 'doc_name' defaults work in practice, but the high schema coverage justifies the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('presenter notes from a slide'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_slide_content' or 'get_slide_info', which also retrieve slide information, so it doesn't fully distinguish its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_slide_content' and 'get_slide_info' that might overlap in retrieving slide data, there's no indication of when this tool is preferred or what makes it unique for accessing presenter notes specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions moving an element but doesn't disclose behavioral traits like whether this is a destructive operation, what permissions are needed, how errors are handled (e.g., invalid coordinates), or what happens on success. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 6 parameters), no annotations, and no output schema, the description is incomplete. It lacks information on behavioral context (e.g., effects, errors), usage prerequisites, and output expectations. For a tool that modifies presentations, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional meaning beyond implying coordinates are involved. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move') and resource ('an element'), specifying the target location ('to new coordinates on a slide'). It distinguishes from siblings like 'resize_element' (changes size) and 'delete_element' (removes), but doesn't explicitly differentiate from tools like 'edit_text_item' that might also reposition elements. The purpose is specific but could be more distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions (e.g., not for moving slides), or comparisons to siblings like 'resize_element' or 'edit_text_item'. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions moving a slide but fails to describe critical behaviors: whether this is a destructive operation (e.g., overwriting slides at the target position), what permissions are required, how errors are handled (e.g., invalid positions), or the expected outcome (e.g., reordering slides). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error handling, and the result of the operation, which are critical for safe and effective use. The description does not compensate for the absence of structured data, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning beyond what the input schema provides, as schema description coverage is 100% with clear parameter descriptions. The baseline score of 3 is appropriate because the schema adequately documents the parameters, and the description doesn't compensate or elaborate further, but it also doesn't detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move') and resource ('a slide'), specifying the operation involves changing position. It's specific enough to understand the core function, though it doesn't explicitly differentiate from similar tools like 'move_element' or 'duplicate_slide' among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'move_element' (for moving elements within slides) or 'duplicate_slide' (for copying slides). It lacks context about prerequisites, such as needing an open presentation, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose what 'Open' entails (e.g., loads into memory, requires permissions, affects state, or potential errors like file not found), leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely mutates state (opening a file) with no annotations and no output schema, the description is inadequate. It lacks details on behavior, side effects, return values, or error handling, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'file_path'. The description adds no additional meaning beyond implying the file must be a Keynote presentation, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and resource ('an existing Keynote presentation'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_presentation' or 'list_presentations' beyond the basic verb, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file must exist), exclusions, or comparisons to siblings like 'create_presentation' for new files or 'list_presentations' for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'Uses UI scripting,' which hints at potential side effects or automation behavior, but doesn't specify whether this is destructive (removing animation permanently), requires specific permissions, or has rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the core purpose. It avoids unnecessary words and gets straight to the point. However, the second sentence ('Uses UI scripting.') could be integrated more smoothly, and there's room to add minimal usage context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 3 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after removal (e.g., success confirmation, error cases), whether animations can be restored, or how it interacts with sibling tools like 'add_build_in'. For a tool that modifies presentation state, more behavioral and contextual detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (slide_number, element_type, element_index) with descriptions and an enum for element_type. The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'Build In animation' means contextually or how element indexing works. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove Build In animation') and target ('from an element'), and specifies the implementation method ('Uses UI scripting'). It distinguishes from siblings like 'delete_element' or 'clear_slide' by focusing specifically on animation removal rather than element deletion or slide clearing. However, it doesn't explicitly contrast with 'add_build_in' or other animation-related tools beyond the obvious verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires an existing presentation with animations), when-not scenarios (e.g., if the element has no animation), or direct alternatives among siblings (like whether 'edit_text_item' might handle animation properties). The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('resize') but doesn't explain what happens during execution: whether this is a destructive mutation, if it requires specific permissions, how errors are handled, or what the response looks like. This leaves significant gaps for a tool that modifies presentation content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain behavioral aspects like side effects, error conditions, or return values. While the schema covers parameters well, the overall context for safe and effective use is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so parameters are well-documented in the structured fields. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score. However, it doesn't compensate for any gaps since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('resize') and target ('an element on a slide'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'move_element' or 'set_element_opacity' that also manipulate slide elements, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an open presentation), comparison to similar tools like 'move_element', or constraints (e.g., whether resizing affects element content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action but doesn't specify whether this requires specific permissions, what happens if the slide doesn't exist, whether the operation is destructive to the presentation, or what the expected output behavior is (e.g., file creation confirmation). This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just 6 words, front-loading the core functionality with zero wasted language. Every word earns its place by communicating the essential action and target resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like error conditions, dependencies on other operations (e.g., needing an open presentation), or what constitutes successful execution. The context demands more comprehensive guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain the relationship between parameters (e.g., that slide_number refers to a specific slide in the current presentation) or provide additional context about parameter usage. The baseline score of 3 reflects adequate but minimal value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a screenshot') and resource ('of a single slide'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential alternatives like 'export_pdf' or other slide export methods, which would require sibling differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'export_pdf' or other slide content retrieval tools. It lacks context about prerequisites (e.g., whether a presentation must be open first) or limitations, offering only basic functional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a destructive mutation, permission requirements, error conditions (e.g., invalid opacity), or effects on the presentation state, which are critical for a tool that modifies visual properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and scope, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It lacks context on behavioral implications (e.g., reversibility, side effects), error handling, or return values, leaving significant gaps for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying opacity is a 0-100 value, which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set opacity') and the target ('on any element'), which is specific and actionable. However, it doesn't distinguish this tool from siblings like 'resize_element' or 'move_element' that also modify element properties, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or comparisons to similar tools like 'resize_element', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Set' implies a mutation, but the description doesn't specify whether this overwrites existing notes, requires specific permissions, affects presentation state, or provides any response format. For a write operation with zero annotation coverage, this leaves critical behavioral traits unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral impact (e.g., whether changes are saved immediately), error conditions, or return values. For a tool that modifies presentation state, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters ('slide_number', 'notes', 'doc_name') with basic descriptions. The description adds no additional meaning beyond what the schema provides, such as format details for 'notes' or default behavior for 'doc_name'. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('presenter notes on a slide'), making the purpose immediately understandable. It distinguishes from siblings like 'get_speaker_notes' by specifying a write operation. However, it doesn't explicitly differentiate from other slide-editing tools like 'edit_text_item' or 'clear_slide' in terms of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open presentation), exclusions, or comparisons to similar tools like 'edit_text_item' for modifying other slide content. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Close a presentation' implies a destructive operation that might end a session or remove data from memory, but it doesn't specify effects like whether unsaved changes are lost, if it requires specific permissions, or what happens post-closure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Close a presentation' directly conveys the core action without unnecessary words. It's appropriately sized for a simple tool and front-loaded with the essential information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with 2 parameters) and no annotations or output schema, the description is minimally adequate. It states the purpose but lacks details on behavior, usage context, or return values. With 100% schema coverage for inputs, it meets a basic threshold, but for a destructive operation, more guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with parameters 'doc_name' and 'should_save' fully documented in the schema. The description adds no parameter information beyond what the schema provides, such as clarifying default behaviors or usage examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close a presentation' clearly states the action (close) and resource (presentation) with a specific verb. It distinguishes from siblings like 'save_presentation' or 'open_presentation' by focusing on termination rather than persistence or access. However, it doesn't specify what 'close' entails (e.g., ending editing session, removing from memory), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must have an open presentation), exclusions (e.g., not for saving), or related tools like 'save_presentation' for saving before closing. This leaves the agent to infer usage from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't specify whether it requires an open presentation, returns a specific format (e.g., list of theme names or objects), or has any side effects. This leaves critical behavioral aspects unclear for a tool in a presentation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'available themes' means in context (e.g., system defaults vs. presentation-specific), the return format, or dependencies. For a tool in a presentation suite with many siblings, more context would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly implies no parameters are required, earning a baseline score of 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of available themes' clearly states the verb ('Get') and resource ('available themes'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'set_presentation_theme' or 'get_available_layouts', but the specificity of 'themes' provides some implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a presentation must be open), nor does it contrast with similar tools like 'get_available_layouts' or explain its role in the workflow (e.g., for selecting themes before applying them).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only), but doesn't mention potential side effects (e.g., if it requires an active presentation session), error conditions (e.g., invalid slide numbers), or output format (e.g., structured data vs. raw text). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get slide info') and lists key attributes without unnecessary words. Every part earns its place by specifying what information is retrieved, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving slide metadata), 100% schema coverage, and no output schema, the description is minimally adequate. It states what info is retrieved but lacks details on behavioral aspects (e.g., error handling) and doesn't explain return values, which is a gap since no output schema exists. It's complete enough for basic use but leaves room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (doc_name and slide_number) fully documented in the schema. The description adds no additional parameter semantics beyond implying the tool operates on slides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('slide info') with specific attributes (number, layout, text item count). It distinguishes from siblings like get_slide_content (which retrieves content details) or get_slide_count (which counts slides), though it doesn't explicitly name these alternatives. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_slide_content (which might return more detailed content) or get_presentation_info (which provides presentation-level data). There's no mention of prerequisites, such as needing an open presentation, or contextual cues for selection among similar retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a read operation ('get'), it doesn't specify whether it requires specific permissions, what happens if the document doesn't exist, or what format the information is returned in. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core purpose without any wasted words. It's front-loaded with the essential information and doesn't include unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one optional parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more context about what exactly is returned (e.g., specific measurements, layout names) and any constraints or requirements for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'doc_name' fully documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema, so it meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('get') and resources ('slide size, aspect ratio, and layout reference info'), making it immediately understandable. However, it doesn't explicitly distinguish itself from similar sibling tools like 'get_slide_info' or 'get_presentation_info', which might also provide related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_slide_info' and 'get_presentation_info' available, there's no indication of what makes this tool distinct or when it should be preferred over those options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it lists 'open presentations', implying it returns currently loaded presentations, but doesn't specify format, pagination, or error conditions. For a tool with no annotation coverage, this is insufficient detail about its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently communicates the core purpose without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of presentation management with many sibling tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'open presentations' means, the return format, or how this tool fits into the broader workflow, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly doesn't mention any parameters, which is appropriate, earning a high score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all open presentations' clearly states the verb ('List') and resource ('open presentations'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_presentation_info' or 'open_presentation', which might also retrieve presentation data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for presentation operations, there's no mention of prerequisites, context, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'clears' content, implying a destructive operation, but doesn't specify whether this is reversible, what permissions are required, whether it affects speaker notes, or what happens to animations/transitions. The description provides basic intent but lacks important behavioral details for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without any wasted words. It's front-loaded with the main action and includes important qualifiers about what gets preserved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides adequate basic functionality but lacks important context about behavioral traits, error conditions, and what constitutes 'user-created content.' It's minimally viable but has clear gaps in completeness for a tool that modifies presentation state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters completely. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('clear all user-created content') and target resource ('from a slide'), with precise scope ('preserving background images and theme placeholders'). It effectively distinguishes this tool from siblings like delete_slide (which removes the entire slide) or delete_element (which removes specific elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to reset slide content while keeping formatting, but doesn't explicitly state when to use this versus alternatives like delete_slide or manually deleting elements. No guidance is provided on prerequisites, side effects, or integration with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool returns 'counts and details' but does not disclose behavioral traits such as whether it requires an open presentation, what happens if the slide number is invalid, if there are rate limits, or the format of the returned details. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get all elements on a slide') and follows with specific return details. There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving content details), lack of annotations, and no output schema, the description is incomplete. It specifies what is returned but not the structure or format of the details, leaving the agent uncertain about the response. However, it does cover the basic purpose adequately, making it minimally viable but with clear gaps in behavioral and output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (slide_number and doc_name) adequately. The description adds no additional meaning beyond what the schema provides, such as explaining the scope of 'all elements' or default behavior for doc_name. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all elements on a slide') and resource ('slide'), distinguishing it from siblings like get_slide_info or get_slide_count by specifying it returns content details rather than metadata. It explicitly lists the types of elements returned (text items, images, shapes, tables), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving slide content details, but provides no explicit guidance on when to use this tool versus alternatives like get_slide_info (which might return metadata) or other siblings. It lacks any 'when-not' scenarios or prerequisites, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: applies builds in order for sequential appearance, auto-skips bullet dots, and uses UI scripting. This covers execution order, element filtering, and implementation method, though it lacks details on error handling, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key behavioral details in three concise sentences. Each sentence adds value: sequential ordering, auto-skipping, and UI scripting method, with zero redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good context for a mutation tool: it explains the action, ordering, element filtering, and method. However, it lacks details on what the tool returns (e.g., success status or errors) and does not cover all potential edge cases, though the schema covers parameters well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema, mentioning 'multiple elements' which relates to element_indices, but does not elaborate on parameter interactions or usage nuances. It references get_slide_content for indices, which is helpful but already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add Build In animations'), target ('multiple elements on a slide'), and method ('in one call'), distinguishing it from sibling tools like add_build_in (which likely handles single elements) and other content-adding tools. It specifies sequential appearance on click, which is a key behavioral detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for applying animations to multiple elements sequentially on a slide. It mentions auto-skipping bullet dots, which helps avoid misuse. However, it does not explicitly state when not to use it or name alternatives (e.g., add_build_in for single elements), though the 'multiple elements' focus implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the animation's step-by-step nature, mentions it uses UI scripting (implying potential performance or compatibility considerations), and crucially states the permission requirement ('requires Accessibility permissions'). However, it doesn't mention potential side effects like whether this overrides existing animations or if it's reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first clause, followed by essential context and requirements. Both sentences earn their place: the first explains what the tool does with an example, the second provides critical implementation details. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations and no output schema, the description does well by covering purpose, usage context, and permission requirements. However, it doesn't describe what happens on success/failure or the return format, which would be helpful given the absence of output schema. The permission disclosure partially compensates for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly with descriptions, enums, and defaults. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add a Build In animation'), target resource ('to an element'), and purpose ('so it appears step-by-step') with a concrete example ('e.g. bullets one by one on click'). It distinguishes from sibling tools like 'add_bullet_list' or 'add_shape' by focusing on animation rather than content creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Add a Build In animation to an element') and provides a critical prerequisite ('requires Accessibility permissions'), which is essential guidance for proper invocation. It also implies when not to use it (for static content addition) by contrasting with sibling tools that add content without animation.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ByAxe/keynote-mcp'

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