KitchenSink4PPT
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation3/5
Most read tools are well separated, but apply_edits exposes ops (search_and_replace, set_placeholder_text, delete_shape) that overlap with standalone tools like search_and_replace and set_placeholder_text, and the descriptions don't clearly state when to use the batch op vs the standalone convenience tool. The read/modeling tools are clearer, but the editing surface has real ambiguity.
Naming Consistency4/5The set uses a mostly consistent lowercase snake_case, verb-first pattern: get_*, set_*, list_*, delete_*, insert_*, reorder_* all read predictably. Minor deviations like apply_edits, search_and_replace, and diagnose break the verb_noun pattern slightly but do not create confusion.
Tool Count3/524 tools is at the heavy end of the borderline 16-25 range, especially for a lite core that also expects many additional pack tools to be enabled. Several tools are meta-tools or convenience wrappers around apply_edits ops, so the count feels slightly inflated even though each tool has a plausible purpose.
Completeness4/5The core covers slide lifecycle, text reading/editing, hyperlink management, and backup/snapshot/restore well, and get_workflows plus enable_tools make optional capabilities discoverable. However, creating presentations, shapes, tables, charts, and exports requires enabling packs, so the out-of-the-box surface has notable but workable gaps.
Average 4.5/5 across 24 of 24 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does disclose that each call handles exactly one kind, returns a flat list with ids and locations, and that slide-scoped kinds honor scope semantics (None, selector, or list). However, it does not explicitly state the operation is read-only, nor does it mention errors, pagination, ordering, or limits, which keeps it from being fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
At four sentences, the description is compact and front-loaded: purpose, kinds, return shape, and scope behavior appear before the downstream use-case sentence. The phrase 'THE multiplex enumerator' is stylistic, and the final pack sentence is useful but slightly tangential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an unannotated tool, the description covers the essential invocation semantics: valid kind values, scope behavior, return shape, and common downstream uses. Since an output schema exists, not detailing every return field is acceptable; the main remaining gap is the lack of explicit guidance for choosing between this and sibling listing/viewing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the description compensates by listing valid values for kind and explaining scope meaning: 'None = all slides, a selector, or a list.' file_path is not elaborated, but it is a conventional path parameter and its type is provided in the schema. This partial compensation goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a multiplex enumerator and explicitly lists the distinct kinds it can return (slides, shapes, placeholders, tables, charts, etc.), so an agent knows exactly what resource this covers. It also anchors the purpose to concrete downstream tasks: 'find layout names for insert_slide and shape ids for editing.' It does not explicitly contrast itself with sibling get/list tools, so sibling differentiation is mostly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: use it to find layout names for insert_slide and shape ids for editing, and notes that editing tools live in the enable_tools packs. It does not state when to prefer siblings like get_presentation_view or get_presentation_info, so it lacks formal exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses important non-obvious behaviors: matches are against displayed text rather than raw XML, regex is guarded against catastrophic backtracking, and results are formatted as addresses for other tools. It does not mention how include_notes or scope affect matching, which is a notable gap, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying essential information: purpose and output shape, regex behavior, displayed-text semantics, and routing to the graphics pack. No filler or redundancy, and the most decision-relevant details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered, and the description covers many behavioral quirks. However, with five parameters, zero schema descriptions, and no annotations, leaving scope and include_notes undefined is a significant completeness gap. An agent could call the tool incorrectly by not realizing notes are included by default or not understanding what scope controls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all five parameters. It explains regex behavior and implies query semantics, but it does not explain scope, include_notes, or file_path expectations. The include_notes parameter is especially relevant because it changes what 'the deck's text' includes, yet the description is silent about it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Search the deck's text') and states exactly what it returns: every match with slide index, shape id, paragraph index, and character offsets. This makes it easy to distinguish from sibling tools like get_text or search_and_replace without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context clues for when to use this tool: it produces addresses that format_text and apply_edits consume, and it explicitly routes formatting-aware replacement to the graphics pack via enable_tools. It does not explicitly contrast with search_and_replace, but the intended workflow is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses formatting preservation, skipped overlapping slide-number/date fields, refusal of regex capture groups in live mode, atomic saves with two-slot backup, and the UNSAVED state until live_save. This is strong behavioral disclosure for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet efficient: the purpose appears first, and every clause carries functional or behavioral information. The packed semicolon-heavy structure makes it slightly harder to parse quickly, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with no annotations and no per-parameter schema text, the description covers the major behaviors well and an output schema exists. Still, key knobs like scope, include_notes, and match_case are not explained, leaving important gaps in the agent's ability to invoke it fully correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully explains regex, live, and backup behavior, but it leaves the ambiguous scope parameter unexplained and does not mention match_case or include_notes, forcing the agent to infer their semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Deck-wide find and replace,' which clearly names the action, resource, and scope. It also names set_table_cells as the tool for bulk cell rewrites, providing some sibling differentiation, though it does not explicitly distinguish from find_text or apply_edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-not guidance for bulk cell rewrites via 'Bulk cell rewrites: set_table_cells (tables-charts pack).' It also explains conditional behavior for locked files through live='auto'/'force'/'off'. However, it does not state when to choose this tool over the other search/edit siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes the tool as returning facts and being a 'cheap first look,' implying a fast, non-mutating read. It also clarifies that rendering, validation, and PDF export are not here but require the assembly-export pack, which prevents false expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the key facts and use case, and contains no filler. Every sentence contributes either scoping or routing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. The description provides enough to know when to call it and what it returns at a high level. The only gap is the undocumented file_path parameter, but the tool is simple enough that this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate, but it never explains file_path semantics, format, or constraints. The single parameter is inferable from context, but the description adds no explicit meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('get') and resource ('presentation') and enumerates the exact deck-level facts returned: slide count/size, slide order with ids/titles, masters/layouts, sections, and notes presence. It also distinguishes itself from get_presentation_view, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: 'the cheap first look before get_presentation_view' tells the agent when to use this tool instead of the view tool. It doesn't explicitly list exclusion cases or all alternative tools, but the primary routing decision is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and largely succeeds: it reveals return contents, units (inches), 0-based slide addressing, durable slide_id, and live-mode semantics including file-lock behavior and unsaved-edit caveat. It does not mention auth or rate limits, but these are less critical for a read-style inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well organized: output contents first, then practical use, then addressing and live semantics. Each sentence carries load-bearing information, though the live-mode sentence is long and slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations but an output schema, the description covers the key invocation details and even previews output fields. Minor gaps remain, such as explicit file_path format guidance, but overall the agent has enough to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate; it does for slide and live. It defines slide as '0-based index or {"slide_id": N}' and explains auto/force/off behaviors in detail. file_path is not elaborated beyond the schema's string type, but that parameter is self-evident from its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'One slide in depth,' clearly naming the resource (a single slide) and the granularity (layout, hidden flag, notes presence, every shape with geometry and text). This distinguishes it from sibling tools like get_presentation_info or list_elements without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'Shape ids here are the addresses every editing tool takes; edit what it lists via the graphics pack' gives an explicit use case: obtain shape addresses before editing. It does not explicitly contrast against siblings, but the context is clear enough for an agent to know when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It reveals atomic saves with two-slot backup, backup=False rotation behavior, live='auto' behavior on locked files, and paragraph/newline semantics. This goes well beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely dense but efficient: every clause adds operational detail. The main action is front-loaded, and the telegraphic style packs substantial semantics without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers placeholder resolution, paragraph levels, backup behavior, and live-mode nuance, while an output schema exists so return-value documentation is not required. Minor gaps remain around file_path/slide format details and live values beyond 'auto'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it thoroughly explains placeholder aliases, text newline/tab conventions, and paragraphs object shape, plus backup and live parameters. file_path and slide formats are left implicit, though their names are relatively self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Fill a layout placeholder' with a clear styling inheritance note. It is distinguishable from sibling tools like search_and_replace or fit_text, but does not explicitly name a sibling or draw an explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete guidance on placeholder value formats and notes that idx/paragraphs are file-mode only, which helps prevent misuse. It also routes free text boxes to 'graphics pack' as an alternative, though it does not name or compare against specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses that collisions get a numeric suffix, the source file is not modified, snapshots are never overwritten, and DTG replacement happens rather than stacking. This is rich behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the essential DTG format and permanent-copy concept, then adds collision behavior, source-file safety, and usage guidance. Every sentence contributes unique information; nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Overall the description is very complete: naming, permanence, non-overwrite behavior, source safety, and when to use it are all covered. The main gap is the undocumented dest_dir parameter; since an output schema exists, return-value documentation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'label' as an optional short label and implies file_path is the source file, but dest_dir is never mentioned, leaving one of three parameters undescribed. Meaning is added for some params but not all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Save a DTG-stamped permanent copy') and gives an exact naming pattern, so the tool's purpose is unmistakable. It also distinguishes snapshots from the automatic prev/anchor slots and from manage_backups, which are the closest sibling concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to take a snapshot before any large or risky editing pass and clarifies that snapshots are never auto-pruned and manage_backups never touches them. This gives clear context for when to prefer a snapshot, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does exceptionally well: it discloses the heuristic estimate, lack of font metrics, run-size rewriting logic, normAutofit enabling, still_overflowing outcome, atomic save, and backup rotation behavior. This gives an agent realistic expectations beyond a simple 'fit text' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded and free of filler. Each sentence contributes distinct information: core mechanism, shape=None behavior, estimation caveat, verification path, and save/backup semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, this is unusually complete: it covers algorithm, scoping, failure reporting, verification, and persistence behavior. The remaining gaps are the undefined slide parameter and the lack of explicit sibling-tool comparisons, which keep it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds real meaning for shape, min_size, and backup, but the required slide parameter is never explained (type, format, or identifier), and file_path is only self-evident from its name. This leaves a meaningful invocation gap for at least one required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Shrink overflowing text to fit') and names the resource it operates on (overflowing text shapes), with enough algorithmic detail to differentiate it from siblings like apply_edits or set_placeholder_text. The behavior is concrete and self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the trigger condition (overflowing text), explains the all-shapes mode, and recommends export_slide_images for verification. It does not explicitly name a sibling alternative or state when not to use the tool, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and handles it well. It discloses reading order, table cell joining, cached field text, scope semantics, include_notes behavior, and the live editing side effects including that edits stay UNSAVED until live_save and that 'force' targets the open session. This is unusually transparent about a subtle mutation risk in a tool named get_text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, front-loading the core purpose before explaining parameters and side effects. Each clause earns its place, especially the live-mode semantics which need detail. The final sentence about rendered-appearance checks is slightly tangential but still valuable for disambiguation. It could be split into clearer sentences, but stays compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 4 parameters, no annotations, subtle live-editing behavior — the description is largely complete: scope, note handling, and live modes are all covered. The output schema covers return values, so that absence is not a gap. A short callout on file_path requirements or locking edge cases would make it fully complete, but the current coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does. It explains scope values explicitly ('None for all slides, a 0-based index, {"slide_id": N}, or a list'), include_notes, and the three live modes. Only file_path is left to its obvious schema meaning, with no format or path details, preventing a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Plain text of the deck in reading order.' It enumerates exactly what is included (shapes, table cells, fields) and distinguishes this from rendered-appearance concerns by pointing to the assembly-export pack. This makes the purpose unmistakable and separates it from siblings like get_presentation_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: retrieving plain text across any slide scope, optionally including notes. It also states a non-goal ('Rendered-appearance checks live in the assembly-export pack'), which implicitly routes agents away from using this tool for visual checks. It does not explicitly name alternative tools, but the usage context is concrete enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It discloses the two modes (index vs. full steps), frames the tool as a recipe/read operation, and notes its role in preventing wrong-tool detours. It does not spell out every edge case, but it gives sufficient behavioral context for a recipe-lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core purpose, and the long list of recipe names is genuinely useful for invoking the task parameter. It could be better structured with the parameter instructions separated from the enumeration, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter reference tool with an output schema, the description covers the call modes, valid inputs, and recommended usage timing. An agent has everything needed to select the correct task name and to know what behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines task as an optional string or null, with 0% description coverage in the schema itself. The description fully compensates by explaining that null returns the index, a task name returns full steps, and enumerating the valid recipe names an agent can pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a set of step-by-step workflow recipes for common jobs, naming the required packs and tool order. It goes beyond a generic label and helps an agent distinguish this meta-level guidance tool from the direct editing tools in its sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit directions: call with no task for the index and with a task name for full steps. It also advises reading the matching recipe before the first deck edit, which provides clear context, though it does not name specific alternative tools or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It discloses that the operation overwrites existing links, enforces exactly one destination, and saves atomically with a two-slot backup and an opt-out via 'backup=False skips rotation'. This is strong transparency for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but economical: the core action is front-loaded, followed by target semantics, destination rules, and persistence behavior. The 'delete_slide knows how to neuter' aside is a bit cryptic, and the insert_shape pairing is tangential, but overall the text earns its length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and seven parameters, the description covers the nontrivial parts: target resolution, unique destination, tooltip, and atomic backup. It correctly relies on the output schema for return details. A small gap remains around the expected format for file_path and slide, which prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining target's shape-id vs text-range forms, to_slide's index or slide_id object format, tooltip semantics, and backup behavior. It leaves file_path and slide formats implicit, but those are more inferable from the tool context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set a hyperlink on a shape or text range'. It also states the operation replaces any existing link, which immediately differentiates it from siblings like remove_hyperlink and list_hyperlinks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear routing context: 'Exactly one destination: url (external) or to_slide (a jump by index...)'. It also mentions how navigation buttons pair with insert_shape, helping the agent understand related tool use. It does not explicitly contrast with remove_hyperlink or list_hyperlinks, so it falls short of full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that shape-level and run-level links are both removed, orphaned link rels are dropped, media playback affordances are untouched, and saves are atomic with two-slot backup behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description packs a great deal of essential behavior into a compact, front-loaded paragraph. Every clause earns its place: target syntax, scope of removal, orphan handling, media exclusion, and save behavior. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the difficult concepts: target disambiguation, effect on runs, orphan rels, media, and atomic save behavior. The presence of an output schema covers return-value details. It falls short only by not defining the conventional params file_path and slide and not mentioning error cases such as a missing shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters in prose. It provides rich semantics for target—shape id vs. object with shape_id, paragraph, start, and end—and explains backup=False behavior. file_path and slide are not explained, but their roles are conventional and low-risk.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Remove hyperlinks from a shape or text range,' which clearly sets this apart from siblings like set_hyperlink and list_hyperlinks. It also defines the two target forms—whole shape versus specific run range—leaving no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It identifies when to apply shape-level versus run-level removal and explains the optional coverage fields. It does not explicitly name sibling tools as alternatives or state when not to use it, but the context is clear enough for straightforward hyperlink-removal tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so thoroughly. It reveals pre-resolution before mutation, whole-batch refusal on stale anchors with failed indices, result.changed mapping, no partial-apply mode, and two-slot backup behavior with backup=False skipping rotation. This gives an agent a realistic model of side effects and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it opens with the core promise, then gives the edit format, op whitelist, resolution/failure semantics, scope exclusion, and atomic/backup constraints. Every sentence earns its place and no content is wasted or repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with nested dynamic edit objects, atomicity constraints, backup behavior, and failure modes, and the description covers all of these. It also directs the agent to the correct addressing source (get_presentation_view) and to creation tools in the packs, making it nearly self-sufficient. Since an output schema exists, the mention of result.changed is a bonus, not a required return-value exposition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does for the most complex parameter, edits: it defines the op/params structure, valid ops, and address anchors. It also clarifies atomic and backup semantics. file_path is only implied by its name, but the remaining parameters receive meaningful behavioral explanation beyond the bare JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Batch editor: many edits, one lock, one backup, one atomic save' states a specific action and resource: applying multiple edits to presentation content in one atomic operation. It names the supported ops, distinguishes itself from creation tools ('nothing here inserts shapes, tables, or slides. Creation tools live in the packs'), and is clearly separate from the single-operation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when to use this tool: for many edits batched atomically, and explicitly says creation tools belong in enable_tools, not here. It also states the required anchor/addressing model and warns that atomic must stay True because v1 has no partial-apply mode. It does not explicitly contrast single-edit scenarios against siblings like search_and_replace or set_placeholder_text, but the batch framing makes this largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure and does so strongly: it states the client is notified to re-fetch the tool list, reports token cost and active surface, is idempotent, and is reversed by disable_tools. These are nontrivial behavioral traits an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to the necessary enumeration of pack contents, but it is front-loaded with the purpose and each pack list is dense rather than padded. Slightly verbose, yet every section serves the selection task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, one parameter, and no schema coverage, this is complete: it defines the parameter domain, effects, idempotence, output reporting, and reversal path. An agent can invoke it correctly without needing sibling schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are no enums, so the description fully compensates by enumerating every valid pack name and its capabilities. It also implies the exact quoted strings to use for the packs parameter, adding meaning the schema lacks entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Switch on optional tool packs mid-session,' which clearly identifies the operation and object. It is distinguishable from siblings because it explicitly references enabling optional capabilities and mentions disable_tools as the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when enabling is appropriate: mid-session when optional packs are needed, and notes that disable_tools reverses the operation. It does not explicitly enumerate when-not-to-use conditions, but no alternative enabling tool exists and the reverse tool is called out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so thoroughly. It discloses stable and durable anchor semantics, the table cell coordinate convention (1-based in this tool, 0-based in table tools), the note rendering as quoted blocks, and the meaning of each detail level including geometry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause delivers useful information: output format, anchor stability, coordinate conventions, scope options, detail levels, and the enable_tools dependency. It is front-loaded with the core purpose and organized with clear labels for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the lack of annotations, the description is exceptionally complete. It explains the returned structure, how to consume anchors downstream, coordinate system caveats, and optional parameters. The presence of an output schema covers raw return values, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains valid values for scope (None, index, object, list) and detail ('outline', 'text', 'full'). file_path is not explicitly described, though its meaning is obvious from the name and required status. This compensates well for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as producing an anchored markdown projection of a presentation, with specific structural elements: slide headers, shape blocks, tables, and notes. This distinguishes it from sibling tools like get_text, get_slide_info, and list_elements, which do not return this anchor-based view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains how to use the output (feed anchors to apply_edits), how to control scope and detail, and when to enable graphics tools. It does not explicitly contrast with alternatives such as get_text or get_slide_info, but the workflow and scope options provide practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and reveals atomic saves, two-slot backup rotation, live-session editing modes, and the critical caveat that live edits remain unsaved until live_save. It also explains layout placeholder inheritance. This is far more transparent than a bare mutation statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences are front-loaded with the core add operation followed by parameter-specific behavior. There is no filler; each clause communicates a distinct fact needed to call the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and a complex save/live-editing model, yet the description covers layout resolution, placement, backup behavior, locked-file modes, and persistence caveats. An output schema exists, so return-value details are not required. Minor gaps such as exact error handling and live='auto' behavior on unlocked files remain, but nothing blocks a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, yet the description explains layout by name or 0-based index and how to list layouts, defines position as the 0-based final index defaulting to end, and clarifies live/backup behaviors. Every non-obvious parameter is covered; file_path is the only one left to inference and is self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Add a slide built from a layout' names a specific action and resource, and the rest clarifies layout selection by name/index and placeholder inheritance. This differentiates insert_slide from siblings like delete_slide or duplicate_slide, which operate on existing slides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context: layouts can be enumerated with list_elements, whole decks start via create_presentation, and live modes govern locked-file situations. It does not explicitly exclude alternatives such as duplicate_slide for cloning an existing slide, so exclusions are implied rather than fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full disclosure. It clearly states the operation is read-only ('file is never modified'), enumerates the types of hyperlinks included, and describes broken-target detection behavior. This gives an agent a solid safety profile and behavioral expectations without relying on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver a dense but efficient definition. Every clause earns its place: scope default, included link types, broken-target detection, compatibility with mutation tools, exclusions, and read-only safety. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not detail return fields. It still covers scope semantics, exclusions, and read-only behavior, which are the main operational unknowns. The complexity is moderate, and the description fully prepares an agent to invoke it correctly, especially alongside the related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify the 'scope' parameter with 'default all slides', adding meaning beyond the bare schema. The 'file_path' parameter is left implicit, but it is a common and self-evident required string. The description also hints at the semantic coupling between the returned addresses and set_hyperlink/remove_hyperlink, which helps an agent interpret values correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: lists all hyperlinks in the presentation, covering external URLs and jump-to-slide links on shapes and text runs. It explicitly differentiates itself from siblings by clarifying what is excluded (media playback controls) and by noting relationships to set_hyperlink/remove_hyperlink.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: to inspect all hyperlinks in scope, and it notes that the returned addresses are exactly what set_hyperlink and remove_hyperlink accept, implying use for auditing before editing. It also explicitly says media playback controls are excluded, routing users to insert_video/insert_audio instead. However, it does not mention when to prefer this over list_elements or get_text, nor does it provide explicit 'when not to use' guidance beyond the media exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals that restore rotates current content into prev before overwriting, validates the payload, and performs an atomic replace; purge only deletes when dry_run=False; and backups live per-deck under .ks4p-backups/. This makes side effects and safety properties explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich with no filler; every sentence contributes behavior. It is front-loaded with the backup location and names the key state files early. However, the opening sentence is grammatically compressed and the entire definition is a single unbroken paragraph, making it slightly harder to scan than a structured bulleted form would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — six parameters, three actions, no enum hints, and no schema descriptions — the definition is remarkably complete. It covers location, state semantics, per-action parameters, validation, atomicity, undo behavior, and deletion safety. Since an output schema exists, the absence of return-value detail is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, and it does. It explains action values, scope ('orphans'/'slots'), source ('prev'/'anchor'/'.pptx'), dry_run defaults and semantics, and references file_path and directory for list/restore. All six parameters are meaningfully contextualized beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages automatic backups under .ks4p-backups/ and enumerates three distinct actions — list, restore, and purge — with specific behavior for each. This clearly distinguishes it from the sibling tools, which operate on presentation content rather than backup state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when each action is appropriate: list for discovering backup slots/orphans, restore for overwriting from a backup source, and purge for deletion with dry_run defaulting to true. It does not explicitly name alternative tools or say when not to use manage_backups, but the action-oriented guidance is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it explains overwrite refusal behavior, the backup rotation into .ks4p-backups, undoability via manage_backups, and that the source file is never modified. This goes well beyond a basic mutation warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with the core operation and use case, then the overwrite/backup behavior, then the safety guarantee. Each sentence adds distinct information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a copy operation with three simple parameters and an existing output schema, the description covers the purpose, parameter semantics, failure/overwrite behavior, backup/recovery path, and source immutability. Nothing needed to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates by explaining dest_path's explicit-path role, overwrite's default false and refusal behavior, and the source file (file_path) being untouched. Every parameter is given semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('copy') and a specific resource ('deck') with the byte-for-byte mode, and distinguishes itself from create_snapshot by noting this tool takes an explicit dest_path rather than generating a DTG-stamped name. An agent can immediately tell what operation this performs and how it differs from the closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the concrete use case (working copy before heavy edits) and names create_snapshot as the alternative for automatic DTG-stamped copies. It does not explicitly enumerate when not to use this tool, but the comparison gives sufficient routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and covers it well: idempotence ('already-disabled packs are reported, not errors'), no file mutation ('Nothing about the presentation files changes'), and side-effect scope ('only trims what this session's client has to carry'). It also discloses the report output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each adding distinct value: purpose, parameter behavior, and side effects/output. No filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is complete: purpose, valid parameter values, behavioral guarantees, side-effect scope, and output semantics are all present. An agent has enough to select and invoke the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the 'packs' parameter. It does: 'Takes the same pack names as enable_tools, or everything.' This gives valid values and a special option, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Switch pack tools back off to shrink the tool surface.' It clearly distinguishes this from the sibling enable_tools by framing it as the inverse action, and clarifies that the lite core always stays on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's intended use is clear: reduce the session's tool surface by disabling pack tools. It references enable_tools as the counterpart for pack names, implying when this tool is the appropriate choice, but it does not explicitly list exclusion criteria or compare scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses atomic save behavior, two-slot backup rotation, shared vs. cloned resources, regeneration of creation GUIDs with a corruption warning, and the effect of backup=False. This is detailed, honest behavioral disclosure beyond anything the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, with the core purpose front-loaded and every clause earning its place. The technical details are packed without becoming redundant or bloated, making it easy for an agent to extract the key facts quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and a non-trivial deep-copy operation, the description is remarkably complete: it explains the copy semantics, parameter behavior, an optional tool-pack dependency, and reliability/backup details. An output schema exists, so return-value documentation is not required from the description. No critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It fully explains slide as a 0-based index or {'slide_id': N}, position as a 0-based final index defaulting to right after the original, and backup with the semantic consequence of backup=False. Only file_path is left to its self-explanatory name, but the rest is thoroughly covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Deep-copy a slide') and goes beyond a generic action by detailing what is cloned and retargeted (notes, charts with embedded workbooks, embeddings) and what remains shared (layout, media). This clearly distinguishes the tool from siblings like insert_slide, delete_slide, and reorder_slides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using the tool: how to address the slide, where the copy goes, the design-pack prerequisite for move/hide functionality, and backup behavior. It does not explicitly name alternatives or state when not to use this tool versus insert_slide or copy_presentation, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure—and it delivers. It details destructive side effects, garbage collection behavior, jump-link neutering, atomic saves with two-slot backup, backup rotation skipping, and the nuances of live editing against a locked PowerPoint file. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but every clause earns its place. The primary destructive action and consequences are front-loaded, followed by parameter semantics, an alternative, and the live-editing caveats. Nothing is redundant, and the structure mirrors the agent's likely decision order: what it does, how to specify it, and what side effects matter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and 4 parameters, the description covers all critical aspects: object identification, backup behavior, live-session interaction, persistence caveats, and cleanup cascades. The presence of an output schema covers return-value expectations, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It clarifies the slide parameter format ('0-based index or {"slide_id": N}'), explains the live options ('auto', 'force', 'off') and their consequences, and defines backup behavior including the backup=False exception. file_path requires no further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource—'Delete a slide'—and immediately enumerates the full cascade of what gets cleaned up (notes, charts, embeddings, comments, custom-show references, section membership) and how jump links are handled. This makes the tool's function unmistakable and clearly distinct from siblings like duplicate_slide, reorder_slides, or set_slide_hidden.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to prefer an alternative: 'Prefer set_slide_hidden (design pack) when it might come back.' It also explains the live-editing modes and when each is appropriate, including the warning that edits stay unsaved until live_save and that 'off' refuses locked files. This is concrete, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It clearly states this operation is 'WITHOUT mutating anything' and reveals what checks are performed with a file path, including existence, size, PowerPoint lock state, openability, and slide count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then efficiently covers behavior, usage timing, and an alternative tool. Every sentence contributes distinct information, and the no-mutation guarantee plus the validate-tool note earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's diagnostic nature and that an output schema exists, the description is complete. It covers what the tool inspects, the optional file behavior, the non-mutating guarantee, when to invoke it, and how it differs from the validate tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully for the single optional file_path parameter. It explains what happens when file_path is provided, listing existence, size, lock state, package open status, and slide count, adding meaning the schema itself lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Self-check for this environment and, optionally, one file.' It then enumerates the exact diagnostics it reports, such as export engine availability, sandbox state, and lock state, which clearly differentiates it from content-editing sibling tools like apply_edits or insert_slide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to run the tool: 'Run it first when any tool refuses unexpectedly or an export engine seems missing.' It also names the alternative for the real opens-clean check, the validate tool, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so exceptionally. It discloses atomic saves, two-slot backup rotation, backup=False skipping rotation, and that durable slide_ids/view anchors survive while plain indices do not. These are exactly the behavioral details an agent needs beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: scope, permutation constraint, ID behavior, alternative tool, and backup semantics. The most important information is front-loaded, and there is zero filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a reordering mutation with no annotations, the description covers the critical edge cases: partial lists, index semantics, persistence of durable identifiers, atomic save, and backup behavior. Combined with the output schema, this gives an agent everything needed to invoke the tool correctly and understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, and it does. It clarifies that 'order' must contain every current 0-based slide index exactly once as a permutation, and it explains the semantics of 'backup' including the effect of backup=False. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Rearrange the whole deck in one call.' It precisely defines the operation as a permutation of all 0-based slide indices, and distinguishes it from sibling tools like move_slide by noting it is for whole-deck rearrangement, not single-slide moves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus the alternative: 'For moving ONE slide, move_slide in the design pack is simpler' and even provides the enable_tools call to access it. It also states a hard constraint (partial lists refuse), so the agent knows not to pass incomplete sequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nometalalchemist/KitchenSink4PPT'
If you have feedback or need assistance with the MCP directory API, please join our Discord server