md-mcp

by afriemann

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 has a clearly distinct purpose: adding, deleting, getting index, getting content, previewing replacement, replacing, and searching. Even the closely related patch_section and replace_section serve different functions (preview vs action). No overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (add_section, delete_section, get_index, get_section, patch_section, replace_section, search_sections). Deviations are absent.
Tool Count5/5
7 tools is well-scoped for the domain of Markdown section manipulation. Each tool addresses a core operation without redundancy, and the count is neither too few nor too many.
Completeness4/5
The toolset covers essential CRUD-like operations (add, read, update, delete) plus search and preview. However, it lacks a tool to rename a section heading or move sections, which are minor gaps in a complete lifecycle.
Average 4.1/5 across 7 of 7 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 must cover behavior. It details the output format and how literal dots are escaped, but does not explicitly state that the tool is read-only, nor mention error handling or prerequisites. The transparency is adequate but not exhaustive.
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 uses three concise sentences, front-loading the purpose and then detailing the output structure and path escaping. No extraneous information is included, and it is well-organized.
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 simplicity (one parameter, output schema exists), the description covers the output format and a special case (dot escaping). However, it omits any discussion of errors (e.g., missing file, invalid path) or preconditions, leaving minor gaps.
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?
The schema has 0% description coverage for the single required parameter file_path. The description does not explain what file_path represents, its expected format, or any constraints, leaving the agent with no additional guidance beyond the schema type.
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 returns the section index of a Markdown file as a nested tree, specifying the structure of each node. It distinguishes itself from sibling tools like add_section, get_section, etc. which operate on individual sections.
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 by mentioning the path field is used by all other tools, suggesting this tool is foundational for locating sections. However, it lacks explicit guidance on when to use this vs. alternatives like get_section, and does not state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It states that the heading is preserved and returns 'ok' on success, but does not cover error cases (e.g., missing section or file), idempotency, or side effects. Adequate for a simple tool but 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?
Two concise sentences with no wasted words. The main purpose and key behavioral note (heading preserved) are front-loaded. Every sentence adds value.
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?
With 3 required params and no output schema details, the description is too sparse. It lacks context on file paths, section hierarchy, error handling, and the output format beyond 'ok'. Sibling tools provide some context, but the description alone is insufficient for confident 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 coverage is 0% (no descriptions on properties). The description does not explain the parameters (file_path, path, new_content) beyond their names. The agent must guess the format or meaning of 'path' (likely section path) and whether 'new_content' is plain text or markdown. Fails to compensate 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 action: replace the body of a section while preserving the heading. It distinguishes from sibling tools like add_section, delete_section, etc., by specifying exactly what is replaced (body) and what is preserved (heading).
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 via its action, but lacks explicit guidance on when to use this tool vs. alternatives like patch_section. No when-not or exclusions are provided, so the agent must infer from context.
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 must disclose behavior fully. It states that the tool does not write, returns a unified diff as a string, and returns empty string if no changes. It lacks details on permissions, idempotency, or side effects, but the core safety (read-only) is clear.
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 two sentences, each adding essential information: what it does and when to use it. No wasted words.
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?
Despite having an output schema, the description lacks parameter explanations and behavioral details (e.g., error conditions, prerequisites). It is complete in stating purpose and return type but fails to cover the three required parameters, leaving significant gaps.
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?
The input schema has 3 required parameters (file_path, path, new_content) with 0% description coverage. The description provides no explanation of what these parameters mean, leaving the agent to infer from the tool name and sibling tools. This is insufficient.
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 returns a unified diff of what replace_section would do without writing. It uses specific verb 'Return' and resource 'unified diff', and distinguishes itself from replace_section by emphasizing preview vs. write.
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 says 'Useful for previewing changes before committing them,' which provides clear context for when to use. It implicitly contrasts with replace_section but does not explicitly state when not to use or list other alternatives.
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?
No annotations provided, so description carries full burden. It covers placement behavior and return value but lacks details on error handling (e.g., file not found, invalid heading) and whether it overwrites existing sections.
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, front-loaded with purpose, and uses bullet-like formatting for placement options for clarity.
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 6 parameters, 0% schema coverage, and no annotations, the description adequately covers parameter semantics and return value. However, it omits details on error conditions and file existence requirements.
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%, so description provides all parameter meaning. It explains heading format with example, content as body text, and placement parameters with clear semantics and constraint (only one of under/before/after).
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 'Insert a new section into a Markdown file' with a specific verb and resource. It distinguishes from siblings like delete_section by detailing placement options.
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 when to use each placement parameter (under, before, after) and defaults to appending when none are set. It does not explicitly exclude alternatives but sibling tool names make context clear.
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?
No annotations are provided, so the description fully bears the burden. It transparently details the deletion behavior for both include_children=True (deleting heading, body, and child sections) and False (promoting child sections). It also specifies the return value.
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 three short paragraphs, front-loading the core action. Every sentence contributes useful information without repetition or fluff.
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 three parameters and the include_children variation, the description adequately covers behavior and return value. An output schema exists, so not detailing return format further is acceptable. Could be improved by describing the 'ok' response structure, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the include_children parameter's effect, but does not add meaning for file_path or path beyond their names. The schema already marks them as required, so the description adds moderate value.
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 deletes a section from a Markdown file, specifying the resource (section) and action (delete). It distinguishes from siblings like add_section and get_section by focusing on deletion behavior and parameters.
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 when to use include_children=True vs False, providing clear guidance on two common scenarios. However, it does not explicitly state when not to use this tool or mention prerequisites like file/section existence, which could be inferred but not stated.
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 the description carries full burden. It discloses case-insensitive matching, depth behavior, error handling (raises error string), and return format (raw Markdown). However, it doesn't state that the operation is read-only (though inferred) or mention any restrictions.
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, well-structured, and front-loaded with the core purpose. Every sentence adds value, with no extraneous information. The depth parameter explanation is clear and compact.
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 presence of an output schema, the description does not need to detail return values. It adequately covers path matching, depth semantics, and error behavior. However, the lack of explanation for 'file_path' is a minor gap, and the sibling context from the list helps differentiate.
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 thoroughly explains the 'path' format and 'depth' options with examples. It does not elaborate on 'file_path', which is required, leaving some ambiguity. Overall, it adds significant 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?
Description clearly states the tool returns heading line(s) and body of a section at a given path. The verb 'return' and resource 'section' are specific, and it distinguishes from sibling tools like add_section, delete_section, etc.
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 how to use the tool (specify path, optionally depth) and implies it's for retrieving section content. It does not explicitly state when not to use it or mention alternatives, but the sibling context indirectly provides differentiation.
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, the description fully discloses behavior: return format (match objects with path, line number, text), line numbering (1-based), scope (only section bodies, not children or headings), error handling (raises error string on invalid regex). No contradictions with annotations since none exist.
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 and well-structured, starting with the main action, then providing a clear example of the return format, followed by important notes. Every sentence adds value, and the structure aids readability.
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 and presence of an output schema (though not shown), the description covers all necessary aspects: return value format, scope, line numbering, error behavior, and reference to alternative. It is complete for a search operation.
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 coverage is 0%, so description must compensate. It explains `query` is a Python regex, and `file_path` is implied as the file to search. However, the third parameter `case_sensitive` is not mentioned at all, leaving its semantics unclear from the description alone. Partial compensation but incomplete.
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 'Search all section bodies for lines matching `query` (regex)', providing a specific verb and resource. It distinguishes from sibling tools like add_section, delete_section, get_index, etc., none of which are search functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Note: heading text is not searched — only section bodies. If the term you are looking for may appear in a heading, call `get_index` first and scan the returned paths.' This tells when not to use the tool and suggests an alternative. Also notes that only section bodies are searched, not children, avoiding confusion.
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:

[![md-mcp MCP server](https://glama.ai/mcp/servers/afriemann/md-mcp/badges/card.svg)](https://glama.ai/mcp/servers/afriemann/md-mcp)

Score Badge

Copy to your README.md:

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

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