This server gives MCP-compatible assistants Carve parsing, linting, formatting, rendering, and migration capabilities, with optional workspace file access.
carve_lint: Check Carve source for structured author-facing warnings and silent degradation.
carve_format: Produce canonical Carve output and report any lossy raw-format nodes.
carve_render: Render Carve to HTML, Markdown, plain text, or ANSI, with presets and advanced options like heading-ID behavior, smart typography, and extensions.
carve_parse: Return a resolved, position-aware interchange AST.
carve_migrate: Convert HTML, Markdown, or Djot into Carve with fidelity diagnostics and explicit Markdown dialect switches.
carve_workspace_info: List configured root indexes without exposing host paths.
carve_read_file: Read allowed text files from configured workspace roots.
carve_write_file: Write files (opt-in) with dry-run mode, root confinement, mode preservation, and optimistic concurrency protection via SHA-256.
Resources: Access carve://guide, carve://rules, per-rule carve://rules/{ruleId}, and lint-rule explanations via carve://lint-rules/{ruleName}.
Deployment: Run over stdio or HTTP with security hardening (token, host allowlist, rate limits, request limits) and an unauthenticated /health endpoint.
Allows migration of Markdown documents to Carve with fidelity diagnostics and rendering of Carve documents as Markdown.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@carve-mcp Lint this Carve document: ::heading[Welcome]"
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.
Give MCP-compatible assistants the same Carve parser, linter, formatter, and renderers used by the JavaScript implementation. Filesystem access is absent by default and can be enabled for explicitly configured document roots.
carve_lint checks a document and returns precise, structured warnings.
carve_format produces canonical Carve and reports rendering losses.
carve_render renders HTML, Markdown, plain text, or ANSI.
carve_parse returns the resolved, position-aware interchange AST.
carve_migrate converts HTML, Markdown, or Djot and reports migration fidelity.
carve_render supports default, portable, and HTML-only static-html
presets. The portable preset lowercases heading IDs and transliterates where it
can. Advanced callers can choose heading-ID behavior, loss policy, smart
typography, and the autolink, semantic-spans, or wikilinks extensions.
carve_migrate exposes Markdown dialect switches explicitly, so migration does
not invent constructs the source format did not enable.
Raw HTML passthrough is disabled by default because MCP inputs are untrusted.
Callers handling trusted documents can opt in with allowRawHtml; dangerous URL
sanitization remains enabled unless explicitly disabled.
All tools accept source text directly. Inputs are limited to 1 MB, and no tool reads or writes files unless a workspace root is configured at startup.
By default the server has no filesystem access. To opt into workspace reads, configure one or more roots at startup:
node dist/index.js --root /absolute/project/pathcarve_workspace_info lists the root indexes used by carve_read_file without
exposing host paths. Reads are limited to common text-document extensions and
exclude hidden paths and dependency directories.
Add --allow-write to register carve_write_file. Writes default to dry runs,
stay inside canonicalized roots, preserve existing file modes, and require the
previously read SHA-256 when overwriting a file. This detects concurrent
changes. MCP's newer protocol no longer asks clients for roots, so startup
configuration keeps the permission boundary explicit across protocol versions.
Related MCP server: mcp-server-markdown
carve://guide is a concise authoring quick start.
carve://rules explains the normative rule categories.
carve://rules/{ruleId} looks up a stable normative CARVE-* rule ID, such as
carve://rules/CARVE-P0-001.
carve://lint-rules/{ruleName} explains a stable diagnostic name returned by
carve_lint.
The resources identify the Carve version and link to the complete documentation
when a reader needs normative detail. Lint diagnostic names are a separate
namespace and are returned with their explanations directly by carve_lint.
Node.js 20 or newer is required.
npm install
npm run build
node dist/index.jsConfigure an MCP client to launch the server over stdio:
{
"mcpServers": {
"carve": {
"command": "node",
"args": ["/absolute/path/to/carve-mcp/dist/index.js"]
}
}
}The intended published command is npx -y @markup-carve/carve-mcp; use the
local command until the package has been released.
The Rust server is intended for native distribution and embedding. It uses
carve-lang directly and currently exposes the five source-based tool names
over stdio:
cargo run --manifest-path rust/Cargo.tomlChoose the TypeScript server for the complete, stable contract, HTTP transport, resources, and guarded workspace operations. The Rust binary is a preview until the shared conformance fixtures cover every option and result shape. It disables raw HTML by default, but advanced render options, loss reports, migration reports, platform-specific linting, and offset normalization are not yet at parity.
Stdio remains the default. For local HTTP development:
node dist/index.js --http --port=3000The default bind is 127.0.0.1:3000; --host value and --port value forms
are also accepted.
The MCP endpoint is /mcp and the health endpoint is /health. Non-loopback
binds require a bearer token supplied through the environment, never a command
line argument:
CARVE_MCP_TOKEN='replace-with-a-long-random-secret' \
CARVE_MCP_ALLOWED_HOSTS='mcp.example.com' \
node dist/index.js --http --host=0.0.0.0 --port=3000CARVE_MCP_ALLOWED_HOSTS is a comma-separated hostname allowlist (without
ports). HTTP mode validates host and origin headers, limits request bodies to 7
MB, allows 60 MCP requests per minute per socket peer, caps concurrent MCP
requests at 32, and applies request, header, and keep-alive timeouts. The health
endpoint is intentionally unauthenticated for deployment probes. Workspace
writes over HTTP require a token even on loopback. Put public deployments
behind TLS; the built-in listener is plain HTTP.
When a reverse proxy terminates TLS, configure equivalent client-aware rate
limits there because the built-in listener sees the proxy as the socket peer.
npm run check
npm test
npm run buildThis project is licensed under the MIT License.
Format Carve source canonically and report any lossy raw-format nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Document source (maximum 1000000 UTF-8 bytes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows the operation is safe and non-mutating. The description adds that it reports lossy raw-format nodes, which is useful, but it doesn't clarify what constitutes a lossy node or what the report looks like. This is acceptable given the annotations but not richly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, and free of redundant wording. Every component earns its place: the verb, the resource, the mode ('canonically'), and the reporting behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool this is mostly sufficient: it names the action and the report. However, there is no output schema, so the description should more explicitly define the 'report' output format. It also doesn't mention error behavior or what 'canonical' means in practice, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a description for the single 'source' parameter, so the description doesn't need to repeat it. The tool description adds no extra parameter meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Format Carve source canonically.' It also indicates a distinct outcome—reporting lossy raw-format nodes—which separates it from parsing, linting, rendering, or migrating. It doesn't explicitly name sibling tools, but the verb 'Format' and the unique report clause make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for canonical formatting of Carve source, so an agent could infer when it applies. However, there is no explicit guidance on when to choose this over carve_lint, carve_render, or carve_migrate, nor any 'when not to use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Carve source for author-facing problems and silent degradation.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Document source (maximum 1000000 UTF-8 bytes) | |
| platforms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the linter detects ('author-facing problems and silent degradation'), but it does not disclose return format, error behavior, or whether any action is taken. The read-only annotation mitigates the need for mutation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that is front-loaded with the action ('Check') and the resource ('Carve source'). Every word contributes to the purpose; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and read-only annotations, the description is mostly sufficient for a simple linting operation. The main gaps are the unexplained `platforms` parameter and the fact that the return value (e.g., diagnostics list) is not specified. An agent could infer behavior from the verb 'Check', but it is not fully explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description adds no parameter-level meaning. The `source` parameter is described in the schema, but `platforms` has no schema description and the tool description also does not explain what `platforms` controls. With 50% schema coverage, the description should compensate for the undocumented `platforms` parameter, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' with the resource 'Carve source' and specifies the goal: detecting 'author-facing problems and silent degradation.' This clearly distinguishes it from siblings carve_format, carve_render, carve_parse, and carve_migrate, each implying a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the linting/validation tool for Carve source, but it does not explicitly state when to use it over siblings or when not to use it. There are no exclusions or alternative routing; the agent must infer from the name and the verb 'Check' that this is the validation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Migrate HTML, Markdown, or Djot source to Carve with fidelity diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | ||
| source | Yes | Document source (maximum 1000000 UTF-8 bytes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive safety profile. The description adds value by disclosing that conversion produces 'fidelity diagnostics', which tells the agent to expect quality/compatibility feedback beyond the converted output. This is meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one front-loaded, information-dense sentence. Every phrase earns its place: the migration action, the supported formats, the target, and the diagnostics behavior. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with read-only annotations, the description is mostly sufficient, but with no output schema it does not clarify what the result looks like beyond 'fidelity diagnostics'. It also does not mention edge cases, formatting details, or whether output is returned as text or a structured object. A bit more return-shape context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'source' has a description with size limits, and 'format' has an enum but no description. The description restates the format options in prose but does not add new parameter meaning, such as format detection, normalization behavior, or how source content is interpreted. This is adequate but not compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Migrate'), a clear resource ('HTML, Markdown, or Djot source'), and a target format ('Carve'). It also adds a distinctive behavioral detail ('with fidelity diagnostics') that separates it from obvious siblings like carve_parse or carve_render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you have HTML, Markdown, or Djot source and want to convert it to Carve. It does not explicitly name sibling tools or exclusion conditions, but the migration-focused wording sufficiently distinguishes it from lint, format, render, and parse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse and resolve Carve into its position-aware interchange AST.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Document source (maximum 1000000 UTF-8 bytes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful output context by specifying that the result is a 'position-aware' AST, but it does not disclose behavior around errors, resolution failures, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-formed sentence that immediately states the operation, the input, and the output. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and annotations covering safety, and the description tells the agent exactly what the tool produces. The lack of an output schema makes the 'position-aware interchange AST' mention valuable, though more detail about resolution behavior or error conditions would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single 'source' parameter is already documented as 'Document source (maximum 1000000 UTF-8 bytes)'. The description does not add meaningful parameter-level details beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Parse and resolve') and a specific resource ('Carve'), and names the exact output ('position-aware interchange AST'). This clearly distinguishes it from the sibling tools carve_lint, carve_format, carve_render, and carve_migrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states that this tool is for parsing and resolving Carve into an AST, which gives the agent a clear context for when it should be used. It does not explicitly name alternatives or exclusions, but the operation is distinct enough from lint, format, render, and migrate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render Carve to HTML, Markdown, plain text, or ANSI terminal text, with loss reporting.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Document source (maximum 1000000 UTF-8 bytes) | |
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. The phrase 'with loss reporting' adds a behavioral detail, but it is vague and does not clarify what the loss report contains, how it is returned, or whether it accompanies the rendered output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the core purpose, output variants, and an additional behavioral note. Every word earns its place; there is no repetition of schema properties or annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, and annotations cover safety, but there is no output schema. The description does not explain the expected return value or the semantics of the loss report, leaving an agent uncertain about what the invocation will actually produce beyond the chosen format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description carries some of the burden. It repeats the target enum values and clarifies that the source is a Carve document, but it does not add meaningful detail beyond the schema for 'source' or explain constraints/pitfalls of each target format. The description is adequate but not compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Render Carve') and enumerates the exact output formats: HTML, Markdown, plain text, and ANSI terminal text. This clearly distinguishes the tool from its siblings (carve_lint, carve_format, carve_parse, carve_migrate) by focusing on conversion/rendering rather than analysis or mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like carve_parse or carve_format. The usage is only implied by the tool's name and the listed output formats; there is no mention of when rendering is appropriate or inappropriate, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0carve_formatcarve_lintcarve_migratecarve_parsecarve_renderEach tool targets a distinct stage of Carve processing: linting for problems, canonical formatting, rendering to output formats, parsing to an AST, and migrating from other formats. No two tools have overlapping purposes.
All tool names follow a consistent carve_<verb> pattern, with the verbs clearly communicating the operation. This is a strong, predictable naming convention.
Five tools is well-scoped for a language-processing server. Each tool earns its place and covers a distinct operation without redundancy or bloat.
The tool set covers the core Carve workflow: migrate source in, parse to an AST, lint for issues, format canonically, and render to output formats. There are no obvious dead ends or missing essential operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Convert files, URLs, and documents to clean, AI-ready Markdown via MCP.
Generate PDF, Word (.docx) and PowerPoint (.pptx) documents from Markdown over MCP.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markup-carve/carve-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
