Tiptap Collaboration MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific document operations, health/statistics monitoring, or format conversion. There is no overlap between tools like create_document, duplicate_document, encrypt_document, and export_markdown, making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., create_document, get_document_statistics, import_markdown). The naming is uniform throughout with no deviations in style or convention.
Tool Count5/5
With 14 tools, the server provides comprehensive coverage for document collaboration, including CRUD operations, bulk actions, health checks, statistics, and format conversions. Each tool serves a clear purpose without bloat.
Completeness5/5
The tool set offers complete lifecycle coverage for collaborative documents, including creation, retrieval, updating, duplication, encryption, deletion, listing, searching, and bulk import. It also includes health monitoring, statistics, and format conversion utilities, leaving no obvious gaps.
Average 3/5 across 14 of 14 tools scored.
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?
No annotations are provided, so the description carries full burden. It mentions 'List all' but doesn't disclose behavioral traits such as pagination, sorting, rate limits, or what 'all' entails (e.g., all accessible vs. all in system). This leaves key operational details unspecified for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that states the purpose without unnecessary words. However, the misspelling 'collaboratiion' slightly detracts from clarity, but it remains efficiently front-loaded.
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 multiple sibling tools, the description is incomplete. It lacks context on return format, scope limitations, or how it differs from similar tools like 'search_documents'. For a list operation in a collaborative environment, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so 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 redundancy.
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 verb 'List' and resource 'collaboration documents', which clarifies the basic action. However, it lacks specificity about scope or format, and the misspelling 'collaboratiion' introduces ambiguity. It doesn't distinguish from sibling tools like 'search_documents' or 'get_document'.
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. With siblings like 'search_documents' (for filtered queries) and 'get_document' (for single documents), the description offers no context for choosing this tool, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Import' which implies a write operation, but doesn't clarify permissions required, whether it overwrites existing documents, error handling for invalid data, or the response format. This leaves significant gaps for a mutation tool with potential 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?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a tool with one parameter and good schema coverage, making it easy to parse while conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after import (success/failure responses), doesn't mention constraints like size limits or rate limits, and provides minimal guidance on usage context. Given the complexity of bulk operations and lack of structured safety information, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single 'documents' parameter and its nested structure. The description adds minimal value by mentioning 'predefined JSON structure' which aligns with the schema, but doesn't provide additional context about format expectations or usage examples beyond what's in the schema descriptions.
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 ('Import multiple documents in bulk') and the method ('using a predefined JSON structure'), which distinguishes it from single-document operations like create_document. However, it doesn't explicitly differentiate from other import-related tools like import_markdown, leaving some ambiguity about when to choose this specific bulk import method.
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 for single documents or import_markdown for different formats. It mentions 'bulk' but doesn't specify thresholds or scenarios where batch processing is preferred, nor does it mention prerequisites or constraints for bulk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new collaborative document' implies a write operation but doesn't specify permissions needed, whether the document becomes immediately editable, what happens if a document with the same name exists, or any rate limits. This leaves significant behavioral questions unanswered for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple creation tool 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 document creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, what the collaborative aspects entail, how to access the created document, or address any potential constraints. Given the complexity of collaborative document 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 provides no parameter information, but the input schema has 100% description coverage with clear documentation for both 'content' and 'name' parameters. Since schema coverage is high, the baseline score of 3 is appropriate - the schema does the heavy lifting for 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 action ('Create') and resource ('collaborative document'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'duplicate_document' or 'import_markdown', which also create documents through different mechanisms.
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 'batch_import_documents', 'duplicate_document', 'import_markdown', and 'update_document', there's no indication of when this specific creation method is appropriate versus those other document creation or modification 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, the description carries full burden but only states the action without behavioral details. It doesn't disclose if deletion is permanent, requires specific permissions, has confirmation steps, or affects related data (e.g., collaborators), which is critical 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 zero wasted words, clearly front-loading the core action. It's appropriately sized for a simple tool, 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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context like irreversible effects, error conditions, or response format, leaving significant gaps in understanding the tool's behavior and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'id' documented as 'ID of the document to delete'. The description adds no additional meaning beyond this, such as format examples or sourcing tips, so it meets the baseline for high schema coverage without compensation.
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 ('Delete') and resource ('a collaborative document'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'batch_import_documents' or 'update_document' beyond the obvious action difference, missing explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 document ID), exclusions (e.g., cannot delete if in use), or related tools like 'list_documents' for finding IDs, leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether duplication requires specific permissions, if it preserves metadata/collaboration settings, potential rate limits, or what the response includes (e.g., success confirmation or new document details). This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 and 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like behavioral details (permissions, effects), output expectations, and differentiation from sibling tools, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the schema provides. Since schema description coverage is 100% (both parameters clearly documented), the baseline score of 3 applies. The description doesn't explain parameter relationships or usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('duplicate') and resource ('collaborative document'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_document' or 'import_markdown' that also create 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. It doesn't mention prerequisites (e.g., needing an existing document), exclusions, or comparisons to siblings like 'create_document' (for new documents) or 'import_markdown' (for importing 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?
No annotations are provided, so the description carries full burden. It states the encryption method but lacks critical behavioral details: whether encryption is reversible, if it modifies the original document or creates a new version, permission requirements, error handling, or output format. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action and resource, and the encryption method is directly relevant. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (encryption operation with 2 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns (e.g., encrypted content, success status), side effects, or error conditions. For a mutation tool without annotations or output schema, more context is needed 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?
Schema description coverage is 100%, with clear descriptions for both parameters ('content' as 'Document content in Tiptap JSON format to encrypt' and 'id' as 'ID of the document to encrypt'). The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Encrypt') and resource ('collaborative document'), and specifies the encryption method ('Base64 encryption'). It distinguishes from siblings like 'create_document' or 'update_document' by focusing on encryption, though it doesn't explicitly contrast with tools like 'export_markdown' that might handle document output differently.
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., not for already encrypted documents), or compare to siblings like 'export_markdown' for secure output. Usage is implied only by the tool name and action.
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 what the tool does without disclosing behavioral traits. It doesn't mention permissions, rate limits, error handling, or what 'information' includes, leaving significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the purpose. It's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'information' is returned, potential errors, or other contextual details needed for effective use, especially among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'id' parameter. The description adds no additional meaning beyond implying retrieval by ID, meeting the baseline for high schema coverage without compensating with extra details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'collaborative document', making the purpose understandable. It distinguishes from siblings like 'list_documents' or 'search_documents' by focusing on retrieving a specific document, though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_documents' or 'search_documents'. The description implies usage for retrieving a specific document by ID, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'real-time statistics' which implies freshness and possibly dynamic data, but doesn't cover critical aspects like whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output format looks like (e.g., JSON structure). This leaves significant gaps for a tool that likely involves sensitive connection data.
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 real-time statistics for a specific document') and adds specific details ('including current connections and connected IPs') without any wasted words. It's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving real-time connection data (which may involve permissions or sensitive info), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'statistics' entail beyond connections/IPs, how data is returned, or any behavioral constraints, leaving the agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'id' clearly documented as 'ID of the document to get statistics for'. The description adds no additional semantic context beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating 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 'Get' and the resource 'real-time statistics for a specific document', specifying what statistics are included (current connections and connected IPs). It distinguishes from siblings like 'get_document' (which likely retrieves content) and 'get_server_statistics' (which is broader), but doesn't explicitly name these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_document' or 'get_server_statistics', nor does it mention prerequisites such as needing an existing document ID. It only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'update' implies mutation, it doesn't specify whether this requires specific permissions, whether changes are reversible, potential rate limits, or what happens to existing content not mentioned. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a basic update operation and front-loads the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address important contextual aspects like what permissions are needed, whether the operation is idempotent, what the response contains, or how it differs from other document modification tools in the sibling list. The 100% schema coverage helps with parameters, but the overall context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the parameters are well-documented in the structured data. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it mentions 'new content' which aligns with the 'content' parameter but provides no additional context about format requirements or the implications of different 'mode' settings.
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 ('collaborative document') with the action ('with new content'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential alternatives like 'duplicate_document' or 'encrypt_document' that might also modify documents in different ways.
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', 'duplicate_document', or 'encrypt_document'. There's no mention of prerequisites (e.g., needing an existing document ID) or when other tools might be more appropriate for different document modification 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 the full burden of behavioral disclosure. It mentions the use of an external API ('Tiptap Conversion API') but does not describe error handling, rate limits, authentication needs (implied by appId), or what happens if conversion fails. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality without unnecessary details. Every word earns its place by specifying the action, input, output, and method, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output expectations. With no output schema, it should ideally hint at the return format, but the schema coverage helps offset some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (appId, content, format) with descriptions and enums. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints on the content object. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting Tiptap JSON content to Markdown format using a specific API. It specifies the verb ('convert'), resource ('Tiptap JSON content'), and target format ('Markdown'), but does not explicitly differentiate from sibling tools like 'import_markdown' (which likely does the reverse operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 does not mention prerequisites (e.g., needing a Tiptap App ID), exclusions, or compare it to sibling tools like 'import_markdown' for reverse conversions or other document-related tools in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves health status but doesn't explain what that entails (e.g., uptime metrics, error rates, service availability), whether it requires authentication, or how frequently it can be called. This leaves significant gaps in understanding the tool's behavior 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 a single, clear sentence that directly states the tool's purpose without any extraneous information. It's front-loaded and efficiently communicates the essential function, making it easy for an agent to parse and understand 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?
Given the complexity of a health-check tool (which often involves metrics, status codes, or detailed outputs), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to provide enough information for an agent to fully understand what the tool returns or how to interpret the results, leaving significant gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion about inputs.
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 a specific verb ('Get') and resource ('health status of the Tiptap collaboration service'), making it immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'get_server_statistics' or 'get_document_statistics', which might also provide health-related information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this health check is appropriate (e.g., for monitoring, troubleshooting) or how it differs from sibling tools like 'get_server_statistics', leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics but does not specify whether this is a read-only operation, requires permissions, has rate limits, or details the response format. 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 that front-loads the key action ('Get server-wide statistics') and provides relevant examples without unnecessary details. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the statistics include beyond vague examples, how they are formatted, or any behavioral traits like safety or performance. For a tool with no structured data, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied as it meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get') and resources ('server-wide statistics'), including examples of what statistics are retrieved ('total documents, connections, and usage metrics'). However, it does not explicitly distinguish this tool from its sibling 'get_document_statistics', which might cause confusion about scope differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_document_statistics' for document-specific stats or 'get_collaboration_health' for related metrics, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the API usage but doesn't describe error conditions, rate limits, authentication requirements (beyond the appId parameter), whether the conversion is idempotent, or what happens with malformed Markdown. For a tool that performs format conversion with external API calls, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a straightforward conversion tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with 3 parameters and no output schema, the description is minimally complete. It identifies the transformation but lacks important context about the Tiptap JSON format, error handling, or what the converted output looks like. Without annotations and with no output schema, users must infer behavioral characteristics from the tool name and parameters alone.
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 'Markdown content' which maps to the 'content' parameter, but adds no additional semantic context beyond what's already in the schema descriptions. With 100% schema description coverage, the baseline is 3 - the description doesn't compensate but doesn't need to since the schema fully documents all 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 tool's purpose: converting Markdown content to Tiptap JSON format using a specific API. It includes a specific verb ('Convert') and resource ('Markdown content'), but doesn't explicitly differentiate from sibling tools like 'export_markdown' or 'create_document' which might handle similar content transformations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'export_markdown' (which presumably does the reverse conversion) or 'create_document' (which might accept Tiptap JSON directly). There's no mention of prerequisites, use cases, or comparison 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions a prerequisite ('requires Tiptap Semantic Search to be enabled'), which adds useful context about dependencies. However, it fails to describe key behaviors such as whether this is a read-only operation, how results are returned (e.g., format, pagination), or any rate limits, leaving significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Search documents using semantic search') and includes a necessary prerequisite without any wasted words. Every part of the sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (semantic search with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and a prerequisite but lacks details on behavior, return values, or error handling. This is sufficient for basic understanding but leaves gaps that could hinder 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('query' and 'limit') in the input schema. The description does not add any additional meaning beyond what the schema provides, such as explaining the semantics of 'semantic search' or query formatting. This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search documents') and the method ('using semantic search'), which distinguishes it from siblings like 'list_documents' or 'get_document'. However, it lacks specificity about what resources are searched (e.g., all documents vs. a subset), making it slightly less precise than 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Search documents using semantic search') and includes a prerequisite ('requires Tiptap Semantic Search to be enabled'), which provides clear context. However, it does not specify when not to use it or name alternatives (e.g., 'list_documents' for non-semantic listing), preventing a perfect score.
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:

[![tiptap-collaboration-mcp MCP server](https://glama.ai/mcp/servers/trainual/tiptap-collaboration-mcp/badges/card.svg)](https://glama.ai/mcp/servers/trainual/tiptap-collaboration-mcp)

Score Badge

Copy to your README.md:

[![tiptap-collaboration-mcp MCP server](https://glama.ai/mcp/servers/trainual/tiptap-collaboration-mcp/badges/score.svg)](https://glama.ai/mcp/servers/trainual/tiptap-collaboration-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/trainual/tiptap-collaboration-mcp'

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