Outline Wiki MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists. For example, 'search_documents' and 'find_related' both involve document discovery, though 'find_related' is semantic. 'archive_document' and 'delete_document' (with permanent=false) both involve removal, but descriptions clarify differences. Overall, descriptions help, but a few tools could be confused without careful reading.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'create_document', 'list_collections', 'update_document', and 'delete_collection'. All tools use snake_case, and verbs are predictable (e.g., add, archive, ask, batch, create, delete, export, get, list, move, restore, search, sync, unarchive, update). No deviations or mixed conventions are present.
Tool Count3/5
With 37 tools, the count is borderline high for a wiki server, feeling heavy compared to typical well-scoped sets of 3-15 tools. While the tools cover extensive operations, it may overwhelm agents. However, given the domain's complexity, it's not extreme, but leans toward too many for optimal coherence.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for documents and collections, including creation, reading, updating, deletion, archiving, restoration, and export. It also includes advanced features like AI-powered search, summarization, diagram generation, and batch operations. No obvious gaps exist; agents can handle all core wiki workflows without dead ends.
Average 2.9/5 across 37 of 37 tools scored. Lowest: 2.3/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 full burden for behavioral disclosure. 'Update collection information' implies a mutation operation but reveals nothing about permissions required, whether changes are reversible, side effects on related resources, error conditions, or response format. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. While this brevity comes at the cost of informativeness, there's no wasted language or unnecessary elaboration. Every word ('Update', 'collection', 'information') contributes directly to the core message, making it front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what 'updating collection information' entails, what parameters are available, what the operation returns, or how it differs from similar tools. The agent lacks sufficient context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description provides no information about parameters beyond what's implied by the name 'update_collection'. It doesn't explain what 'collectionId', 'name', 'description', or 'color' represent, their constraints, or how they interact. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update collection information' is a tautology that essentially restates the tool name 'update_collection'. It specifies the resource ('collection') but lacks specificity about what aspects can be updated or how this differs from similar tools like 'update_document' or 'batch_update_documents'. While it indicates a mutation operation, it doesn't provide meaningful differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing collection), exclusions, or comparisons to sibling tools like 'batch_update_documents' for multiple updates or 'update_document' for document-level changes. The agent receives no contextual cues about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It doesn't specify whether archiving is reversible, requires specific permissions, affects document accessibility, or has side effects (e.g., removing from regular listings). This leaves critical behavioral traits undisclosed 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 extremely concise with a single sentence ('Archive a document.'), which is front-loaded and wastes no words. For a simple tool, this brevity is appropriate, though it may sacrifice clarity for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral aspects, parameter details, or expected outcomes, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description adds no semantic information about 'documentId' (e.g., format, source, or constraints). This fails to compensate for the schema's lack of documentation, leaving the parameter's meaning unclear beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Archive') and resource ('a document'), which provides a basic understanding of what the tool does. However, it lacks specificity about what 'archive' means in this context (e.g., moving to an archived state vs. permanent deletion) and doesn't differentiate from sibling tools like 'batch_archive_documents' or 'unarchive_document', making it vague in comparison.
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., document must exist), exclusions (e.g., cannot archive already archived documents), or related tools like 'unarchive_document' for reversal or 'list_archived_documents' for viewing archived items, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' implies a write operation, but doesn't disclose behavioral traits such as permissions needed, whether it's idempotent, rate limits, or what happens on failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Create a new document.', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, but structurally it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation, no annotations, no output schema), the description is incomplete. It doesn't explain the creation process, return values, error handling, or how it fits with siblings, making it insufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no meaning beyond the schema—no explanation of what parameters like 'collectionId', 'parentDocumentId', or 'publish' do, their formats, or default behaviors. With 5 parameters, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new document' clearly states the verb ('Create') and resource ('document'), which is better than a tautology. However, it lacks specificity about what kind of document or system (e.g., wiki, CMS) and doesn't differentiate from sibling tools like 'batch_create_documents' or 'create_collection', making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a collectionId), exclusions, or comparisons to siblings like 'batch_create_documents' for multiple documents or 'create_collection' for creating collections instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Export a collection' implies a read-only or data extraction operation, but it fails to specify aspects like output format details, file handling, permissions required, or potential side effects (e.g., if it modifies the collection). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Export a collection.', which is front-loaded and wastes no words. While it may be under-specified, it is structurally efficient and easy to parse, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, no output schema), the description is incomplete. It does not explain what 'export' means in practice, the parameters involved, or the expected output, making it inadequate for an agent to use the tool effectively without additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description does not mention any parameters, such as 'collectionId' or 'format', nor does it explain their semantics (e.g., that 'format' can be 'outline-markdown' or 'json'). This fails to compensate for the lack of schema documentation, leaving parameters unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export a collection' states a clear verb ('Export') and resource ('a collection'), providing a basic understanding of the tool's function. However, it lacks specificity about what 'export' entails (e.g., file generation, data transfer) and does not distinguish it from sibling tools like 'export_all_collections' or 'export_document', making it vague in comparison.
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 does not mention prerequisites, such as needing an existing collection, or compare it to siblings like 'export_all_collections' for bulk operations or 'export_document' for individual documents, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to describe how 'semantically related' is determined, what the output format looks like, whether results are ranked, if there are rate limits, or what permissions are required. For a tool with no annotation coverage, this leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and uses precise terminology ('semantically related'). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of semantic search, lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address how similarity is measured, result format, error conditions, or performance characteristics. For a tool that likely involves non-trivial computation, this leaves too many unknowns for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'documentId' refers to (e.g., UUID, title, path) or how 'limit' affects results (e.g., top-N matches). With 2 parameters completely undocumented in both schema and description, this creates significant ambiguity for the agent.
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 ('find') and resource ('documents semantically related to a specific document'), making the purpose understandable. It distinguishes from obvious siblings like 'search_documents' by specifying semantic relationships rather than keyword-based searches. However, it doesn't explicitly differentiate from 'get_document_backlinks' which might also find related documents.
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 'search_documents' or 'get_document_backlinks'. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires specific permissions, what the output looks like (file, data structure), or any side effects like rate limits or system impact.
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?
Extremely concise with just three words, front-loaded with the core action. Every word earns its place by specifying the verb, scope, and target without any fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that presumably performs a bulk export operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'export' entails (e.g., file download, data return), scope limitations, or error handling, leaving significant gaps for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the single parameter 'format' has an enum with clear options. The description adds no parameter semantics beyond what the schema provides, but with only one optional parameter and enum values, the baseline is adequate. No additional context about format implications is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export all collections' clearly states the action (export) and target (all collections), but it's vague about what 'export' means in practice. It distinguishes from sibling 'export_collection' by specifying 'all' vs. single collection, but doesn't clarify the scope or output format beyond the schema's enum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'export_collection' for single collections or other export-related tools. The description implies bulk export but doesn't specify prerequisites, timing, or constraints that would help an agent choose appropriately.
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 adds a comment and supports replies, but doesn't disclose behavioral traits like permissions needed, rate limits, whether comments are editable/deletable, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part ('Add a comment to a document. Supports replies.') earns its place by stating core functionality and an additional feature efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers basic purpose but lacks details on behavior, parameter usage, error handling, or return values. For this complexity level, it should provide more context to be adequately helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies parameters for document and text, and hints at 'replies' for parentCommentId, but doesn't explain what each parameter means, their formats, or usage. With 3 parameters and no schema descriptions, the description adds minimal semantic value beyond basic inference.
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 comment') and resource ('to a document'), with additional functionality indicated ('Supports replies'). It distinguishes from siblings like 'get_comment' (read) and 'list_document_comments' (list), though not explicitly named. The purpose is specific but could better differentiate from other comment-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It mentions 'Supports replies,' which hints at context for threaded comments, but doesn't specify when to use parentCommentId versus not, or contrast with other comment or document tools. The description lacks explicit when/when-not instructions or named alternatives.
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. 'Create multiple documents at once' implies a write operation but doesn't specify permissions required, whether it's atomic/all-or-nothing, rate limits, or what happens on partial success. The description is too minimal 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 maximally concise with a single clear sentence. Every word earns its place by specifying the batch nature of the operation. No wasted words 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 batch creation tool with complex nested parameters (5 sub-properties), no annotations, and no output schema, the description is severely incomplete. It doesn't explain the document structure, required fields, default behaviors, or what the tool returns. The minimal description fails to compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. The single 'documents' parameter and its complex nested structure (with 5 sub-properties including required fields) are completely undocumented in the description. This leaves the agent guessing about required formats and 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 ('create multiple documents') and resource ('documents'), making the purpose immediately understandable. It distinguishes from the sibling 'create_document' by specifying batch functionality. However, it doesn't specify what kind of documents or system context, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_document' or other batch operations. It doesn't mention prerequisites, performance considerations, or error handling for partial failures in batch creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action ('move') without disclosing behavioral traits. It doesn't mention permissions required, whether moves are reversible, effects on document metadata or links, error handling for invalid IDs, or rate limits. 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 with zero waste—'Move multiple documents at once' is front-loaded and appropriately sized for the tool's purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation with 3 parameters), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on behavior, parameters, usage context, and expected outcomes, which are critical for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'documentIds', 'collectionId', or 'parentDocumentId' represent, their formats (e.g., UUIDs), or how they interact (e.g., moving documents to a collection or under a parent). This leaves key semantics undocumented.
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 'Move multiple documents at once' clearly states the verb ('move') and resource ('documents'), with the 'multiple...at once' specifying batch operation. However, it doesn't explicitly differentiate from the sibling 'move_document' tool, which handles single document moves, though the batch nature is implied.
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 'move_document' for single moves or other batch operations. The description implies batch usage but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose behavioral traits such as permissions required, whether updates are atomic or partial, error handling for failed updates, rate limits, or what happens to unspecified fields. 'Update' implies mutation but lacks critical details for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly conveying the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on usage context, parameter semantics, behavioral implications, and expected outcomes, making it inadequate for safe and effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain the 'updates' array structure, required 'documentId', optional fields like 'title' and 'text', or the 'append' boolean behavior. The description fails to provide meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple documents at once' clearly states the action (update) and resource (documents) with a specific scope (multiple/batch). It distinguishes from single-document updates like 'update_document' by emphasizing batch capability, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'update_document' or 'batch_create_documents'. The description implies batch operations but doesn't specify prerequisites, constraints, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether this requires specific permissions, what happens if the document doesn't exist, whether the export is immediate or queued, or any rate limits. 'Export' suggests a read operation but lacks confirmation of safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Every word contributes to the core purpose. The structure is front-loaded with the essential action and format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what the export produces (file content? download link?), error conditions, or behavioral details needed for reliable use. The context demands more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'documentId' represents, how to obtain it, or format requirements beyond the schema's 'minLength: 1'. The single parameter remains semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Export') and resource ('document') with specific format ('Markdown format'). It distinguishes from siblings like 'export_collection' or 'export_all_collections' by focusing on single documents, but doesn't explicitly differentiate from other document export operations if they existed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'export_collection' or 'export_all_collections'. The description implies it's for single documents but doesn't specify prerequisites, limitations, or when other export methods 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 the full burden of behavioral disclosure. It states the tool 'finds' an ID, implying a read-only lookup, but doesn't specify whether it returns a single ID or multiple matches, what happens if no match is found, or if there are rate limits or authentication requirements. For a lookup tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse. Every word earns its place, and there's no 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?
Given the tool's complexity (a lookup with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., string ID, error handling), parameter constraints, or how it differs from sibling tools. For a tool that likely returns critical identifiers, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'by title,' which hints at the 'query' parameter's purpose, but doesn't explain what 'query' should contain (e.g., exact title, partial match) or the role of 'collectionId' (optional UUID for scoping). With 2 parameters and no schema descriptions, the description adds minimal value beyond the tool name.
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 'Find document ID by title' clearly states the verb ('Find') and resource ('document ID'), specifying the lookup mechanism ('by title'). It distinguishes from siblings like 'get_document' (which retrieves full content) and 'search_documents' (which performs broader searches), though it doesn't explicitly name these alternatives. The purpose is specific but could be more precise about the exact matching behavior.
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 prefer it over 'search_documents' (which might also return IDs) or 'get_document' (if the ID is already known). There are no prerequisites, exclusions, or context about its role in the workflow, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Get list'), but doesn't disclose pagination behavior (limit/offset), authentication needs, rate limits, error conditions, or what the returned list structure looks like. For a tool with 3 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately front-loaded with the core purpose, making it easy to scan and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain parameter usage, return format, error handling, or how it relates to sibling tools. For a list operation with pagination parameters, more context is needed to use it effectively beyond just knowing it fetches comments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'documentId' implicitly via 'on a document', but doesn't explain what format this ID should be, where to get it, or the purpose of 'limit' and 'offset' parameters. The description adds almost no meaning beyond the bare schema, leaving parameters largely unexplained.
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 list') and resource ('comments on a document'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_comment' (singular) or 'get_document' (which might include comments), but the focus on listing comments is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention whether this should be used instead of 'get_document' (which might include comments) or 'get_comment' (for a single comment), nor does it specify prerequisites like needing document access. The description only states what it does, not when to choose 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 implies a mutation ('Move') but doesn't disclose permissions required, whether the move is reversible, effects on document links or metadata, error conditions, or response format. This leaves significant gaps for a tool that modifies document structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, parameter usage, error handling, and output, leaving the agent with significant uncertainty about how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds little. It mentions 'collection' and 'parent document' as destinations, hinting at parameters 'collectionId' and 'parentDocumentId', but doesn't explain their relationship (e.g., mutually exclusive?), formats, or that 'documentId' is required. With 3 parameters and no schema descriptions, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and resource ('document'), specifying the destination ('to another collection or under a parent document'). It distinguishes from siblings like 'batch_move_documents' by implying single-document operation, though not explicitly. However, it lacks explicit differentiation from tools like 'update_document' which might also handle document relocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., document must exist), exclusions (e.g., cannot move to a non-existent collection), or comparisons with sibling tools like 'batch_move_documents' for multiple documents or 'update_document' for other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Supports pagination,' which adds some context about handling large datasets, but fails to cover critical aspects like read-only vs. destructive behavior, authentication needs, rate limits, or error handling. For a search tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences: 'Search documents by keyword. Supports pagination.' Every word earns its place, and it's front-loaded with the core purpose. There's no wasted verbiage, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on parameter meanings, behavioral traits, output format, and differentiation from siblings. For a search function in a document-heavy system, this leaves significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description only mentions 'keyword' (implied for 'query') and 'pagination' (implied for 'limit' and 'offset'), but doesn't explain 'collectionId' or provide details on parameter usage, formats, or constraints. It adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search documents by keyword.' It specifies the verb ('search') and resource ('documents'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'find_related' or 'list_document_comments', which might also involve document retrieval, 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 mentions 'Supports pagination,' which hints at usage for large result sets, but doesn't explicitly compare to siblings like 'list_recent_documents' or 'find_related.' Without clear when/when-not instructions or named alternatives, the score is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'AI-powered' which hints at non-deterministic output, but doesn't address critical aspects like rate limits, authentication needs, output format, or whether this is a read-only operation. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of AI-powered summarization, no annotations, no output schema, and 0% parameter documentation, the description is inadequate. It doesn't explain what kind of summary to expect, length considerations, quality limitations, or how the AI aspect affects results. The minimal description doesn't provide enough context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (documentId and language), the description provides no information about parameter meanings or usage. It doesn't explain what documentId refers to, what format it should be in, or what the optional language parameter controls. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate an AI-powered summary') and the resource ('of a document'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get_document' or 'smart_status' that might also provide document insights, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (like 'get_document' for full content or 'smart_status' for analysis), there's no indication of when summarization is preferred over other document operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions using RAG (Retrieval-Augmented Generation), which implies AI-generated answers based on retrieved content, but doesn't detail aspects like response format, potential inaccuracies, rate limits, authentication needs, or whether it modifies data. For a tool with no annotations, this leaves significant gaps in understanding its operation and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Ask a question and get an answer based on wiki content using RAG.' It's front-loaded with the core action and method, with no wasted words or redundancy, 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 tool's complexity (involving RAG and wiki content), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what the output looks like (e.g., text answer, citations), error conditions, or how it interacts with the wiki system. For a query tool with AI components, more context on reliability and scope is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (question) with 0% description coverage, meaning the schema provides no semantic details. The description adds value by implying the parameter is a question to be answered using wiki content and RAG, but it doesn't specify format, length limits, or examples. Since schema coverage is low, the description partially compensates but not fully, aligning with the baseline for minimal param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask a question and get an answer based on wiki content using RAG.' It specifies the verb ('ask'), resource ('wiki content'), and method ('RAG'), making it distinct from siblings like search_documents or get_document. However, it doesn't explicitly differentiate from find_related or summarize_document, which might have overlapping query functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like search_documents, get_document, and find_related that might handle queries or content retrieval, there's no indication of when ask_wiki is preferred, such as for open-ended questions versus specific document lookups, or any prerequisites like needing existing wiki content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions needed, whether archiving is reversible (though 'unarchive_document' exists), rate limits, or what happens to archived documents (e.g., moved to a list accessible via 'list_archived_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 with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and outcomes, failing to compensate for the missing structured data, which could lead to incorrect usage by 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 0%, so the description must compensate but adds no parameter details. It implies 'documentIds' are needed but doesn't explain format, sourcing, or constraints. With 1 parameter and no schema descriptions, baseline is 3 as the description doesn't add meaningful semantics beyond the obvious.
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 ('archive') and resource ('multiple documents'), making the purpose understandable. It distinguishes from 'archive_document' by specifying batch operation, though it doesn't explicitly contrast with 'batch_delete_documents' or 'batch_move_documents' which are similar batch operations on documents.
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 'archive_document' (for single documents) or 'batch_delete_documents' (for deletion instead of archiving). The description implies batch usage 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. It mentions deletion but fails to disclose critical behavioral traits: whether deletion is reversible (e.g., via 'permanent' parameter), permission requirements, rate limits, or error handling for invalid IDs. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly conveys the core action, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, no output schema, and low schema coverage, the description is incomplete. It omits essential context like return values, error conditions, and safety warnings, which are crucial for a batch deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'documentIds' as input but does not explain the 'permanent' parameter or provide any semantic details beyond the schema. Since it adds minimal value, the score reflects a baseline with some compensation for hinting at parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete multiple documents at once') and specifies the resource ('documents'), making the purpose unambiguous. However, it does not differentiate from the sibling tool 'delete_document', which handles single deletions, leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_document' for single deletions or 'batch_archive_documents' for archiving. It lacks context on prerequisites, such as needing document IDs, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral aspects like required permissions, whether creation is idempotent, what happens on duplicate names, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loading the essential action and resource with zero wasted words. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover what a collection represents in this system, how it relates to other resources, or what to expect upon creation. More context is needed given the complexity implied by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information beyond the tool name implying a 'collection' resource. It doesn't explain what 'name', 'description', or 'color' parameters mean or their significance. Baseline is 3 since the schema fully defines parameters, but the description adds minimal 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 ('Create') and resource ('a new collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'batch_create_documents' or specify what distinguishes a collection from other resources in this system.
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 'batch_create_documents' or 'update_collection', nor does it mention prerequisites or typical use cases. It's a bare statement of function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a diagram but doesn't describe what happens after generation (e.g., output format, whether it's saved or displayed, error handling, or any limitations like diagram complexity). This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Generate a Mermaid diagram from a text description.' It is front-loaded with the core action and resource, with no wasted words. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain the output (e.g., diagram format, success/failure responses) or behavioral aspects like error conditions. For a generative tool with one parameter, more context is needed to fully understand its operation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one required parameter 'description' of type string. The description adds meaning by specifying it's a 'text description' for generating a Mermaid diagram, which clarifies the parameter's purpose beyond the schema. However, it doesn't provide details on format, examples, or constraints, so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a Mermaid diagram from a text description.' It specifies the verb ('Generate') and resource ('Mermaid diagram'), and the input schema confirms the single parameter is a text description. However, it doesn't explicitly differentiate from sibling tools, which are all document/collection management tools unrelated to diagram generation, so the distinction is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions. Given the sibling tools are unrelated to diagram generation, there's no explicit comparison or usage context provided, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose details like permissions needed, rate limits, error conditions, or what 'hierarchy' entails (e.g., tree structure, metadata). For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal parameter guidance, the description is incomplete. It doesn't explain what 'document hierarchy' includes (e.g., nesting levels, metadata), return format, or error handling. For a tool that likely returns structured data, this leaves too much undefined for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't add any parameter-specific information. It mentions 'collectionId' implicitly via 'collection' but doesn't explain its format (UUID) or sourcing. Baseline is 3 due to the single parameter, but the description fails to compensate for the lack of schema 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 action ('Get') and resource ('document hierarchy within a collection'), making the purpose understandable. It distinguishes from siblings like 'get_document' (single document) and 'list_collections' (collections themselves), though it doesn't explicitly contrast them. The description is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as whether it works on archived collections or requires specific permissions. It leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it 'gets details' but doesn't specify what details are returned, error conditions, permissions required, or rate limits. This is inadequate for a 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 with no wasted words. It's front-loaded with the core action, 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, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return values, error handling, or behavioral traits, which are critical for a tool that retrieves data. This leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description mentions 'a specific comment', implying the 'commentId' parameter identifies the comment. However, it doesn't add details like format hints (UUID) or where to obtain the ID, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific comment'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_document_comments' which might retrieve multiple comments, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a comment ID), exclusions, or how it differs from related tools like 'list_document_comments', leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'full document content' but doesn't specify format (e.g., plain text, HTML, JSON), size limits, error handling (e.g., for invalid IDs), authentication requirements, or rate limits. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get full document content') and specifies the key constraint ('by document ID'). There is no wasted verbiage, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on return values (e.g., content format, structure), error conditions, and behavioral aspects like permissions or limitations. While minimalism might suffice for basic use, the absence of annotations and output schema means the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic context beyond the input schema. It mentions 'document ID' as the parameter, aligning with the schema's 'documentId', but provides no details on ID format, sourcing (e.g., from 'get_document_id_from_title'), or validation rules. With 0% schema description coverage, the description doesn't compensate for the lack of schema documentation, but it at least clarifies the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('full document content'), specifying retrieval by document ID. It distinguishes from siblings like 'get_document_backlinks' or 'get_document_id_from_title' by focusing on content retrieval rather than metadata or IDs. However, it doesn't explicitly differentiate from 'export_document' or 'summarize_document', which might also involve document content access.
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 valid document ID), exclusions (e.g., not for archived documents), or comparisons to siblings like 'export_document' (for file output) or 'summarize_document' (for condensed content). Usage is implied only by the tool name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action 'Find' but doesn't describe what 'Find' entails—e.g., whether it returns a list, the format of backlinks, error conditions, or performance characteristics. For a tool with no annotations, this is a significant gap, as it omits key behavioral details needed for reliable use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's function without fluff. It's appropriately sized for a simple tool and front-loaded with the core action. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete for a tool that likely returns structured data (e.g., a list of backlinks). It doesn't explain return values, error handling, or behavioral nuances. For a read operation with potential complexity, this leaves critical gaps, scoring a 2 as it provides only basic purpose without supporting context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies a 'documentId' parameter by referring to 'this document', but it doesn't add meaning beyond the input schema. With 0% schema description coverage and 1 parameter, the baseline is 3 because the schema alone defines the parameter. The description doesn't compensate with details like ID format or validation, so it meets the minimum viable level without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'other documents linking to this document', making the purpose immediately understandable. It distinguishes from siblings like 'get_document' (which retrieves content) or 'find_related' (which might use different logic), though it doesn't explicitly name alternatives. The purpose is specific but lacks explicit sibling differentiation, warranting a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 valid documentId), exclusions (e.g., not for archived documents), or comparisons to siblings like 'find_related' or 'get_document'. Without any usage context, it's minimally functional but leaves the agent to guess, scoring a 2.
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 'Get list of archived documents,' implying a read-only operation, but does not specify any behavioral traits such as pagination, sorting, authentication requirements, rate limits, or what happens if no archived documents exist. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Get list of archived documents,' which is front-loaded and wastes no words. Every part of the sentence directly contributes to the tool's purpose, making it efficient and easy to parse, though it may be overly brief for completeness.
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 moderate complexity (a list operation with one parameter), no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It lacks details on behavioral aspects, usage context, and what the output entails (e.g., format, structure). For a tool that interacts with archived documents, more context is needed to ensure proper use, making it inadequate overall.
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 one parameter ('limit') with 0% description coverage, meaning the schema provides no semantic context. The description does not mention any parameters, so it adds no explicit parameter semantics. However, since there is only one parameter and the tool's purpose is straightforward (listing archived documents), the lack of parameter details is less critical, warranting a baseline score of 4 for minimal parameter complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of archived documents' clearly states the verb ('Get') and resource ('archived documents'), making the basic purpose understandable. However, it lacks specificity about what 'Get' entails (e.g., retrieval, listing, filtering) and does not distinguish this tool from potential siblings like 'list_recent_documents' or 'list_trash', which are similar list operations. This results in a vague but not misleading purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 does not mention any context, prerequisites, or exclusions, such as how it differs from 'list_recent_documents' or 'list_trash' in terms of scope or filtering. Without such information, users must infer usage from the tool name alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get list' implies a read-only operation, the description doesn't address important behavioral aspects like what 'recently modified' means (time window criteria), whether results are paginated, what format the list returns, or any rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list 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 tool with no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't explain what constitutes 'recently modified', what data is returned, or how results are ordered. Given the complexity of document management systems and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the schema has one parameter (limit) with 0% description coverage. Since the description adds no parameter information beyond what's in the schema, and with only one parameter that's reasonably self-explanatory from its name and constraints, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of recently modified documents' clearly states the verb ('Get list') and resource ('recently modified documents'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'list_archived_documents', 'list_collections', or 'search_documents', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_documents', 'list_archived_documents', and 'list_collections' available, there's no indication of when 'recently modified' filtering is appropriate versus other listing or search approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get list' implies a read-only operation, it doesn't specify whether this requires special permissions, what format the results come in, whether there's pagination, or if the operation has any side effects. The description is too minimal for a tool that presumably accesses sensitive deleted 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 extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and uses straightforward language. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that accesses trash/deleted documents with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned about each document, whether the operation is safe/reversible, or how results are structured. The context demands more disclosure for a tool dealing with potentially sensitive deleted content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has one parameter (limit) with 0% description coverage. Since schema_description_coverage is 0%, the description should compensate but doesn't. The baseline would be lower, but the tool has only one optional parameter, making the gap less severe than for multi-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of documents in trash', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_archived_documents' or 'list_recent_documents', which would require mentioning the specific trash context more explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose list_trash over other listing tools like list_archived_documents or list_recent_documents, nor does it specify prerequisites or constraints for accessing trash content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Restore' implies a mutation operation, it doesn't specify permissions required, whether the action is reversible, what happens if the document isn't in trash, or any rate limits. This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information immediately.
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, no output schema, and minimal parameter documentation, the description is inadequate. It doesn't address what happens after restoration, error conditions, or how this differs from similar operations like unarchiving, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a document' which implies the 'documentId' parameter, but with 0% schema description coverage, it doesn't explain what format the ID should be, where to find it, or provide any examples. Since there's only one parameter, the baseline is 4, but the lack of any parameter guidance beyond basic implication reduces this to 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 action ('Restore') and target resource ('a document from trash'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'unarchive_document' or 'move_document' which might have overlapping functionality, 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 like 'unarchive_document' or 'move_document', nor does it mention prerequisites such as needing a document to be in trash first. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions AI-suggestion but doesn't disclose traits like whether it's read-only (implied by 'Get'), latency, rate limits, authentication needs, or output format. This is inadequate for a tool with potential complexity in AI processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundancy or fluff, 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 no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on behavioral traits, parameter meaning, and return values (e.g., tag format, confidence scores), which are critical for an AI-suggestion tool. The conciseness comes at the cost of necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter details beyond implying 'documentId' is needed. It doesn't explain what a documentId is, format requirements, or how content is analyzed. With 1 parameter and low coverage, this minimally compensates, meeting the baseline for simple tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get AI-suggested tags') and resource ('for a document'), specifying it's based on content analysis. It distinguishes from siblings like 'get_document' or 'summarize_document' by focusing on tag generation, though it doesn't explicitly contrast with similar tools like 'find_related' or 'smart_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., document must exist), use cases (e.g., content categorization), or exclusions (e.g., not for documents without text). It leaves the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Restore' implies a mutation operation, but the description doesn't specify permissions required, whether the action is reversible, side effects (e.g., if it affects document visibility or metadata), or error conditions. This leaves significant gaps for a tool that modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action ('Restore'), making it easy to scan. Every part of the sentence earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'restore' entails (e.g., moves from archived to active state), return values, error handling, or dependencies. For a tool that changes document state, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't mention any parameters. Since there's only one parameter and the schema defines it as a required string 'documentId', the baseline is 4 for zero parameters, but the description adds no semantic context (e.g., what format the ID should be or where to find it). This results in a minimal viable score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Restore an archived document' clearly states the verb ('restore') and resource ('archived document'), making the purpose immediately understandable. It distinguishes from sibling tools like 'archive_document' (opposite action) and 'restore_document' (likely for trash restoration), though it doesn't explicitly mention these distinctions. The description avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the document must be archived first), exclusions (e.g., not for trashed documents), or refer to related tools like 'list_archived_documents' for finding targets or 'restore_document' for a different context. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the 'append mode' feature but doesn't describe what happens by default (replace vs. append), whether updates are reversible, what permissions are required, or what the response looks like. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences that get straight to the point. The first sentence states the core purpose, and the second adds the key feature about append mode. There's no wasted verbiage 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 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter interactions, error conditions, return values, or behavioral nuances. The agent would struggle to use this tool correctly without significant trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description doesn't explain any of the 4 parameters beyond implying 'append' relates to 'append mode'. It doesn't clarify what 'documentId' represents, whether 'title' and 'text' are optional or required, or how they interact. The description adds minimal value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('an existing document'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_document' by specifying it works on existing documents, though it doesn't explicitly differentiate from 'batch_update_documents' or other update-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance - it mentions 'append mode' but doesn't specify when to use append vs. replace, nor does it provide context about when to choose this tool over alternatives like 'batch_update_documents' or 'move_document'. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether this is a read-only operation, what permissions might be required, whether it affects system state, what format the statistics are returned in, or any rate limits. For a status-checking tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that efficiently communicates the tool's dual purpose. Every word earns its place, with no redundant information or unnecessary elaboration. It's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and the description provides minimal behavioral context, this is incomplete. For a status-checking tool that presumably returns system information, the description should at minimum indicate what 'index statistics' includes or the format of the response. The current description leaves too many unknowns for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it appropriately focuses on the tool's purpose rather than parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check' and 'get') and resources ('smart features' and 'index statistics'). It distinguishes itself from siblings by focusing on system status rather than document/content operations. However, it doesn't explicitly differentiate from potential similar status-checking tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools are all document/content management operations, this tool stands alone for system status checking, but the description doesn't explicitly state this distinction or provide any context about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation but doesn't disclose behavioral traits like pagination, sorting, rate limits, authentication requirements, or what 'all collections' entails (e.g., includes archived). For a list tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is minimally adequate but lacks completeness. It doesn't explain return values (e.g., format, fields) or behavioral context (e.g., pagination). For a simple list tool, it meets basic needs but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here. Baseline is 4 for zero parameters, as it avoids unnecessary complexity.
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 list') and resource ('all collections'), making the purpose immediately understandable. It distinguishes from siblings like 'get_collection_structure' (detailed view) and 'export_all_collections' (exporting). However, it doesn't specify verb tense or scope nuances like whether it includes archived/trashed collections.
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 siblings like 'search_documents' (filtered search) or 'list_recent_documents' (time-based), nor does it specify prerequisites or exclusions (e.g., permissions needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action 'sync' but doesn't describe what this entails operationally—whether it's a full or incremental sync, how long it takes, if it requires specific permissions, or what happens on failure. The mention of 'vector store' hints at AI infrastructure but lacks practical implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the tool's purpose and usage timing. Every word serves a clear function, and it's front-loaded with the core action. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (syncing documents to a vector store for AI search), no annotations, no output schema, and poor parameter documentation, the description is insufficient. It doesn't explain what 'sync' entails operationally, what the vector store is, how to verify success, or error handling. The guidance to run before 'ask_wiki' is helpful but doesn't cover broader contextual needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'collectionId' parameter. It doesn't explain what a collection is, how to obtain its ID, or whether syncing applies to all collections if omitted. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'sync' and resource 'documents to vector store', specifying the purpose for 'AI-powered search'. It distinguishes from sibling 'ask_wiki' by indicating this is a prerequisite step, though it doesn't explicitly differentiate from other document/collection management tools like 'batch_create_documents' or 'update_collection'.
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: 'before using ask_wiki'. This gives explicit timing guidance, but it doesn't mention when NOT to use it or alternatives for similar functionality, such as whether it's needed after document updates or if other tools handle incremental syncing.
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 helpfully adds that 'All documents in the collection will also be deleted,' which is crucial context beyond the basic 'delete' action. However, it doesn't address other important behaviors: whether deletion is permanent or reversible, what permissions are required, if there are confirmation prompts, or what the response looks like (success/failure indicators).
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 short sentences that communicate the core action and a critical side effect. Every word earns its place: 'Delete a collection' establishes the purpose, and 'All documents in the collection will also be deleted' provides essential behavioral context. There's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations and no output schema, the description is incomplete. It covers the basic action and cascading deletion effect but misses important context: whether the operation is reversible (checking sibling tools shows 'restore_document' but no collection restoration), what permissions are needed, error conditions, or response format. For a high-stakes delete tool, more behavioral transparency would be expected.
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 1 parameter with 0% description coverage, so the description must compensate. While it doesn't explicitly mention the 'collectionId' parameter, it implies its necessity by stating 'Delete a collection'—the agent can infer that identifying the collection is required. For a single-parameter tool where the parameter's purpose is obvious from context, this is adequate. However, it doesn't specify the UUID format or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a collection'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'delete_document' by specifying it operates on collections rather than individual documents. However, it doesn't explicitly differentiate from other collection-related tools like 'archive_document' or 'list_collections' 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing collection ownership), when not to use it (e.g., for temporary removal), or direct alternatives among siblings (like 'archive_document' for documents or whether collections can be archived). The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the trash/permanent deletion behavior, which is valuable. However, it lacks critical information such as required permissions, whether deletion is reversible (especially for permanent=true), what happens to linked resources, or error responses. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that front-load the core action and immediately follow with parameter semantics. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, and no output schema, the description is incomplete. It covers the basic operation and parameter effect but misses safety warnings, permission requirements, and result format. For a delete tool with 2 parameters, this provides a minimum viable explanation but leaves gaps an agent would need to infer.
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 description adds meaningful context for the 'permanent' parameter by explaining that false moves to trash while true permanently deletes. This clarifies behavior beyond the schema's boolean type and default value. Since schema description coverage is 0%, the description compensates well for one of the two parameters, though 'documentId' remains minimally described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a document'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'archive_document', 'move_document', and 'restore_document' by specifying deletion behavior. However, it doesn't explicitly contrast with 'batch_delete_documents' for single vs. batch operations.
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 when to use this tool through the 'permanent' parameter explanation (trash vs. permanent deletion), which provides some contextual guidance. However, it doesn't explicitly state when to choose this over alternatives like 'archive_document' or 'batch_delete_documents', nor does it mention prerequisites or error conditions.
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:

[![outline-smart-mcp MCP server](https://glama.ai/mcp/servers/huiseo/outline-smart-mcp/badges/card.svg)](https://glama.ai/mcp/servers/huiseo/outline-smart-mcp)

Score Badge

Copy to your README.md:

[![outline-smart-mcp MCP server](https://glama.ai/mcp/servers/huiseo/outline-smart-mcp/badges/score.svg)](https://glama.ai/mcp/servers/huiseo/outline-smart-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/huiseo/outline-smart-mcp'

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