docuwriter
Server Details
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 15 of 15 tools scored.
Each tool has a clearly distinct purpose: space management vs. various code generation outputs (comments, docs, optimization, tests, language conversion, swagger, UML). No overlap between categories.
All tools follow a consistent verb_noun pattern with snake_case: create-space, list-spaces, generate-code-comments, get-user-info, etc. Conventions are uniform.
15 tools is well-scoped for a documentation and code generation server, covering space management, search, and seven distinct code generation capabilities without being excessive.
The tool set covers space CRUD, search, and varied code generation. Missing direct document-level operations (e.g., create or view document content) but generation tools can create documents in spaces, so only minor gaps.
Available Tools
15 toolscreate-spaceCreate Space ToolAInspect
Use this when the user wants to create a new documentation Space or knowledge base container. State-changing: creates the Space directly after the MCP client authorizes the call. Requires a Space name and may include description, public visibility, and slug.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the new documentation Space the user wants to create. | |
| slug | No | Optional public slug. | |
| is_public | No | Whether the Space should be public. Defaults to false. | |
| description | No | Optional Space description. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds 'State-changing: creates the Space directly after authorization', which clarifies the mutation behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (1 required) and no output schema. The description covers purpose and parameters but omits return values. However, for a creation tool, this is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description merely summarizes the schema ('requires a Space name and may include...') without adding extra meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'create a new documentation Space or knowledge base container', which is a specific verb+resource. It clearly distinguishes from sibling tools like delete-space, update-space, and list-spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this when the user wants to create...' and mentions required and optional parameters. It implies when to use but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete-spaceDelete Space ToolADestructiveInspect
Use this when the user explicitly wants to delete a whole documentation Space. Destructive state-changing action: removes the manageable Space directly after the MCP client authorizes the call. Requires numeric space_id from list-spaces and should not be used for deleting individual pages.
| Name | Required | Description | Default |
|---|---|---|---|
| space_id | Yes | Numeric Space ID to delete. Use list-spaces first and confirm the user means the whole Space. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: 'removes the manageable Space directly after the MCP client authorizes the call', clarifying the destructive action flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with good annotations and schema, description fully covers what an agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters; description adds guidance to 'use list-spaces first and confirm the user means the whole Space', enhancing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a whole documentation Space, distinguishing it from deleting individual pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (explicit user request), prerequisites (numeric space_id from list-spaces), and excludes misuse (not for pages).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-code-commentsGenerate Code Comments ToolAInspect
Use this when the user supplies source code and asks to add inline comments, docblocks, docstrings, or code annotations. State-changing generation action: consumes AI credits, creates a generation, and returns commented code after authorization. Use browser guidance for file uploads.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional custom name used to identify the commented code in generation history | |
| filename | Yes | The full file path of the file being commented (e.g., src/utils/helper.ts) | |
| source_code | Yes | The source code to add comments to |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by noting state-changing behavior (consumes AI credits, creates a generation) and authorization requirement. Annotations only indicate non-read-only and non-destructive, leaving out these specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose. No superfluous text; each sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is straightforward; parameters and behavior are adequately described. No output schema, but returning commented code is implied. Could detail response format, but not critical given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no new meaning beyond what the input schema already provides for each parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates comments/inline annotations for source code. Differentiates from siblings like generate-code-documentation by specifying 'inline comments, docblocks, docstrings, or code annotations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies when to use (user supplies source code and asks for comments). Provides context for file uploads via browser guidance. However, does not explicitly exclude scenarios or mention alternatives like generate-code-documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-code-documentationGenerate Code Documentation ToolAInspect
Use this when the user supplies source code and asks to generate markdown documentation, explain code, or document one or more files. State-changing generation action: consumes AI credits, creates a generation, and returns documentation after authorization. Use browser guidance for local upload or repository/full-tree flows.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional custom name used to identify the documentation in generation history | |
| files | Yes | Array of files to document. Each file must have filename and source_code properties | |
| output_language | No | Output language for documentation | |
| documentation_type | No | Free-text style hint for this single document, e.g. 'API Reference', 'Tutorial', 'General Documentation' (the default). This is NOT a Space's full-tree documentation audience — any string is accepted and passed to the prompt as-is. | |
| additional_instructions | No | Additional instructions for documentation generation |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it discloses that the action is state-changing, consumes AI credits, creates a generation record, and requires authorization. This is vital for an agent to understand 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the purpose, and includes behavioral and contextual information without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, triggers, behavior, and alternative flows. It lacks explicit mention of the output format (e.g., markdown) but the first sentence already states 'generate markdown documentation'. Given no output schema, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not elaborate on parameter details beyond what the schema provides. It adds minimal extra meaning (e.g., 'State-changing' hints at purpose of parameters like additional_instructions), but not enough to raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: generating markdown documentation from source code. It uses specific trigger phrases like 'supplies source code' and 'document one or more files', distinguishing it from sibling tools like generate-code-comments or generate-uml-diagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear triggers for when to use the tool (when user asks for documentation or code explanation) and mentions alternative flows via browser guidance. However, it does not explicitly compare to sibling generation tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-code-optimizationOptimize Source CodeAInspect
Use this when the user supplies source code and asks for an optimized or refactored version. After authorization, this state-changing action consumes AI credits, creates a generation, and returns the revised code.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional custom name used to identify the optimized code in generation history | |
| filename | Yes | The full file path of the file being optimized (e.g., src/utils/helper.ts) | |
| source_code | Yes | The source code to optimize | |
| optimization_focus | No | Focus area for optimization (default: Performance) | |
| additional_instructions | No | Additional instructions for code optimization |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is state-changing, consumes AI credits, creates a generation, and returns revised code. This adds value beyond annotations (which only indicate readOnlyHint=false, destructiveHint=false, openWorldHint=false) by specifying the cost and output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the usage context, and contains no redundant information. Every sentence provides essential guidance, making it efficient for an AI agent to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description explains the tool's main behavior: source code input, authorization, credit consumption, generation, and output of revised code. It lacks details like error handling or response structure, but the absence of an output schema is partially compensated by stating the return type (revised code).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are fully described in the input schema, so the description does not add additional meaning beyond what the schema provides. The description mentions 'returns the revised code' but does not elaborate on parameter usage or formats, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is for optimizing or refactoring source code provided by the user. It specifies the exact scenario ('when the user supplies source code and asks for an optimized or refactored version'), and the verb 'optimize' distinguishes it from sibling tools like 'generate-code-comments' or 'generate-code-documentation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'when the user supplies source code and asks for an optimized or refactored version.' However, it does not provide guidance on when not to use it or mention alternatives, though the sibling list implies related but distinct functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-code-testsGenerate Code Tests ToolAInspect
Use this when the user supplies source code and asks to generate unit, feature, integration, or framework-specific tests. State-changing generation action: consumes AI credits, creates a generation, and returns test code after authorization. Use browser guidance for local uploads or repository-wide test generation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional custom name used to identify the tests in generation history | |
| filename | Yes | The full file path of the file being tested (e.g., src/utils/helper.ts) | |
| test_type | No | Type of tests to generate (e.g., "unit tests", "integration tests") | |
| source_code | Yes | The source code to generate tests for | |
| test_framework | No | Testing framework to use (e.g., "Jest", "PHPUnit", "JUnit") or "auto-detect" | |
| additional_instructions | No | Additional instructions for test generation |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses state-changing nature, credit consumption, and authorization requirement. Annotations already indicate not read-only (readOnlyHint=false), but description adds concrete behavioral context. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with zero waste. First sentence states when to use, second adds behavioral notes, third gives additional guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavioral traits, and a hint about browser guidance. Lacks output format details but sufficient given no output schema and 6 params (2 required).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description aligns with parameters (test_type, test_framework) but adds no new parameter-level detail beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates unit, feature, integration, or framework-specific tests from source code. It uses specific verbs ('generate') and resource ('tests') and distinguishes from siblings like generate-code-documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user supplies source code and asks to generate...tests' and provides a when-not-to-use hint: 'Use browser guidance for local uploads or repository-wide test generation.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-language-conversionConvert Source Code LanguageAInspect
Use this when the user supplies one source-code file and asks to convert it to another programming language or framework. After authorization, this state-changing action consumes AI credits, creates a generation, and returns converted code using source_code, filename, from_language, and to_language.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional generation history name for the converted output. Defaults to the supplied filename when omitted. | |
| filename | Yes | Filename for the supplied source code, including extension when known, so the generator can name the generation and understand context. | |
| source_code | Yes | Source code contents to convert. Use this only when the customer supplied the code text to the MCP client; use browser guidance for local file picker uploads. | |
| to_language | Yes | Target programming language or framework to convert to, such as TypeScript, Python, Go, Vue, TailwindCSS, CSS, or Laravel. | |
| from_language | Yes | Source programming language or framework to convert from, such as PHP, JavaScript, Python, React, Bootstrap, CSS, or Laravel. | |
| save_to_space | No | Optional destination Space item for saving the converted code after authorization. The authenticated user must be able to manage that Space. | |
| additional_instructions | No | Optional conversion guidance, such as preserving APIs, using a framework version, matching style conventions, or focusing on compatibility. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that it consumes AI credits, creates a generation, and requires authorization. These are important behavioral traits not covered by annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, each with a clear purpose. First sentence states when to use. Second explains the action's side effects and parameters. No filler, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (including nested objects), no output schema, and annotations, the description adequately covers when to use, the state-changing nature, credits, auth, and key parameters. It doesn't detail return format or error handling, but for a conversion tool the output is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all 7 parameters described in the input schema. The description merely references the key parameters (source_code, filename, from_language, to_language) without adding additional meaning or usage details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'convert source code to another language/framework' with specific verb and resource. The title 'Convert Source Code Language' reinforces this. It clearly distinguishes from sibling generation tools like generate-code-comments or generate-code-tests by focusing on conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user supplies one source-code file and asks to convert it to another programming language or framework.' This provides a clear usage condition. It does not explicitly list alternatives but implies that other generate-* tools are for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-swagger-apiGenerate OpenAPI From Source CodeAInspect
Use this when the user supplies API source code and asks for an OpenAPI or Swagger specification. After authorization, this state-changing action consumes AI credits, creates a generation, and returns OpenAPI JSON; it accepts one source_code file or multiple files entries.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional generation history name for the generated OpenAPI output. Defaults to the supplied filename or comma-separated filenames. | |
| files | No | Multiple supplied file contents for one OpenAPI spec. Use this when the customer pasted or supplied several files directly; use browser guidance for local uploads. | |
| filename | No | Filename for source_code in the single-file path. Omit when using files[]. | |
| source_code | No | Source code to analyze for a single supplied file. Provide filename too. Omit when using files[]. | |
| save_to_space | No | Optional destination Space item. | |
| additional_instructions | No | Optional generation instructions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is state-changing, consumes AI credits, and generates output. Annotations confirm non-destructive behavior (destructiveHint=false). No contradictions; the description adds useful context about side effects (credit consumption) and return format (OpenAPI JSON).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the purpose and usage condition. Every phrase contributes meaning, with no wasted words. It efficiently covers purpose, preconditions, side effects, and input structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (multiple input files, optional save_to_space), the description covers usage, side effects, and input format. It mentions the return type (OpenAPI JSON). However, it could briefly explain the authorization step or what 'AI credits' entails. Still, it is complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage). The description adds value by explaining the dual input modes (single file vs. multiple files) and the optional nature of parameters like 'name' and 'save_to_space'. It complements the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool generates OpenAPI or Swagger specifications from API source code. This clearly distinguishes it from sibling tools like 'generate-code-comments', 'generate-code-documentation', etc., which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly advises to use the tool 'when the user supplies API source code and asks for an OpenAPI or Swagger specification.' It implies the context of use but does not explicitly exclude other scenarios or mention alternatives. The guidance is clear but could be more comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-uml-diagramGenerate Uml Diagram ToolAInspect
Use this when the user supplies source code and asks for UML, Mermaid, sequence, class, component, or architecture diagrams. State-changing generation action: consumes AI credits, creates a generation, and optionally writes markdown to a Space after authorization. Use browser guidance for local uploads or full repository diagrams.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional generation name. | |
| filename | Yes | Filename for the source code. | |
| source_code | Yes | Source code to analyze. | |
| diagram_type | Yes | Class Diagrams, Sequence Diagrams, Use Case Diagrams, Activity Diagrams, Component Diagrams, State Diagrams, or Object Diagrams. | |
| save_to_space | No | Optional destination Space item. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is state-changing, consumes AI credits, creates a generation, and optionally writes markdown to a Space after authorization. These details go beyond the annotations (which only deny read-only, open-world, and destructive hints), providing valuable transparency about side effects and costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core use case, and every sentence adds essential information. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, nested objects, no output schema), the description covers the trigger, behavior, and optional save-to-space feature. It could further specify the output format (e.g., Mermaid code or rendered diagram), but overall it provides sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add per-parameter details beyond what the schema already provides, but it does provide overall context about the tool's behavior. This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states when to use the tool: when the user supplies source code and asks for UML or related diagrams. It clearly identifies the action (generating diagrams) and resource (source code), distinguishing it from sibling tools like generate-code-comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for using the tool ('when the user supplies source code and asks for UML...') and additional guidance about browser usage for local uploads. However, it does not explicitly state when not to use it or name alternatives, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-user-infoGet Account Generation StatusARead-onlyInspect
Use this when the user asks which DocuWriter.ai account is connected or whether it can run a generator. Read-only: returns the account name and a can_generate boolean without changing account data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and destructiveHint false. The description adds specific return fields (account name and can_generate boolean) and confirms no data changes. While it covers the essential behavior, it could mention error cases or idempotency, but for a simple read-only tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first provides clear usage guidance, the second states functionality. It is front-loaded, concise, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and simple behavior, the description fully explains what it does (returns account name and can_generate boolean) and when to use it. No additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters, the input schema provides no information. The description implicitly indicates no input is needed by stating it 'returns... without changing account data.' According to calibration, 0 params baseline is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check which DocuWriter.ai account is connected and whether it can run a generator. It distinguishes itself from sibling tools like generate-code-* or space management tools by focusing on account status and generation capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when the user asks which DocuWriter.ai account is connected or whether it can run a generator.' This provides clear usage context and implicitly excludes other scenarios handled by sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
global-searchSearch All Space DocumentsARead-onlyInspect
Use this when the user wants to search documents across every accessible Space rather than one known Space. Read-only: returns matching titles, snippets, Space details, and URLs for a query without changing content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (minimum 2 characters) | |
| per_page | No | Number of results to return (default 20, max 100) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description confirms and adds what is returned (titles, snippets, Space details, URLs). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Usage guidance front-loaded, followed by behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, safety, and return info. No output schema, but description provides minimal return structure. Slightly incomplete on result ordering/pagination details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description does not add extra parameter details beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'search documents across every accessible Space', using specific verb and resource. Distinguishes from sibling tool 'search-space-documents' which searches within a single space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (search across all accessible spaces) and implies when not to (for a single known space, use 'search-space-documents').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-space-documentsList Space Documents ToolARead-onlyInspect
Use this when the user wants to browse a Space tree, list pages/docs/documents/folders, find numeric document or item IDs, or inspect structure before editing. Read-only: returns documents and folders for one numeric space_id without changing content.
| Name | Required | Description | Default |
|---|---|---|---|
| space_id | Yes | The numeric ID of the space to list documents from. Call list-spaces first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states read-only nature and no content change, reinforcing annotations. Adds detail about returning documents and folders for a single space_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with use cases, no wasted words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers core behavior. Could be more specific about output structure but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for space_id. Description does not add new parameter info beyond mention of 'numeric space_id', which is already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool is for browsing Space trees, listing pages/docs/documents/folders, and inspecting structure. Distinct from sibling tools like list-spaces and search-space-documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (browse, list, find IDs, inspect structure) and context. Does not explicitly mention when not to use or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-spacesList Spaces ToolARead-onlyInspect
Use this when the user asks to see, choose, or look up their documentation Spaces, especially before using tools that need a numeric space_id. Read-only: returns accessible Spaces and does not change settings or documents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. Description confirms read-only and adds context about returning accessible Spaces and not changing settings, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage context, no unnecessary words, each sentence provides distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description covers usage and safety clearly. Could mention return format (e.g., list of space IDs and names) but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline is 4. Description does not need to add semantics since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'list' and resource 'Spaces', and distinguishes from sibling tools by emphasizing read-only nature and use case for obtaining numeric space_id before other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when user asks to see/choose/look up spaces, especially before tools needing space_id. Implicitly excludes mutation use, but does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-space-documentsSearch Space Documents ToolARead-onlyInspect
Use this when the user wants to find pages, docs, documents, or content inside one specific Space. Read-only: searches the selected Space and returns matching document snippets without changing content. Requires numeric space_id from list-spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination | |
| query | Yes | Search query (minimum 2 characters) | |
| per_page | No | Number of results per page | |
| space_id | Yes | The numeric ID of the space to search in. Call list-spaces first. | |
| highlight | No | Whether to highlight search terms in results |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds value by stating 'Read-only: searches the selected Space and returns matching document snippets without changing content,' reinforcing the read-only nature and hinting at output format. This goes beyond annotations but is not extensively detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, front-loaded with the primary purpose. It is extremely concise with zero redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description mentions 'returns matching document snippets' but does not detail pagination, response structure, or limitations. Still, it adequately covers purpose, usage context, and prerequisites. Slightly vague on output format prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are documented in the input schema with 100% coverage. The description adds no extra semantic information beyond repeating the prerequisite ('space_id from list-spaces') which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Use this when the user wants to find pages, docs, documents, or content inside one specific Space.' It uses a specific verb ('search') and resource ('documents inside one specific Space'), distinguishing it from siblings like global-search (global) and list-space-documents (list all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context ('Use this when the user wants to find ... inside one specific Space') and a prerequisite ('Requires numeric space_id from list-spaces'). However, it does not explicitly state when not to use this tool or suggest alternatives like global-search for cross-space searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update-spaceUpdate Space ToolAInspect
Use this when the user wants to rename a Space, edit its description, make it public/private, publish/unpublish it, or change its public slug. State-changing: updates manageable Space settings after authorization. Requires numeric space_id from list-spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New Space name when the user wants to rename the Space. | |
| slug | No | Public slug to use when the Space is published or made public. | |
| space_id | Yes | Numeric Space ID to update. Use list-spaces first when the user gives a Space name. | |
| is_public | No | Public visibility flag. | |
| description | No | New Space description. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only, and the description adds that it is state-changing and requires authorization. No contradictions; the behavioral description is clear and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both highly informative with no wasted words. The first enumerates use cases, the second provides behavioral and licensing context (state-changing, authorization, prerequisite).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (all documented) and no output schema, the description covers the core functionality and usage context. Could mention return value type (e.g., updated space object or success), but overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter is described in the schema. The description does not add new details about parameters beyond reinforcing space_id's source (list-spaces). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists specific actions (rename, edit description, change visibility/publish status, change slug) with clear verb-resource pairs, and distinguishes this update tool from siblings like create-space and delete-space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it (e.g., 'Use this when the user wants to...') and hints at a prerequisite ('Requires numeric space_id from list-spaces'). It lacks explicit exclusions for non-update operations (creation, deletion), but the listed use cases effectively imply boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!