How do I use tooldash-mcp?

1. Click on "Deploy 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., "@tooldash-mcp Merge these two PDFs and save the result to my Desktop" 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.

tooldash-mcp

by LassiB999

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

ToolDash MCP

Offline PDF and text tools for AI agents. An MCP server that lets Claude Desktop, Cursor, VS Code and any other MCP client merge PDFs, pull out pages, inspect documents and clean up text — entirely on your own machine.

No upload. No API key. No account. No network call of any kind: the PDF work is done locally by pdf-lib, so a confidential contract never leaves your laptop.

Tools

Tool	What it does	Writes files?
`pdf_info`	Page count, per-page dimensions and metadata of a PDF	No
`merge_pdfs`	Combine two or more PDFs into one, in the given order	Yes
`extract_pdf_pages`	Copy a page selection (`"1-3,7,10-12"`) into a new PDF	Yes
`clean_text`	Collapse whitespace, strip invisible characters, normalize punctuation, optionally remove URLs	No

The two tools that write files refuse to replace an existing file unless you pass overwrite: true, so an agent retrying a call cannot quietly destroy a document.

Related MCP server: Doc MCP Server

Requirements

Node.js 20 or newer.

Install

No install step — your MCP client runs it on demand with npx. Add the server to your client's config and restart it.

Claude Desktop

Edit claude_desktop_config.json:

macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
Windows — %APPDATA%\Claude\claude_desktop_config.json
Linux — ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "tooldash": {
      "command": "npx",
      "args": ["-y", "tooldash-mcp"]
    }
  }
}

Restart Claude Desktop. The tools appear under the tools icon in the chat box.

Cursor

Create .cursor/mcp.json in your project (or ~/.cursor/mcp.json for every project):

{
  "mcpServers": {
    "tooldash": {
      "command": "npx",
      "args": ["-y", "tooldash-mcp"]
    }
  }
}

Then enable the server under Settings → MCP.

VS Code (GitHub Copilot agent mode)

Create .vscode/mcp.json:

{
  "servers": {
    "tooldash": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "tooldash-mcp"]
    }
  }
}

Running from a clone

git clone https://github.com/LassiB999/tooldash-mcp.git
cd tooldash-mcp
npm install
npm test

Then point your client at node /absolute/path/to/tooldash-mcp/server.js instead of npx.

Paths may be absolute, relative to the client's working directory, or start with ~. Surrounding quotes are stripped, so a path pasted as "/home/you/file.pdf" still works.

Restricting file access

The server reads and writes wherever your user account can. To confine it to one directory, set TOOLDASH_MCP_ROOT — any path outside it is refused with a clear error:

{
  "mcpServers": {
    "tooldash": {
      "command": "npx",
      "args": ["-y", "tooldash-mcp"],
      "env": { "TOOLDASH_MCP_ROOT": "/home/you/Documents/pdfs" }
    }
  }
}

Usage examples

Ask your assistant in plain language — "merge these two PDFs and put the result on my desktop" — and it will fill in the calls below. The raw JSON is here for testing.

`pdf_info`

{ "path": "/home/you/Documents/report.pdf" }

report.pdf: 12 page(s), 248.3 KB. Title: "Q3 Report".

`merge_pdfs`

{
  "inputPaths": ["/home/you/Documents/cover.pdf", "/home/you/Documents/report.pdf"],
  "outputPath": "/home/you/Documents/final.pdf",
  "overwrite": false
}

`extract_pdf_pages`

Pages are 1-based. Order is preserved, so "3,1-2" gives you page 3 first. A descending range like "5-1" reverses those pages.

{
  "inputPath": "/home/you/Documents/report.pdf",
  "pages": "1-3,7,10-12",
  "outputPath": "/home/you/Documents/excerpt.pdf"
}

`clean_text`

{
  "text": "Hello   world  \r\n\r\n\r\n\r\nSecond   line   ",
  "collapseBlankLines": true,
  "normalizeQuotes": false,
  "removeUrls": false
}

removeUrls strips every http/https URL. The server is offline, so it cannot tell a working link from a dead one — it does not pretend to.

How it handles failure

Bad input comes back as a readable error result the model can act on, never as a crash: a missing file, a password-protected PDF, a page number past the end of the document, or an output path that already exists each produce a message saying what to do next. The server keeps running.

Diagnostics go to stderr only. stdout carries protocol frames and nothing else — the tests would fail if anything leaked into it.

Development

npm test                # 15 end-to-end tests: a real MCP client over stdio, on real PDFs
npm run inspect         # open the MCP Inspector against this server

Powered by ToolDash

ToolDash is a set of free, browser-based utilities — PDF, text, image, colour, developer and calculator tools — that run entirely in your tab with nothing uploaded. This server brings the same idea to your editor.

tooldash.app — the full tool collection
PDF Factory — the browser PDF studio these PDF tools mirror
Al-Katib — Arabic keyboard and writing pad

License

MIT

Available Tools

4 tools

clean_textClean and normalize textA

Read-onlyIdempotent

Normalize messy text: collapse repeated spaces, strip trailing whitespace and invisible characters, unify line endings, and optionally collapse blank lines, convert smart punctuation to ASCII, or remove URLs. Runs entirely offline — nothing is uploaded and no network call is made.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The text to clean.
`removeUrls`	No	Strip every http/https URL from the text. Note: this removes ALL URLs — the server is offline and cannot tell a working link from a dead one.
`normalizeQuotes`	No	Replace curly quotes, en/em dashes and ellipsis characters with their ASCII equivalents.
`collapseBlankLines`	No	Collapse runs of two or more blank lines into a single blank line.

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The cleaned text.
`after`	Yes
`before`	Yes
`changed`	Yes	False when the input was already clean.
`removedUrls`	Yes	URLs stripped, when removeUrls was set.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond this: it states the tool is fully offline, makes no network request, and clarifies that removeUrls strips every URL indiscriminately because the server cannot distinguish live from dead links. This gives agents an accurate mental model of side effects and limitations.

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 long, front-loaded with the tool's core operations, and has no filler. The privacy/offline statement earns its place as an important behavioral constraint. Every clause contributes either operational scope or a safety guarantee.

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?

The definition is complete for the tool's complexity: all four parameters are documented in the schema, an output schema exists, and annotations cover read-only, idempotent, and non-destructive behavior. The description adds the offline guarantee and optional transformations. No critical behavioral or usage gap remains for an agent to select and invoke this tool correctly.

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?

The input schema covers all parameters with descriptions, and the context signal reports 100% schema description coverage, so the baseline is 3. The description adds value by summarizing the parameter effects in behavior-oriented terms (e.g., 'collapse repeated spaces,' 'convert smart punctuation to ASCII,' 'remove URLs') and noting which transformations are default versus optional. This helps an agent anticipate the tool's default behavior without opening 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?

The description opens with 'Normalize messy text' and enumerates specific operations: collapsing repeated spaces, stripping invisible characters, unifying line endings, and optional transformations. This clearly distinguishes clean_text from its PDF-related siblings (pdf_info, merge_pdfs, extract_pdf_pages), which operate on binary documents rather than raw text.

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 clearly implies when to use the tool: whenever raw, messy text needs normalization before further processing. It also adds a relevant constraint by emphasizing the tool runs entirely offline, which is useful context for privacy-sensitive data. However, it does not explicitly state when not to use it or name alternative text-processing tools, though none are provided among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

extract_pdf_pagesExtract PDF pagesA

Destructive

Write a selection of pages from a local PDF into a new file, leaving the original untouched. Pages are 1-based and may be given as a list and ranges, e.g. "1-3,7,10-12". Order is preserved, so "3,1" produces a two-page file in that order.

ParametersJSON Schema

Name	Required	Description
`pages`	Yes	1-based page selection, e.g. "1-3,7,10-12". Ranges may descend ("5-1").
`inputPath`	Yes	The PDF to take pages from. Absolute, or relative to the client's working directory.
`overwrite`	No	Replace outputPath if a file is already there.
`outputPath`	Yes	Where to write the extracted pages. Absolute, or relative to the client's working directory.

Output Schema

ParametersJSON Schema

Name	Required	Description
`pageCount`	Yes
`sizeBytes`	Yes
`outputPath`	Yes
`sourcePages`	Yes	The 1-based source pages, in output order.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag this as non-read-only and destructive, and the description adds useful behavioral detail: the original PDF is left untouched, pages are 1-based, and order is preserved. The overwrite behavior is not repeated in the description, but the overwrite parameter schema and destructiveHint annotation already cover that risk.

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 sentences with a front-loaded purpose, a compact example of page syntax, and no filler. Every clause contributes: local file, original untouched, 1-based indexing, list/range support, and order preservation.

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?

For a 4-parameter tool with an output schema and full schema descriptions, the description covers the essential operation, page-selection semantics, and non-destruction of the source. It does not cover edge cases such as invalid page numbers, but the schema and annotations carry the rest of the contract.

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 coverage is 100% for all four parameters, so the baseline is 3. The description adds value beyond the schema by clarifying that page order is preserved, so '3,1' produces a two-page file in that order—a non-obvious behavioral detail for the pages parameter.

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 opens with a specific verb and resource: 'Write a selection of pages from a local PDF into a new file'. It clearly distinguishes the tool from siblings like merge_pdfs (combining PDFs) and pdf_info (inspecting PDFs) by describing the exact extraction operation.

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 gives clear context: use this tool when you need selected pages from a local PDF written to an output file. It does not explicitly name when-not conditions or alternatives, so it stops short of the top tier, but the intended use is unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

merge_pdfsMerge PDFsA

Destructive

Combine two or more local PDFs into a single file, in the order given. Runs entirely on this machine with pdf-lib — nothing is uploaded and no URL is fetched. Refuses to overwrite an existing output unless overwrite is true.

ParametersJSON Schema

Name	Required	Description
`overwrite`	No	Replace outputPath if a file is already there.
`inputPaths`	Yes	The PDFs to merge, in the order they should appear in the result.
`outputPath`	Yes	Where to write the merged PDF. Absolute, or relative to the client's working directory.

Output Schema

ParametersJSON Schema

Name	Required	Description
`sources`	Yes
`pageCount`	Yes
`sizeBytes`	Yes
`outputPath`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses important behavioral traits: the operation runs locally using pdf-lib, nothing is uploaded, no URL is fetched, and existing output files are preserved unless overwrite is true. This gives an agent meaningful safety and side-effect information that annotations alone do not provide.

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 compact and front-loaded: the primary action is stated first, followed by local-execution context and overwrite safety. Every sentence contributes useful information without repeating schema details.

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 output schema and annotations, the description covers what an agent needs to call the tool correctly: input order, local execution, no upload, and protected overwrite behavior. It is sufficiently complete for a moderately simple file-merging tool.

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 coverage is 100%, so the schema already documents all three parameters. The description adds value by clarifying that paths refer to local files, that no URL is fetched, and that overwrite behavior is guarded. Since it enriches the schema's parameter meaning with local-only semantics, it earns credit above the baseline.

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 opens with a clear verb and resource: 'Combine two or more local PDFs into a single file, in the order given.' It unambiguously describes what the tool does and distinguishes it from siblings like pdf_info, extract_pdf_pages, and clean_text, all of which have different purposes.

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 clearly states the intended use case: merging multiple local PDFs into one file. It also provides relevant context such as local execution and order preservation. It does not explicitly name alternatives or say when not to use the tool, but the core usage context is clear and the sibling tools are sufficiently distinct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pdf_infoInspect a PDFA

Read-onlyIdempotent

Report the page count, per-page dimensions and document metadata of a local PDF. Read-only: the file is never modified. Call this before merging or extracting so page numbers are known to be valid.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	The PDF to inspect. Absolute, or relative to the client's working directory.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`path`	Yes
`pages`	Yes
`title`	Yes
`author`	Yes
`pageCount`	Yes
`sizeBytes`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description reinforces this with 'the file is never modified,' which is useful but largely redundant. It adds a hint that page numbers are reliable for later operations, but does not go much beyond 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?

Two tightly written sentences. The first states the output and scope, the second states safety and usage timing. No filler, and the most important information is front-loaded.

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?

For a simple read-only inspection tool with a single well-documented parameter and an output schema, the description is sufficient. It explains the tool's purpose, safety, and when to call it. It does not discuss error behavior, but that is a minor gap given the overall simplicity and available structured metadata.

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 'path' parameter is already documented in the schema. The description adds the contextual phrase 'of a local PDF,' which lightly reinforces that the path must point to a local file, but it does not add substantive meaning 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?

The description states a specific verb ('Report') and a precise resource scope: page count, per-page dimensions, and metadata of a local PDF. It distinguishes itself from the sibling merge/extract tools by focusing on inspection, so an agent can clearly tell it apart.

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 explicitly advises calling the tool 'before merging or extracting' to validate page numbers, giving clear context for when it should be used. It does not explicitly name alternative tools or state when not to use it, but the instruction is direct and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.2Aug 29, 2026
- First observedclean_text
- First observedextract_pdf_pages
- First observedmerge_pdfs
- First observedpdf_info

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-29 19:20 across 4 tools

Disambiguation5/5

Each tool targets a distinct action: reading PDF metadata, merging PDFs, extracting pages, and normalizing text. There is no overlap or boundary ambiguity, so an agent can select the right tool confidently.

Naming Consistency4/5

Three tools follow a clear verb_object pattern (merge_pdfs, extract_pdf_pages, clean_text), while pdf_info uses noun_noun rather than a verb-first form. This is a minor inconsistency in an otherwise predictable and readable naming scheme.

Tool Count4/5

Four tools is a reasonable size for a focused utility server, and none of the tools feel redundant. The mix of PDF operations with a standalone text cleaner makes the scope slightly broad, but the count itself is not too thin or bloated.

Completeness4/5

The PDF workflow covers the key needs of inspection, merging, and page extraction, while clean_text works as a self-contained text utility. Missing operations like PDF text extraction, rotation, or encryption are plausible additions, but agents can complete core merge, extract, and cleanup tasks without dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

pdf-merge-split-stamp-extract-pages A
io.github.theluckystrike
Merge, split, extract, rotate, reorder and stamp PDF pages from your AI chat, all offline.
File Systems Workplace & Productivity
151
pdf-tools A
com.pdfia
Free PDF tools for AI agents: merge, split, rotate, watermark, page numbers, metadata, flatten.
Developer Tools
101
docweave-mcp A
io.github.NicolasMartalog
Generate and read PDFs for AI agents: a generate_pdf and a read_pdf tool, priced per document.
Workplace & Productivity Developer Tools
23
Razi Tools A
io.github.razikallayi
PDF, image, video, OCR, screenshot, SQL, QR and text tools for agents. No API key, no signup.
Image & Video Processing Databases
281

Related MCP Servers

PDF Document MCP Server
File Systems Text Summarization Documentation Access
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
A local document processing toolkit for AI agents that extracts text, converts PDFs to Markdown, merges files, extracts tables, and summarizes documents without external API dependencies.
Updated 16 days ago (2026-09-04 12:42 UTC)
4 npm
46 PyPI
MIT
Doc MCP Server
Workplace & Productivity File Systems
ceeyang-ai
A
license
B
quality
C
maintenance
Enables AI agents to generate PDFs from Markdown or URLs, extract text, merge documents, and perform text conversions via the Model Context Protocol.
Updated 3 months ago (2026-06-18 19:20 UTC)
8
1
MIT
pdf-agent-toolkit-mcp
File Systems Workplace & Productivity
abhishektangudu
F
license
Not graded
quality
A
maintenance
Enables AI agents to perform comprehensive PDF operations locally, including compression, text extraction, PII redaction, page organization, splitting, merging, watermarking, creation, and form filling, all without cloud uploads.
Updated 25 days ago (2026-08-26 20:38 UTC)
11 npm
-
MCP_Documents
Documentation Access Research & Data
azzindani
F
license
B
quality
A
maintenance
Enables local, offline document extraction and manipulation—PDF first but also HTML, DOCX, XLSX, PPTX, EML, EPUB, Markdown, and plain text—through tools for probing, locating, extracting, converting, assembling, OCR, protecting, and redacting documents, with nothing leaving the machine.
Updated 14 days ago (2026-09-07 05:39 UTC)
7
-