LibreOffice MCP Tools

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as document operations versus presentation or spreadsheet tools. However, some overlap exists: document_read_text and document_read_range both handle reading content, and document_convert and document_export both involve format conversion, which could cause minor confusion in selection.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with clear prefixes (document_, presentation_, spreadsheet_) that group related operations. All names use snake_case uniformly, making them predictable and easy to parse for agents.
Tool Count3/5
With 27 tools, the count is borderline high for a single server, potentially overwhelming for agents. While the tools cover a broad range of LibreOffice operations, the number feels heavy and could be streamlined by consolidating overlapping functions like reading or conversion tools.
Completeness5/5
The tool set provides comprehensive coverage for document, presentation, and spreadsheet workflows, including creation, reading, updating, conversion, and metadata operations. There are no obvious gaps; agents can perform full CRUD/lifecycle tasks across all supported file types without dead ends.
Average 3.6/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal whether this is a destructive mutation (likely yes, but not confirmed), what permissions are needed, how errors are handled (e.g., invalid index), or the response format. This leaves significant gaps for a tool that modifies document 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 directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks details on behavioral traits (e.g., side effects, error handling), output expectations, and usage context, making it incomplete for safe and effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (docId, paragraphIndex, style) with clear descriptions. The description adds no additional parameter semantics beyond implying that 'style' includes heading and paragraph types, which is already suggested by the schema's example values. 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 ('Apply a heading or paragraph style') and target ('to a specific paragraph by index'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like document_replace_text or document_insert_paragraph, which might also affect paragraph formatting, 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 document), exclusions, or comparisons to other styling-related tools that might exist in the context, 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 of behavioral disclosure. It states the tool inserts a paragraph, implying a mutation, but lacks details on permissions, side effects (e.g., impact on existing content), error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core action and resource without unnecessary words. It efficiently communicates the purpose without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 mutation operation with no annotations and no output schema, the description is insufficient. It lacks information on behavioral traits, return values, error conditions, and how it differs from similar tools, leaving significant gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the tool uses these parameters for insertion, but it does not compensate for any gaps since there are none. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('insert a new paragraph') and target resource ('Writer document'), with specificity about location ('at a specific index'). However, it does not explicitly differentiate from sibling tools like 'document_insert_text' or 'document_replace_text', which also modify document content, leaving some ambiguity about when to choose this tool over those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'at a specific index' but does not clarify scenarios where inserting a paragraph is preferred over inserting text or other document operations, nor does it reference sibling tools like 'document_insert_text' for context-specific choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool modifies text ('replace') but doesn't disclose critical behavioral traits such as whether changes are saved automatically, if it requires write permissions, potential side effects on formatting, or error handling. The description is minimal and lacks necessary context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It's appropriately sized with no wasted words, though it could be slightly more structured by separating optional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like save requirements, permissions, or return values. Given the complexity of modifying documents, more context is needed to adequately guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain interactions between parameters like replaceAll and caseInsensitive). Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find and replace text') and the resource ('Writer document'), which distinguishes it from siblings like document_insert_text or document_search. However, it doesn't explicitly differentiate from document_search which also finds text, though that tool likely doesn't replace.
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 mentions 'Optionally replace all occurrences' which hints at usage but provides no explicit guidance on when to use this tool versus alternatives like document_search or document_insert_text. There's no mention of prerequisites (e.g., document must be open) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool adds a slide but doesn't disclose permissions needed, whether changes are saved automatically, error conditions, or what happens to slide order. 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 action without unnecessary words. Every part ('Add a new slide to a presentation') directly contributes to understanding the tool's function, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context relative to siblings, and output details. Given the complexity of adding slides and the absence of structured data, more descriptive content 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 parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'docId' refers to a presentation and 'title', 'body', 'notes' are slide components. 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 ('Add') and resource ('new slide to a presentation'), making the purpose immediately understandable. It distinguishes from siblings like 'presentation_update_slide' by specifying creation rather than modification. However, it doesn't explicitly differentiate from other slide-related tools like 'presentation_list_slides', keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open document via 'document_open'), exclusions, or comparisons to sibling tools like 'presentation_update_slide' for modifying existing slides. This leaves the agent without contextual usage cues.
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 'Update' implying a mutation, but fails to specify permissions needed, whether changes are reversible, rate limits, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, or return values, leaving significant gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'title or body text' but does not provide additional context beyond what the schema specifies, such as formatting rules or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('title or body text of an existing slide'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'presentation_get_slide' or 'presentation_add_slide', which would require more specific context about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'presentation_add_slide' for creating new slides or 'presentation_get_slide' for viewing. It lacks explicit context, prerequisites, or exclusions, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an 'Add' operation (implying mutation) but doesn't describe what happens on success/failure, whether sheet names must be unique, what happens if headers are provided, or any permission requirements. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for this straightforward operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what happens on errors, or important behavioral constraints. The 100% schema coverage helps with parameters, but overall context for using this tool safely and effectively is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new sheet') and the target resource ('to a spreadsheet workbook'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'spreadsheet_list_sheets' or 'spreadsheet_set_range' beyond the obvious action 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing an open document via 'document_open'), nor does it specify when this operation is appropriate versus other spreadsheet manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a write operation ('Set multiple cell values'), implying mutation, but lacks critical details: whether it overwrites existing data, requires specific permissions, handles errors (e.g., invalid ranges), or returns confirmation. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that directly state the action and a key requirement. It's front-loaded with the core purpose and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success (e.g., returns confirmation, updates in real-time) or failure, nor does it cover behavioral aspects like idempotency or side effects. Given the complexity of modifying spreadsheet data, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds minimal value beyond the schema: it mentions '2D array of values matching the range,' which aligns with the 'values' parameter description in the schema but doesn't provide additional context like formatting examples or constraints. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set multiple cell values') and resource ('in a spreadsheet'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'spreadsheet_set_cell' (which presumably sets a single cell) or 'document_replace_text' (which modifies text documents rather than spreadsheets), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'spreadsheet_set_cell' for single-cell updates or 'document_replace_text' for text documents, nor does it specify prerequisites (e.g., needing an open document via 'document_open') or exclusions (e.g., not for read-only operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves content, implying a read-only operation, but does not address potential behaviors like error handling (e.g., invalid slide index), permissions needed, or rate limits. This leaves significant gaps for a tool that interacts with documents.
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 purpose ('Get the full content of a specific slide') and specifies the content retrieved. There is no wasted language, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving slide content), no annotations, and no output schema, the description is minimally adequate. It covers what content is returned but lacks details on output format, error cases, or integration with sibling tools. This results in a score of 3, indicating clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with docId and slideIndex clearly documented in the input schema. The description adds no additional parameter semantics beyond implying slideIndex is 0-based (which is already in the schema). This meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the full content') and resource ('a specific slide'), specifying what content is retrieved (title, body text, and speaker notes). It distinguishes from siblings like presentation_list_slides (which lists slides) and presentation_get_notes (which might focus only on notes), but does not explicitly name alternatives, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like presentation_list_slides or document_read_range, nor does it mention prerequisites such as needing an open document handle. It implies usage by specifying what it does but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read-only operation ('List'), but doesn't cover aspects like permissions needed, rate limits, pagination, or error handling. This leaves significant gaps for a tool that interacts with external resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic operation but lacks details on behavioral traits and usage context, which are important for a tool without annotations. This results in a score of 3, indicating it's viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'docId' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all sheets in a spreadsheet'), specifying what information is returned ('names, row counts, and column counts'). However, it doesn't explicitly differentiate from sibling tools like 'spreadsheet_get_range' or 'spreadsheet_add_sheet', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a document handle from 'document_open'), exclusions, or comparisons to other tools like 'spreadsheet_get_range' for specific data retrieval.
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 disclosure. It states what the tool does but doesn't mention permissions required, whether the insertion is reversible, how it handles existing content, or what happens on success/failure. For a mutation 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 with just two sentences that directly state the tool's function and positioning options. Every word serves a purpose with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after insertion, error conditions, or how the tool interacts with document state. Given the complexity and lack of structured coverage, more context about behavioral 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 parameters thoroughly. The description adds minimal value beyond the schema by mentioning position options ('start', 'end', or after a specific heading text'), which is already covered in the position parameter's enum and description. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Insert text'), target resource ('Writer document'), and positioning mechanism ('at a specified position'). It distinguishes itself from siblings like document_insert_paragraph (which inserts paragraphs) and document_replace_text (which replaces rather than inserts).
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 document_insert_paragraph or document_replace_text. The description mentions position options but doesn't explain scenarios where one position choice is preferable over another or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a listing operation but doesn't disclose behavioral traits like whether this requires specific permissions, what happens if no documents are open (empty list vs error), whether the list is real-time or cached, or any rate limits. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all currently open documents') followed by specific return attributes. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what information is returned but doesn't describe the return format (e.g., array of objects), error conditions, or behavioral constraints. For a read-only listing tool, this is minimally viable but lacks completeness about how the tool behaves in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it correctly focuses on what the tool does rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all currently open documents') with specific attributes (docId, file path, format, size). It distinguishes from siblings like document_get_metadata or document_read_text by focusing on listing open documents rather than reading content or metadata of specific documents. However, it doesn't explicitly differentiate from document_list_sheets or presentation_list_slides which serve similar listing functions for different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use document_list versus document_get_metadata for document information, or document_list versus document_open for accessing documents. There's no context about prerequisites (e.g., requires documents to be open) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions saving state but lacks critical behavioral details: whether this overwrites files, requires write permissions, handles errors (e.g., invalid path), or confirms success. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('save the current state') and includes key details (file path options). Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 with potential side effects (file overwriting), the description is incomplete. It should address behavioral risks, error handling, or output expectations, but does not, leaving significant gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (docId, filePath) with clear descriptions. The description adds minimal value beyond schema, mentioning 'original path' which aligns with schema's optional note, but no additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('save') and resource ('current state of a document'), specifying it saves to a file path (original or new). It distinguishes from siblings like document_export (conversion) or document_close (closing without saving), but doesn't explicitly name alternatives, keeping it at 4.
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 saving document changes, with optional new path for saving elsewhere. It doesn't explicitly state when to use vs. alternatives like document_export (for format conversion) or document_close (discarding changes), nor mention prerequisites (e.g., document must be open), leaving gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool's action but lacks behavioral details such as permissions required, rate limits, error conditions (e.g., invalid slideIndex), or output format (e.g., structured notes vs. raw text). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose and key parameter behavior. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., notes format, structure), error handling, or dependencies (e.g., requires an open document). For a tool with 2 parameters and no structured output info, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (docId and slideIndex). The description adds minimal value by clarifying that omitting slideIndex returns all notes, which is implied by the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'speaker notes for all slides or a specific slide', making the purpose explicit. It distinguishes from siblings like 'presentation_get_slide' (which retrieves slide content) by focusing on notes, but doesn't explicitly differentiate from other note-related tools (none exist in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'Omit to get all notes' for the slideIndex parameter, which suggests when to use the optional parameter. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. 'presentation_get_slide' for slide content) or prerequisites like needing an open document.
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. It mentions 'open it' and returns a docId, but doesn't disclose important behavioral traits like whether this requires write permissions, if the file is saved immediately, what happens if filePath exists, or error conditions. The description is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence states core functionality and return value. Second sentence efficiently lists supported document types with their file extensions. Perfectly front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation/mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'open it' means operationally, doesn't mention permissions or side effects, and provides minimal context about the returned docId. Should do more given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds minimal value by listing the three documentType enum values and mentioning filePath, but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new empty document and open it') and the resource (document), with specific document types listed. It distinguishes from siblings like document_open (opens existing) or document_convert (converts format).
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 creating new documents, but doesn't explicitly state when to use this vs. alternatives like document_open for existing files or document_convert for format changes. It provides context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that changes are 'saved immediately' (important behavioral trait), but doesn't mention error conditions, permission requirements, rate limits, or what happens if the cell doesn't exist. It adequately describes the core mutation behavior but lacks comprehensive operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the core purpose. Every word earns its place - no redundancy, no unnecessary elaboration. Perfectly sized for the tool's complexity.
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 context but lacks important details about error handling, return values, and operational constraints. It covers the 'what' but not the 'what happens if' or 'what you get back' aspects that would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., doesn't clarify precedence rules beyond what's in the formula parameter description). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Set the value or formula'), target resource ('single cell in a spreadsheet'), and scope ('immediately saved'), distinguishing it from sibling tools like spreadsheet_set_range (which handles multiple cells) and spreadsheet_get_formulas (which is read-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting individual cell values/formulas but doesn't explicitly state when to use this vs. alternatives like spreadsheet_set_range for multiple cells or document_insert_text for text documents. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the LibreOffice dependency and supported formats, which are useful behavioral traits. However, it doesn't cover critical aspects like whether the export modifies the original document, error handling, or output file behavior beyond the default path hint.
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?
Three sentences with zero waste: first states core purpose, second lists supported formats, third gives prerequisite. Each sentence adds essential information, and the description is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers purpose, formats, and prerequisite well. However, it lacks details on mutation behavior (e.g., whether original document is altered), error cases, or output specifics, leaving some gaps for a tool that performs file operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no parameter-specific semantics beyond implying format options (listed in schema enum) and a default output path behavior, which is partially covered in schema. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Export a document to a different format') and resource ('document'), distinguishing it from siblings like document_convert (which might convert without export) or document_save (which saves in original format). The mention of LibreOffice adds technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying supported formats and a prerequisite (LibreOffice must be installed), but lacks explicit guidance on when to use this tool versus alternatives like document_convert or document_save. No exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns matching paragraphs/cells/slides with surrounding context, which is useful behavioral information. However, it doesn't mention important traits like whether it requires document_open first, performance characteristics, or error handling for invalid queries, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that directly state the tool's function and return value. Every word earns its place, and it's front-loaded with the core purpose. No unnecessary information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and return format but lacks details on behavioral traits, error conditions, or output structure. For a search tool with 3 parameters, this is minimally adequate but leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents all parameters. The description doesn't add any additional meaning beyond what's in the schema descriptions (e.g., it doesn't explain search algorithm details or context window size). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Search') and resource ('text within a document'), and distinguishes it from siblings by specifying it returns matching content with context, unlike document_read_text or document_read_range which read specific sections without search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning it searches within a document and returns matches, suggesting it's for finding specific content rather than reading entire documents. However, it doesn't explicitly state when to use alternatives like document_read_text for direct reading or document_list for browsing documents, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait of returning formulas rather than values, which is crucial. However, it doesn't mention permissions needed, rate limits, error conditions, or output format details, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and adds critical clarification about returning formulas vs. values. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description covers the essential 'what' but lacks details on output structure, error handling, or dependencies. It's minimally viable but leaves the agent guessing about the return format and potential limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no parameter-specific information beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all formulas in a spreadsheet range'), specifying it returns formula expressions rather than computed values. This distinguishes it from sibling tools like spreadsheet_get_range (which likely returns values) and spreadsheet_set_cell/spreadsheet_set_range (which are write operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'returns formula expressions, not computed values', suggesting when to use this vs. value-retrieval tools. However, it doesn't explicitly name alternatives or state when-not-to-use conditions, though the distinction from computed values provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's purpose and efficiency focus ('token-efficient overview'), but lacks details on behavioral traits like pagination, rate limits, permissions needed, or error handling. This is a moderate gap for a read operation without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place, with no redundancy or fluff, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only operation), no annotations, and no output schema, the description is reasonably complete. It covers purpose and usage context but could improve by hinting at output structure (e.g., list of slides with indices/titles) or error cases, which would make it a 5.
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 one parameter 'docId' fully documented in the schema as 'Document handle returned by document_open'. The description does not add any meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all slides in a presentation' with specific outputs 'index and title'. It distinguishes from siblings like presentation_get_slide (gets single slide content) and presentation_get_notes (gets notes), focusing on a token-efficient overview rather than detailed content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Token-efficient overview before reading content', implying this tool is for initial scanning rather than detailed analysis. However, it does not explicitly state when not to use it or name specific alternatives like presentation_get_slide for detailed content, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the read operation and efficiency characteristics, but doesn't mention important behavioral aspects like error conditions (e.g., what happens with invalid indices), performance characteristics beyond token efficiency, or what format the returned content takes. It provides some useful context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences that each earn their place. The first sentence states the core functionality, and the second provides crucial comparative guidance. There's zero wasted text and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (range-based reading with document type variations), no annotations, and no output schema, the description provides adequate but incomplete context. It covers the purpose and comparative usage well, but lacks details about return format, error handling, and specific behavioral characteristics that would be important for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds minimal value beyond what's in the schema - it mentions paragraph/slide indexing but doesn't provide additional semantic context about parameter usage, constraints, or 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.
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 ('Read a specific range of a document'), identifies the resource (document), and specifies the mechanism (by paragraph index for Writer or slide index for Impress). It also explicitly distinguishes this tool from its sibling 'document_read_text' by mentioning token efficiency for specific sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when you only need a specific section') and when to use an alternative ('More token-efficient than document_read_text'). This directly addresses the sibling tool context and gives clear comparative usage advice.
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's a cleanup operation that releases resources and specifically mentions temp files from format bridging. This gives the agent important context about side effects and resource management that isn't obvious from the tool name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that's perfectly front-loaded with the core action, followed by important parenthetical clarification about resource release. Every word earns its place with zero redundancy or wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter cleanup tool with no output schema, the description provides adequate context about what the tool does and its behavioral implications. The mention of temp files from format bridging adds valuable specificity. However, it doesn't address potential error conditions or confirmations, which would be helpful for a destructive-sounding 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 the single parameter completely. The description adds no additional parameter information beyond what's in the schema (docId is described as 'Document handle returned by document_open' in both places). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close') and target resource ('an open document'), distinguishing it from siblings like document_save (persist changes) or document_open (acquire handle). It explicitly mentions releasing resources, which is unique to this tool among document operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'an open document' and referencing 'document handle returned by document_open', clearly indicating this tool should be used after document_open. However, it doesn't explicitly state when NOT to use it (e.g., vs. document_save for saving changes) or name alternatives for related cleanup operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it 'Creates a new file; original is not modified' (clarifying non-destructive nature), specifies the underlying technology ('using LibreOffice CLI'), and states a system requirement ('LibreOffice must be installed'). This covers mutation behavior, safety, and prerequisites, though it lacks details on error handling or performance 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 appropriately sized and front-loaded, with three concise sentences that each earn their place: the first states the core purpose, the second clarifies behavior and provides usage examples, and the third specifies a prerequisite. There is zero waste or redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (file conversion with system dependencies), no annotations, and no output schema, the description is largely complete. It covers purpose, behavior, usage examples, and prerequisites. However, it does not describe the return value or potential error cases, which would be helpful for an agent invoking the tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (filePath, format, outputPath) with descriptions and an enum for format. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining format constraints or outputPath behavior. The baseline score of 3 is appropriate given the comprehensive schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Convert a document file to a different format') and resource ('document file'), using the verb 'Convert' with the tool name 'document_convert'. It distinguishes from siblings like 'document_export' by specifying the LibreOffice CLI method and providing concrete examples of conversions (DOC→DOCX, DOCX→PDF, etc.).
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 ('Useful for: DOC→DOCX, DOCX→PDF, XLSX→CSV, etc.') and mentions a prerequisite ('LibreOffice must be installed'). However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'document_export' which might serve a similar purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about supported formats and automatic conversion via LibreOffice, but does not mention permissions, rate limits, or error handling. It adequately describes the core behavior without contradictions, but lacks depth on operational traits.
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 main purpose in the first sentence, followed by supporting details in a structured list of formats and conversion notes. Each sentence adds necessary information without redundancy, making it efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (opening files with format support), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, and behavioral aspects like conversion, but could improve by detailing return values or error cases, though the output is implied as a docId handle.
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 the single parameter 'filePath', so the baseline is 3. The description adds value by implying the parameter is used to specify a document file for opening, though it does not provide additional syntax or format details beyond the schema's description of 'Absolute or relative path'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a document file') and the resource ('document file'), specifying it returns a docId handle for use with other tools. It distinguishes from siblings by focusing on opening files rather than creating, converting, or manipulating documents, making the purpose specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing supported file formats and mentioning automatic conversion for legacy formats, which helps users know when this tool is applicable. However, it does not explicitly state when to use alternatives like document_convert or document_create, missing explicit exclusions or comparisons with 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?
No annotations are provided, so the description carries full burden. It effectively discloses key behavioral traits: it's a read-only operation (implied by 'Get'), requires an open document (via docId from document_open), and is 'Token-efficient' (a performance consideration). However, it doesn't mention error handling, rate limits, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: the first states purpose and lists metadata fields, the second provides usage guidance. It's front-loaded with essential information and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, 100% schema coverage, no output schema), the description is largely complete. It covers purpose, usage, and key behavioral aspects. A minor gap is the lack of output format details (e.g., structure of returned metadata), but this is partially mitigated by the listed metadata fields.
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 docId parameter fully documented in the schema. The description adds no additional parameter details beyond what the schema provides (e.g., no examples or format specifics), so it meets the baseline of 3 without compensating further.
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 metadata') and resource ('an open document'), listing concrete metadata fields (title, author, page count, etc.). It distinguishes from siblings like document_read_range or document_read_text by focusing on metadata rather than content.
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?
Explicitly states when to use this tool ('use this before reading document content to understand its size and structure') and implies when not to use it (e.g., for content reading, use document_read_range or document_read_text instead). This provides clear context relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively communicates key behavioral traits: it's a read-only operation (implied by 'Get'), describes what information is returned for different document types, and mentions the 'token-efficient' performance characteristic. However, it doesn't address potential limitations like document size constraints 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 perfectly structured with a clear opening statement followed by bullet points for different document types and a concluding usage guideline. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description provides excellent context about what information is returned for different document types and clear usage guidance. The only minor gap is the lack of explicit mention about return format or potential error cases, but overall it's highly complete for its complexity level.
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% for the single parameter 'docId', which is adequately described in the schema. The tool description doesn't add any additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Get') and resource ('structural outline of a document'), with explicit details about what this entails for different document types (Writer, Calc, Impress). It distinguishes from siblings like document_read_text by focusing on structure rather than content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('always call this before document_read_text to understand structure'), making it clear this is a prerequisite step for efficient content reading. It distinguishes from document_read_text by explaining the token-efficiency rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the output format (Markdown text), pagination support for large documents, default character limit (4000 characters), and a prerequisite suggestion (use document_get_outline first). It doesn't mention error conditions, performance implications, or authentication needs, but covers essential operational context adequately.
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 three concise sentences with zero waste. The first sentence states the core purpose, the second addresses large documents and pagination, and the third provides a prerequisite recommendation. Each sentence adds critical information, and it's front-loaded with the main functionality.
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 read operation: purpose, usage guidelines, behavioral traits (format, pagination, defaults), and sibling differentiation. It doesn't describe the return value structure (e.g., whether it's a string or object), which is a minor gap since there's no output schema, but overall it's quite complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it implies that limit/offset are for pagination (though the schema says 'items' vs. characters), and mentions the 4000-character default (which matches maxChars default). No additional syntax or format details are provided, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Read document content as Markdown text'), identifies the resource ('document content'), and distinguishes from siblings like document_read_range (which reads specific ranges) and document_get_outline (which provides structure). It goes beyond a simple restatement of the name by specifying the output format (Markdown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'For large documents, use limit/offset for pagination' and 'Use document_get_outline first to understand structure.' It also mentions the default character limit (4000), helping the agent decide when pagination is needed. This directly addresses sibling tools like document_get_outline and document_read_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation (implied by 'Read'), returns data in structured formats, supports pagination when range is omitted, and emphasizes token efficiency. However, it doesn't mention rate limits, authentication needs, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidelines and efficiency tips. Every sentence earns its place: the first states what it does, the second explains output formats, the third clarifies range usage, and the fourth advises on token efficiency. No 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?
Given the complexity (6 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, usage, output formats, and parameter guidance. However, it lacks details on error cases, authentication, or exact return structure, which could be helpful for a read tool with multiple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantics of the 'range' parameter (e.g., 'A1:D10' for specific cells, omitting for paginated full sheet) and implicitly clarifying 'limit' and 'offset' through pagination context. It doesn't detail all parameters but enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Read a range of cells') and resources ('from a spreadsheet sheet'), distinguishing it from siblings like spreadsheet_get_formulas (formulas only) or spreadsheet_set_range (write operation). It explicitly mentions the output formats (JSON and markdown table), which further clarifies its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: it advises specifying a range for token efficiency rather than reading the whole sheet, and mentions omitting the range for paginated full sheet access. It also distinguishes from siblings by focusing on reading cell data (not formulas, metadata, or writing).
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:

[![libreoffice-mcp-tools MCP server](https://glama.ai/mcp/servers/passerbyflutter/libreoffice-mcp-tools/badges/card.svg)](https://glama.ai/mcp/servers/passerbyflutter/libreoffice-mcp-tools)

Score Badge

Copy to your README.md:

[![libreoffice-mcp-tools MCP server](https://glama.ai/mcp/servers/passerbyflutter/libreoffice-mcp-tools/badges/score.svg)](https://glama.ai/mcp/servers/passerbyflutter/libreoffice-mcp-tools)

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/passerbyflutter/libreoffice-mcp-tools'

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