Markdown Editor MCP Server

by KazKozDev

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: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between delete_element and delete_item, which could cause confusion as their descriptions are unclear or missing. Additionally, search_tools is ambiguous and doesn't fit cleanly with the document editing focus, potentially leading to misselection.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., create_directory, insert_element, move_element) with only minor deviations like search_tools and undo, which are less structured but still readable. Overall, the conventions are predictable and aid in tool identification.
Tool Count5/5
With 15 tools, the count is well-scoped for a Markdown editor server, covering file management, document structure manipulation, content editing, and search functionalities. Each tool appears to serve a specific role without feeling excessive or insufficient for the domain.
Completeness4/5
The tool set provides comprehensive coverage for Markdown editing, including CRUD operations for files and elements, navigation, and undo functionality. A minor gap exists in lacking a dedicated tool for creating or modifying specific Markdown elements like lists or code blocks, but agents can work around this using insert_element and replace_content.
Average 2.7/5 across 15 of 15 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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 action ('Removes') but lacks details on permissions needed, whether the deletion is permanent or reversible, error handling, or effects on the document structure. This is insufficient 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, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, and an output schema (which might cover return values), the description is incomplete. It doesn't address safety, permissions, or error scenarios, leaving significant gaps for an AI agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't explain what 'file_path' and 'path' parameters mean, their formats, or how they interact. This leaves key input semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Removes') and the resource ('a block from the document'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_item' or 'move_element', which might also remove content, 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 such as 'delete_item' or 'move_element', nor does it mention prerequisites like file existence or permissions. It's a basic statement without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'fetches' content, implying a read operation, but doesn't cover critical aspects like error handling (e.g., if the path is invalid), performance (e.g., rate limits), or output format (though an output schema exists). This leaves gaps in understanding how the tool behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('fetches') and resource. There is no wasted wording, and it directly communicates the tool's function without unnecessary elaboration, 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 (2 required parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks details on error cases, permissions, or behavioral nuances. It meets a basic threshold but doesn't provide a complete picture for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by its path' but doesn't explain what 'file_path' and 'path' represent or how they differ (e.g., file location vs. block hierarchy). It adds minimal semantic value beyond the parameter names, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetches') and resource ('full content of a specific block'), making the purpose understandable. It distinguishes from siblings like 'get_document_structure' (which likely lists elements) or 'search_text' (which searches content). However, it doesn't explicitly differentiate from 'get_context' or other read-like siblings, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the file to exist), exclusions (e.g., not for metadata), or comparisons to siblings like 'get_document_structure' for overviews or 'search_text' for content queries. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'scalability feature' but doesn't explain what this entails—such as performance characteristics, rate limits, or authentication needs. The description lacks details on how the search works, what the output includes, or any constraints, making it insufficient for a tool with behavioral implications.
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 sentence that is front-loaded and efficient, with no wasted words. It directly states the tool's purpose without unnecessary elaboration. However, it could be slightly more structured by explicitly mentioning the scope (e.g., 'among sibling tools') to improve clarity without sacrificing conciseness.
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 that there is an output schema (which reduces the need to describe return values) and high schema coverage, the description is minimally adequate. However, for a search tool with no annotations and behavioral aspects like scalability, it should provide more context on how results are ranked or what 'scalability feature' means. The description is incomplete in addressing these nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'query' parameter well-documented as a string describing the operation. The description adds no additional meaning beyond the schema, such as clarifying search syntax or result relevance. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 as 'find the right tool for your complex task among all available tools,' which specifies the verb 'find' and the resource 'tool.' It distinguishes itself from siblings like 'search_text' by focusing on tool discovery rather than content searching. However, it doesn't explicitly mention that it searches among the sibling tools listed, which could make it slightly less specific.
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 specify scenarios where searching for tools is preferable over directly using known tools like 'list_directory' or 'search_text,' nor does it mention prerequisites or exclusions. This lack of context leaves the agent without clear usage instructions.
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 return content without disclosing behavioral traits like error handling, performance, or side effects. It doesn't mention if it's read-only, safe, or has any limitations beyond the basic functionality.
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 with zero waste. Every word contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and moderate complexity, the description is minimally adequate but lacks depth. It covers the basic operation but misses behavioral context and usage guidelines, leaving gaps in completeness for a tool with no annotations.
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 50% (only 'path' has a description), and the description adds no parameter-specific details beyond what the schema provides. It implies parameters are used to locate the element but doesn't explain their roles or interactions, resulting in a baseline score due to moderate schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and resource ('target element along with its immediate neighbors'), specifying the scope ('before and after'). It distinguishes from siblings like 'read_element' (which likely returns only the element) and 'get_document_structure' (which likely returns broader structure), though not explicitly named.
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 'read_element' or 'get_document_structure' is provided. The description implies usage for contextual analysis but lacks prerequisites, exclusions, or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an insertion operation but doesn't mention whether this modifies files in-place, requires write permissions, has side effects, or what happens on failure. For a tool that modifies documents, this lack of behavioral context 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 that front-loads the core action. Every word earns its place by specifying what's inserted (new block), what types are possible, and the relative positioning. There's no wasted verbiage or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description doesn't need to explain return values. However, for a tool with 6 parameters, low schema coverage (17%), and no annotations, the description should provide more context about the insertion behavior, error conditions, and relationship to sibling tools. It's minimally adequate but leaves significant 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 only 17%, with only one parameter ('path') having a description. The description adds minimal value by mentioning 'relative to an existing one' which hints at the 'path' and 'where' parameters, but doesn't explain the purpose of 'file_path', 'element_type', 'content', or 'heading_level'. The baseline is 3 since the description provides some context but doesn't compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inserts' and resource 'new block' with examples of block types. It specifies the action is relative to an existing element, which distinguishes it from tools like 'create_file' or 'replace_content'. However, it doesn't explicitly differentiate from similar tools like 'move_element' or 'update_metadata'.
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_file', 'replace_content', 'move_element', or 'update_metadata'. It mentions the action is 'relative to an existing one' but doesn't clarify when this specific insertion approach is preferred over other content modification methods.
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 action but doesn't describe traits like whether it's read-only, pagination behavior, error handling for invalid paths, or output format details. This leaves significant gaps for a tool that interacts with filesystem-like resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete behavioral context, it doesn't fully compensate for the lack of structured metadata, leaving gaps in understanding how the tool behaves in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter information beyond what the schema already shows (a 'path' parameter). The schema provides examples like '.' and '/path/to/directory', while the description doesn't elaborate on semantics such as relative vs. absolute paths or default behavior. Baseline 3 is appropriate as the schema does the minimal documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('files and folders in the workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_document_structure' or 'search_text', which might also involve listing content, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_text' for filtered results or 'get_document_structure' for hierarchical views. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions moving 'an element (and its children)', implying hierarchical effects, but fails to detail critical traits like whether the operation is destructive (e.g., overwrites target), requires specific permissions, or has side effects like updating references. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word earns its place by specifying the move operation, the element scope (including children), and the destination context, with no redundant or vague phrasing.
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 complexity (a mutation with 4 parameters) and the presence of an output schema (which alleviates need to explain return values), the description is minimally adequate. However, with no annotations and low schema coverage, it lacks completeness in behavioral and parameter details, making it just sufficient for basic understanding but insufficient for robust agent decision-making.
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 specific meaning beyond the input schema, which has 0% description coverage. It implies parameters for source, target, and file context but doesn't explain semantics like path formats or the 'where' enum's effect. With low schema coverage, the description fails to compensate, resulting in a baseline score due to the lack of parameter details in either source.
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 ('Moves'), the resource ('an element (and its children)'), and the context ('to a new location in the document'). It distinguishes from siblings like 'delete_element' or 'insert_element' by specifying relocation rather than removal or addition. However, it doesn't explicitly differentiate from 'replace_content' which might involve movement, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'insert_element' for adding new content or 'delete_element' for removal. It lacks context on prerequisites, such as needing an existing element to move, or exclusions, like not being suitable for non-structural changes. This leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Overwrites' (implying mutation) and 'Maintains document structure', but lacks details on permissions, reversibility (e.g., via 'undo'), error handling, or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. Every phrase ('Overwrites the content', 'specific block', 'Maintains document structure') adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema (which reduces need to explain returns), the description is incomplete. It covers the basic purpose but lacks usage guidelines, behavioral details, and parameter semantics, making it minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no parameter-specific information beyond what the schema's examples imply. The description doesn't explain 'path' semantics or 'new_content' constraints, leaving parameters largely undocumented. Baseline 3 is applied due to the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Overwrites') and target ('content of a specific block'), and distinguishes it from siblings like 'update_metadata' or 'insert_element' by focusing on replacement rather than creation or modification of metadata. However, it doesn't explicitly differentiate from 'delete_element' or 'read_element' in terms of scope.
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 'update_metadata', 'insert_element', or 'delete_element'. It mentions maintaining document structure, but doesn't specify prerequisites, exclusions, or contextual cues for selection among 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. While 'reverts' implies a mutation that changes document state, it doesn't specify whether this is destructive (e.g., irreversible), has side effects (e.g., affects other tools), requires specific permissions, or details error conditions (e.g., what happens if N exceeds available operations). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('reverts') and key parameters ('last N operations'). There is no wasted wording, making it easy to parse quickly while conveying essential information.
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 complexity (a mutation with 2 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for that in the description. However, for a tool that modifies document state, more details on behavior, constraints, and usage context would improve completeness, especially with no annotations to fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning by explaining that 'count' refers to 'last N operations,' which clarifies the parameter's purpose beyond the schema's basic type and examples. However, with 0% schema description coverage, it doesn't fully compensate for the lack of details on 'file_path' (e.g., format requirements or path validity) or constraints on 'count' (e.g., maximum value). The baseline is 3 due to partial 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 ('reverts') and resource ('operations on the document'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'replace_content' or 'update_metadata' that might also modify documents, leaving some ambiguity about when to use undo versus other modification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires an open document), exclusions (e.g., cannot undo after saving), or compare to siblings like 'replace_content' for specific edits. This lack of context makes it harder for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Modifies' implies a mutation operation, but it doesn't address critical aspects like whether this overwrites or merges metadata, what permissions are required, if changes are reversible, or what happens on errors. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 2 parameters, nested objects, no annotations, but with an output schema, the description is minimally adequate. The output schema reduces the need to describe return values, but the description should do more to explain behavioral aspects and parameter usage for a tool that modifies documents.
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 doesn't explain either parameter beyond what the schema shows through examples. With 0% schema description coverage, the description adds no semantic value about 'file_path' or 'metadata' parameters. However, since there are only 2 parameters and the schema provides clear examples, this meets the baseline for minimal viability.
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 ('Modifies') and target ('document's Frontmatter'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'replace_content' or 'insert_element' that might also modify document content, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'replace_content' or 'insert_element' for document modifications. It mentions the target ('Frontmatter') but doesn't specify prerequisites, exclusions, or contextual usage patterns.
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 'semantic search' and 'returns structural paths', but lacks details on permissions, rate limits, error handling, or what 'structural paths' entail (e.g., format, depth). This is a significant gap for a search 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 core purpose. Every word earns its place, with no redundant or vague phrasing. It's appropriately sized for a tool with two parameters and an output schema.
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), no annotations, and an output schema (which handles return values), the description is minimally adequate. However, it lacks context on behavioral traits and parameter nuances, leaving gaps in understanding how to use it effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'query' has a description), and the description adds no parameter-specific information beyond what's in the schema. It doesn't explain 'file_path' semantics (e.g., supported formats, relative vs. absolute paths) or clarify 'semantic search' for the 'query' parameter. Baseline 3 is appropriate as the schema partially documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('performs a semantic search for text strings') and the resource ('in document'), distinguishing it from siblings like 'search_tools' (which appears to be a meta-tool) and 'get_document_structure' (which retrieves structure without searching). The verb 'search' is specific and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'search_text' over 'search_tools' or 'get_context', nor does it specify prerequisites like file existence or format compatibility. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior as parsing and returning a tree, which implies a read-only operation without side effects, but lacks details on error handling, performance, or output format specifics. It adds some context with the navigation advice but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core functionality in the first sentence and adds a concise usage tip in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (parsing Markdown structure), no annotations, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose and usage but could improve by addressing behavioral aspects like error cases or limitations, though the output schema mitigates 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 fully documents both parameters (file_path and depth). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how depth affects the tree structure or file_path validation, resulting in a baseline 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 clearly states the specific action ('parses the Markdown file') and the resource/result ('returns a tree of headings and elements'), distinguishing it from siblings like read_element or search_text by focusing on structural analysis rather than content reading or searching.
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?
It provides explicit guidance to 'use this first to navigate,' indicating a primary use case for initial exploration of document structure. However, it does not specify when not to use it or name alternatives among siblings, such as read_element for content reading.
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:

[![markdown-editor-mcp-server MCP server](https://glama.ai/mcp/servers/KazKozDev/markdown-editor-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/KazKozDev/markdown-editor-mcp-server)

Score Badge

Copy to your README.md:

[![markdown-editor-mcp-server MCP server](https://glama.ai/mcp/servers/KazKozDev/markdown-editor-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/KazKozDev/markdown-editor-mcp-server)

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/KazKozDev/markdown-editor-mcp-server'

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