mcp-agent-docparser
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOCPARSER_LOGS_DIR | No | Rotating DEBUG logs (5×5 MB) | logs |
| DOCPARSER_RECEIPTS | No | Path to the receipts registry | receipts.json |
| DOCPARSER_OUTPUT_DIR | No | Where emitted `.md` files go | doc_output |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_datetimeA | Return the current local and UTC date/time in ISO 8601 format. |
| receipt_listA | List all registered receipts with key, language, and last-fetch status. |
| receipt_showB | Show the full JSON of a single receipt by its key. |
| receipt_addA | Create a new receipt (or replace an existing one). Required: key, name, language, urls, selectors. Optional: strip_tags, section, js_render, markdown_passthrough, notes, code_language. Validates before writing; returns validation errors if the receipt is malformed.
|
| receipt_editA | Patch specific fields of an existing receipt.
|
| receipt_deleteA | Delete a receipt by key. Returns false if the key does not exist. |
| receipt_reloadA | Re-read receipts.json from disk (pick up external edits). |
| doc_parseA | Parse a saved receipt: fetch all its URLs, extract the content, and write a timestamped .md file into the output directory. Returns the emitted filename plus a per-URL character count and the full rendered markdown. With dry_run=true, reports what would be fetched without making any network requests. |
| doc_parse_urlA | Parse an arbitrary URL using an existing receipt as a template for its selectors/strip_tags/language. Does not persist the result as a receipt. Returns the emitted filename and the rendered markdown. |
| doc_probeA | Probe a documentation page to discover its selector structure. Fetches the URL statically and reports which candidate CSS selectors match, the H2 section structure, and sample internal links. The findings' best_selector can be used to create a new receipt. |
| doc_probe_jsA | Probe a JS-rendered documentation page via headless Chromium. Same selector report as doc_probe, but over the rendered DOM, plus detection of a 'Copy as Markdown' button (a saved receipt then pre-fills js_render and markdown_passthrough). Requires Playwright Chromium installed. |
| doc_outputA | List the extracted .md files currently in the output directory. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
The receipt CRUD, parse, and probe tools are clearly separated by resource and action. The only potentially confusable pair is doc_parse vs doc_parse_url, but their descriptions distinguish saved-receipt parsing from arbitrary-URL parsing; get_current_datetime is unrelated but unambiguous.
Most tools follow an object_verb pattern such as receipt_list, receipt_add, doc_parse, and doc_probe, making the set predictable. get_current_datetime breaks the pattern, and doc_output is noun-styled, but the prefix grouping keeps names readable and consistent overall.
Twelve tools is a reasonable, well-scoped count for managing receipt configurations, parsing documentation, probing selectors, and listing outputs. The get_current_datetime tool feels slightly out of place, but the set is not bloated or thin.
The receipt lifecycle is fully covered with list/show/add/edit/delete/reload, and the parse/probe workflow handles both static and JS-rendered pages plus dry runs. A minor gap is the inability to read the contents of already-generated output files, since doc_output only lists filenames.