1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@md-mcp Fetch the 'Installation' section from docs/guide.md" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

md-mcp

by afriemann

Overview Schema Related Servers Score Discussions

Python

Local

md-mcp

An MCP server that gives agents surgical read/write access to individual sections of Markdown files.

Overview

Large Markdown files — documentation, changelogs, wikis — are expensive for agents to work with: reading the entire file just to update one section wastes tokens, and rewriting the whole file risks accidental data loss. md-mcp solves this by exposing each section as an individually addressable unit, so an agent can fetch, edit, or delete exactly the slice it needs without touching anything else.

The server runs over stdio as a local MCP server. Files are addressed by path on disk; sections within a file are addressed by a dot-separated heading path (e.g. "User Guide.Installation.Prerequisites"). Parsed ASTs are cached in memory and invalidated automatically on mtime change, so repeated reads of an unchanged file are fast.

Related MCP server: mnema

Installation

The package is not yet published to PyPI. Install it in editable mode directly from the repository.

pip

pip install -e .

uv

uv pip install -e .

Connecting to opencode / Claude Desktop

After installation the md-mcp entry-point script is on your PATH. Add it as a local stdio MCP server in your client config.

opencode (`opencode.json` / `opencode.jsonc`)

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "md-mcp": {
      "type": "local",
      "command": ["md-mcp", "--allow-root", "/your/docs/dir"]
    }
  }
}

Claude Desktop (`claude_desktop_config.json`)

Claude Desktop uses the top-level key mcpServers:

{
  "mcpServers": {
    "md-mcp": {
      "command": "md-mcp",
      "args": [],
      "transport": "stdio"
    }
  }
}

Dot-path addressing

Every tool that targets a section takes a path argument — a dot-separated string of heading texts from the document root down to the target section. Given this Markdown file:

# My Project

## Installation

### Prerequisites

## Usage

The available paths are:

Section	Path
`# My Project`	`My Project`
`## Installation`	`My Project.Installation`
`### Prerequisites`	`My Project.Installation.Prerequisites`
`## Usage`	`My Project.Usage`

Matching is case-insensitive, so my project.installation and My Project.Installation resolve to the same section. Ambiguous paths (duplicate heading texts at the same level) resolve to the first match.

Tool reference

Tool	Arguments	Returns	Description
`get_index`	`file_path: str`	`dict`	Returns the full section tree of a file as a nested dict with `heading`, `level`, `path`, and `children` fields.
`get_section`	`file_path: str`, `path: str`, `depth: int \| None = None`	`str`	Returns the raw Markdown text of the named section. `depth=None` (default): full subtree; `depth=0`: heading + own body only; `depth=N`: heading + N levels of children.
`search_sections`	`file_path: str`, `query: str`, `case_sensitive: bool = False`	`list`	Searches all section bodies for lines matching `query` (Python regex). Returns a list of `{"path", "matches": [{"line", "text"}]}` objects in file order. Each section's own body is searched independently — results are never duplicated across parent and child. Heading text is not searched — use `get_index` to find terms in headings.
`add_section`	`file_path: str`, `heading: str`, `content: str`, `under: str \| None = None`, `before: str \| None = None`, `after: str \| None = None`	`str`	Inserts a new section. `heading` must start with `#`–`######` followed by a space. Placement: `under` (last child), `before` (immediately before), `after` (immediately after including its children), or omit all to append. Returns `"ok"`.
`replace_section`	`file_path: str`, `path: str`, `new_content: str`	`str`	Replaces the body of the named section, preserving its heading line. Returns `"ok"`.
`patch_section`	`file_path: str`, `path: str`, `new_content: str`	`str`	Returns a unified diff of what `replace_section` would write, without modifying the file. Returns an empty string if there are no changes.
`delete_section`	`file_path: str`, `path: str`, `include_children: bool = True`	`str`	Deletes the named section. With `include_children=True` (default) removes the heading, its body, and all child sections; with `False` removes only the heading and its direct body, promoting children. Returns `"ok"`.

Examples

A short worked session against a file docs/guide.md whose top-level heading is User Guide:

1. Inspect the structure

get_index("docs/guide.md")

Returns a nested tree:

{
  "sections": [
    {
      "heading": "User Guide",
      "level": 1,
      "path": "User Guide",
      "children": [
        {
          "heading": "Getting Started",
          "level": 2,
          "path": "User Guide.Getting Started",
          "children": []
        },
        {
          "heading": "Configuration",
          "level": 2,
          "path": "User Guide.Configuration",
          "children": []
        }
      ]
    }
  ]
}

2. Read a section

get_section("docs/guide.md", "User Guide.Getting Started")

Returns the raw Markdown text of that section (heading line + body).

3. Preview a change

patch_section("docs/guide.md", "User Guide.Configuration", "Set `debug: true` in `config.yaml`.")

Returns a unified diff showing exactly what would change — nothing is written yet.

4. Apply the change

replace_section("docs/guide.md", "User Guide.Configuration", "Set `debug: true` in `config.yaml`.")

Returns "ok". The file is updated; the heading line is preserved unchanged.

5. Add a new section

add_section("docs/guide.md", "## Troubleshooting", "See the FAQ.", after="User Guide.Configuration")

Returns "ok". The new ## Troubleshooting section is inserted immediately after ## Configuration.

6. Find sections mentioning a term

search_sections("docs/guide.md", "debug")

Returns:

[
  {
    "path": "User Guide.Configuration",
    "matches": [
      {"line": 18, "text": "Set `debug: true` in `config.yaml`."}
    ]
  }
]

Development

Requirements: Python 3.11+

Install the package with dev dependencies:

pip install -e ".[dev]"

Run the test suite:

pytest

Set up and run pre-commit hooks (ruff + mypy):

pre-commit install
pre-commit run --all-files

Available Tools

7 tools

add_sectionA

Insert a new section into a Markdown file.

heading must start with 1–6 '#' characters followed by a space, e.g. "## New Section". content is the body text (no heading line). Placement: exactly one of under, before, after may be set, or all None to append.

under: insert as the last child of the named section
before: insert immediately before the named section
after: insert immediately after the named section (and all its children) Returns "ok" on success.

ParametersJSON Schema

Name	Required	Description	Default
`after`	No
`under`	No
`before`	No
`content`	Yes
`heading`	Yes
`file_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

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.

delete_sectionA

Delete a section from a Markdown file.

With include_children=True (default): deletes the heading, its body, and all child sections. With include_children=False: deletes only the heading and its own body; child sections are promoted. Returns "ok" on success.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`file_path`	Yes
`include_children`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

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.

get_indexA

Return the section index of a Markdown file as a nested tree.

Each node: {"heading": str, "level": int, "path": str, "children": [...]} The "path" field is the dot-separated address used by all other tools. Literal dots in heading text are represented as . in path strings.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

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.

get_sectionA

Return the heading line(s) and body of the section at path.

path is a dot-separated heading path, e.g. "My README.Installation.Prerequisites". Matching is case-insensitive. Returns the raw Markdown text of the section.

depth controls how many levels of child sections are included:

None (default): return the section and all descendants
0: return the heading and its own body only (no child sections)
1: heading + own body + immediate children
2: heading + own body + children + grandchildren etc.

Raises an error string if the path does not exist.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`depth`	No
`file_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

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.

patch_sectionA

Return a unified diff of what replace_section would do, without writing.

Useful for previewing changes before committing them. Returns the unified diff as a string (empty string if no changes).

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`file_path`	Yes
`new_content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

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.

replace_sectionA

Replace the body of a section, preserving its heading line.

The heading line is kept unchanged; only the body text is replaced. Returns "ok" on success.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`file_path`	Yes
`new_content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

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.

search_sectionsA

Search all section bodies for lines matching query (regex).

Returns a list of match objects — one per section that contains at least one hit — in file order:

[
  {
    "path": "Root.Child",
    "matches": [
      {"line": 12, "text": "...the matching line text..."},
      ...
    ]
  },
  ...
]

line is the 1-based line number within the file. Only each section's own body is searched (not its children), so results are never duplicated across parent and child sections. 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. query is a Python regex; raises an error string if the pattern is invalid.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`file_path`	Yes
`case_sensitive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.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.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
Agentage Memory
io.agentage
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Knowledge & Memory File Systems
2
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
hjarni AOAuth
com.hjarni
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Note Taking Workplace & Productivity
3

Related MCP Servers

pure-admin-docs-mcp
Documentation Access Knowledge & Memory
Hwacc
F
license
Not graded
quality
D
maintenance
MCP server that syncs Markdown docs from a GitHub repository and provides search, reading, and listing capabilities for AI agents.
Updated 6 months ago (2026-03-03 17:14 UTC)
mnema
Knowledge & Memory RAG Systems File Systems
Ray0907
A
license
Not graded
quality
B
maintenance
Provides a file-first personal memory layer for AI agents, enabling them to store and retrieve memories as markdown files with an SQLite index. The MCP server offers read-only search by default, with optional write tools for manual memory addition and conflict resolution.
Updated a month ago (2026-08-04 09:51 UTC)
11
MIT
basic-memory-mcp
Note Taking Knowledge & Memory File Systems
garland3
A
license
A
quality
B
maintenance
An MCP server that gives AI models a persistent notebook backed by a folder of Markdown files, with tools to discover, read, write, edit, and delete notes.
Updated 8 days ago (2026-08-26 23:10 UTC)
9
MIT
memoryadapter
RAG Systems Knowledge & Memory Version Control
kerfuffledev
A
license
Not graded
quality
A
maintenance
An MCP server that enables verified agents to retrieve from, propose changes to, and share capabilities around a human-owned Markdown/Git knowledge base, ensuring curation, exact-byte approval, and Git-based promotion.
Updated a month ago (2026-08-07 20:18 UTC)
MIT

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

md-mcp

Overview

Installation

pip

uv

Connecting to opencode / Claude Desktop

opencode (opencode.json / opencode.jsonc)

Claude Desktop (claude_desktop_config.json)

Dot-path addressing

Tool reference

Examples

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

opencode (`opencode.json` / `opencode.jsonc`)

Claude Desktop (`claude_desktop_config.json`)