docx-comments

by kosh-jelly

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: comment creation, reply, resolution, track changes, acceptance/rejection, and document reading/search. No overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_comment, accept_change, search_document), making the set predictable.
Tool Count5/5
With 9 tools, the count is within the ideal 3-15 range and well-scoped for the server's focus on .docx comments and track changes.
Completeness4/5
The tool set covers core CRUD for comments and track changes, but lacks a tool to delete comments entirely (only mark resolved) and to list all track changes independently, though read_document includes them.
Average 4.3/5 across 9 of 9 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool modifies the file (overwrites or saves to new), creates timestamped backup, and returns success. However, it omits specifics like whether the comment becomes hidden or immutable after resolution.
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 concise with no wasted words. It uses clear sections (Args, Returns) and front-loads the purpose. Every sentence provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema, the description covers all inputs and return values. It could mention prerequisites (e.g., comment must exist) or visual effects of resolution, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains each parameter: path is path to .docx file, comment_id is ID, and output_path describes save behavior including default backup. This adds significant value beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Mark a comment as resolved/done', which is a specific verb and resource. It clearly distinguishes from siblings like accept_change and reject_change which are for track changes, not comments.
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 explicit guidance on when to use this tool versus alternatives like create_comment or create_reply. The description only states what it does, not when it's appropriate or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses permanent modification, backup behavior, and return values. It explains behavior for insertions and deletions clearly.
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?
Well-structured with purpose, effect details, args, and returns. Concise but could be slightly tighter; the args section uses a code block that is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers the tool's operation, including return dictionary structure. Given output schema is described, it is complete and clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaningful details for all three parameters: path, change_id, and output_path behavior. Compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Accept a tracked change (apply the change permanently).' It distinguishes from siblings like reject_change and create_track_change with specific verb+resource.
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 explicit guidance on when to use this tool vs reject_change or other alternatives. Usage context is only implied through the description of effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses return value structure, backup creation behavior, and the uniqueness requirement. Could add permission or file format constraints.
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?
Well-structured with Args and Returns sections, but slightly verbose in the Returns list. Efficient overall, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: behavior, return fields, backup, uniqueness. Lacks error handling and prerequisites (e.g., file existence), but output schema is implied. Adequate given parameters and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage in description, the text explains all 5 parameters: path, find_text, replace_with, author (with default), and output_path behavior (backup fallback). Adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool makes an edit with track changes enabled (insertion, deletion, or replacement) on a .docx file. It clearly distinguishes from siblings like accept_change or reject_change by focusing on creating changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tracking edits but does not explicitly state when to use this tool over alternatives. It mentions constraints (find_text must be unique) but lacks contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavioral traits: it modifies the document, creates a timestamped backup if output_path is omitted, overrides original, and gives default author. Error handling is detailed. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Errors sections. It is moderately long but every sentence serves a purpose. Minor verbosity could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, an output schema, and no annotations, the description covers all necessary aspects: purpose, parameters, return values, error cases, and side effects. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds comprehensive parameter details: path, anchor_text (must exist, unique), comment_text, author (default), output_path (behavior). It also describes return values and errors, adding far more meaning than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a comment anchored to specific text in a Word document.' This specifies the action (Add) and resource (comment on text in Word doc), distinguishing it from sibling tools like create_reply and create_track_change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides error conditions (anchor text not found or not unique) but does not explicitly guide when to use this tool versus siblings like create_reply. No direct comparison or context for selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description compensates by detailing return structure, clamping behavior of indices, and conditional inclusion of comments and track changes. It discloses 0-based inclusive indexing and default for include_annotations.
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 well-structured with a brief purpose, usage context, Args, and Returns blocks. It is concise yet informative, though the Returns block is slightly detailed but justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and an output schema, the description covers parameters, return values, and usage context adequately. It could elaborate on edge cases like out-of-range indices, but the clamping mention helps. Overall, it's complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args block explaining each parameter: path, start_index (0-based inclusive), end_index (0-based inclusive), and include_annotations (default false). This significantly adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific range of paragraphs from a Word document.' It distinguishes from sibling tools by advising use after search_document for context or to avoid loading the full document, making the purpose distinct.
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?
Provides explicit usage context: 'Use after search_document to get more context around matches, or to read a specific section without loading the full document.' While it doesn't list alternatives or when-not-to-use, the context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains the return value structure in detail (metadata, paragraphs, comments, track_changes). It covers parameters and defaults. No mention of error handling, but adequate 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?
Well-structured with sections for Args and Returns, front-loaded with purpose. Could be slightly more concise, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a detailed return structure (metadata, paragraphs, comments, track_changes). The tool's purpose is fully covered in context of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds full parameter semantics: path required, include_text/comments/track_changes with defaults and what they control. This significantly adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a Word document and extract content, comments, and track changes', specifying verb and resource. It distinguishes from sibling tools like accept_change and create_comment, which are mutational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies reading vs. modifying, but does not explicitly state when to use or when not to use alternatives. No exclusions or when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that for insertions text is removed, for deletions text is restored, and if output_path is omitted, a timestamped backup is created and original overwritten. It does not mention required permissions or error handling.
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 well-structured with sections for Args and Returns, using bullet points. It is slightly verbose but efficient for the level of detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal) and sibling tools, the description covers behavioral nuances (insertion vs deletion), output structure, and backup behavior. It is thorough for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains all three parameters (path, change_id, output_path) with details on output_path's default behavior. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rejects a tracked change and distinguishes between insertions (remove text) and deletions (restore text). It differentiates from the sibling 'accept_change' by specifying undo behavior.
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 explains what the tool does and its effects, but does not explicitly state when to use reject over accept or provide prerequisites. The contrast with accept_change is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals key traits: if output_path is omitted, the tool creates a timestamped backup and overwrites the original file, which is critical for understanding the destructive action. It also describes the returned dictionary fields. While permissions or error handling are absent, the backup behavior adds significant value, warranting a 4.
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 concise: a one-line purpose sentence, a structured Args list, and a Returns section. Every sentence provides essential information without redundancy. It is front-loaded with the core action and efficiently organized for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 3 required, modifies a file) and the presence of an output schema, the description covers all necessary aspects: parameter meanings, behavioral nuance (backup on overwrite), and return format. It is complete enough for an agent to use the tool correctly without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain all parameters fully. The Args section details each parameter's purpose (path, parent_comment_id, reply_text, author with default, output_path with behavior). This completely compensates for the schema's lack of descriptions, earning the maximum score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Add a reply to an existing comment in a Word document,' which clearly identifies the action (adding a reply) and the resource (existing comment). This distinguishes it from sibling tools like create_comment (which creates a new comment) and accept_change (which handles track changes), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring 'parent_comment_id' (an existing comment), providing clear context for when to use the tool. However, it does not explicitly contrast with alternatives like create_comment or mark_comment_resolved, leaving some inference needed. A score of 4 reflects good but not exhaustive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral details: it returns matching paragraphs with surrounding context, limits results via 'max_results', and optionally includes annotations. The return structure is thoroughly described, including fields like 'match_start', 'match_end', and 'context_before'.
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 well-structured with a summary, usage hint, parameter list, and return explanation. It is efficient but slightly verbose; for example, the 'Args' and 'Returns' sections could be condensed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-contained and complete for a search tool. It covers purpose, parameters, behavior, and return format, leaving no ambiguity about what the tool does or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the 'Args' section in the description clearly explains each parameter, including defaults and effects. The return value is also detailed, compensating fully for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Search for text in a Word document,' which clearly states the verb and resource. It distinguishes the tool from siblings like 'read_document' by emphasizing that it finds specific content without loading the entire document.
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 advises using the tool to 'find specific content without loading the entire document,' implying it is not for full-document reading. However, it does not explicitly name alternative tools like 'read_document' for when the entire document is needed.
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:

[![docx-comments-mcp MCP server](https://glama.ai/mcp/servers/kosh-jelly/docx-comments-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kosh-jelly/docx-comments-mcp)

Score Badge

Copy to your README.md:

[![docx-comments-mcp MCP server](https://glama.ai/mcp/servers/kosh-jelly/docx-comments-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kosh-jelly/docx-comments-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/kosh-jelly/docx-comments-mcp'

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