What can you do with this server?

Adeu is a DOCX ↔ LLM translation layer that lets AI agents read, edit, redline, sanitize, and validate Word documents using Track Changes, while also providing email and cloud integration tools. Document Reading * Read a DOCX file in full or outline mode, returning CriticMarkup-annotated text (tracked changes/comments inline) or a clean/accepted view, with pagination support. Document Editing * Apply batch edits including: search-and-replace (modify), accept/reject specific tracked changes by ID, reply to comments, and insert/delete table rows. * Accept all tracked changes and remove all comments in one operation to produce a clean final document. Document Comparison * Compare two DOCX files and generate a Unified Diff, against either clean/accepted states or raw CriticMarkup text. Document Sanitization * Strip metadata (author names, rsids, template paths, hidden text, etc.) before sharing externally. Supports three modes: full scrub, keep-markup (preserves redlines), or baseline (recomputes a clean delta against an original). Produces an audit report of everything removed. Document Validation * Asynchronously validate one or more documents (DOCX/PDF) for inconsistencies, contradictions, and risks via Adeu Cloud; poll for results using a task ID. Email Integration (Adeu Cloud) * Search a live inbox with filters (sender, subject, date, unread status, attachments, folder), fetch full email bodies, and auto-download attachments. * Create new email drafts or reply to existing threads in Outlook/Gmail, with support for local file attachments and Markdown-formatted bodies. Local Desktop * Open any local file in its native desktop application (e.g., a DOCX in Microsoft Word). Adeu Cloud Authentication * Log in via a browser-based flow or log out and clear the API key from the OS Keychain.

Which integrations are available for this server?

Provides integration with LangChain through the langchain-adeu package, enabling AI agents to use Adeu's document manipulation tools within LangChain workflows.

de en es ja ko ru zh

adeu

by dealfluence

Overview Schema Related Servers Score Discussions

Python

Hybrid

Adeu: Track Changes for the LLM era

GitHub Repo stars PyPI version npm version Downloads MCP Compatible Smithery License: MIT

LLMs speak Markdown; reviewers speak "Track Changes."

Adeu is a docx ↔ LLM translator: a Model Context Protocol (MCP) server (Python and Node.js implementations) and accompanying SDKs that act as a Virtual DOM for Microsoft Word. It provides a two-way abstraction layer that lets AI agents freely edit document text without destroying the underlying formatting or complex DOCX XML.

While standard libraries like python-docx excel at generating documents from scratch, they fail at non-destructive redlining. Adeu solves this by translating .docx files into a token-efficient Markdown representation. This frees AI agents to focus entirely on document semantics instead of wasting tokens wrestling with OpenXML.

Adeu acts as an intelligent proxy, processing AI edits as safe, atomic transactions:

Read: Translates the document (from disk or live Word) into LLM-friendly CriticMarkup with a Semantic Appendix of defined terms, cross-references, and likely typos. The agent starts with semantic structure, not raw data.
Validate: Acts as a strict safety gate. It protects the document's integrity by automatically blocking ambiguous text matches or invalid structural changes before they touch the file.
Apply: Translates the AI's text edits into native Word Track Changes. Adeu handles the complex XML under the hood, ensuring existing layouts, fonts, and margin comments are perfectly preserved.

Built and maintained by the team at Adeu.

Installation

Adeu can be installed directly into AI assistants as an MCP server, used as a Claude Code plugin or Agent Skill, CLI tool, or used locally as a developer toolchain.

Claude Code (Plugin)

Adeu ships as a Claude Code plugin with a built-in agent skill that teaches Claude how to use the engine effectively. Inside Claude Code:

/plugin marketplace add dealfluence/adeu
/plugin install adeu-redlining@adeu-skills

For best results, also connect either the Node MCP server (npx -y @adeu/mcp-server) or the Python MCP server (uvx --from adeu adeu-server). The plugin works without an MCP server too — it falls back to driving the uvx adeu CLI via Bash.

Other Skills-Compatible Agents (Cursor, Windsurf, VS Code Copilot, etc.)

Adeu's redlining skill follows the open Agent Skills specification and works with any compatible agent:

npx skills add dealfluence/adeu

The skill installs to your agent's skills directory and activates automatically when you ask Claude to redline, edit, or review a .docx file.

Claude Desktop

You can install Adeu directly into Claude Desktop using the official extension package:

Download the latest Adeu.mcpb file from the GitHub Releases page.
Open Claude Desktop and navigate to Settings > Extensions.
Click Advanced settings and find the Extension Developer section.
Click Install Extension..., select the downloaded .mcpb file, and follow the prompts.

Gemini CLI

Adeu is available as a native Gemini CLI extension. To install:

gemini extensions install https://github.com/dealfluence/adeu

Other MCP Clients (Cursor, Windsurf, etc.)

For IDEs or clients that configure MCP servers via JSON, you can use either the Node.js or Python backend:

Node.js

{
  "mcpServers": {
    "adeu": {
      "command": "npx",
      "args": ["-y", "@adeu/mcp-server"]
    }
  }
}

Python (Required for Live MS Word integration on Windows)

{
  "mcpServers": {
    "adeu": {
      "command": "uvx",
      "args": ["--from", "adeu", "adeu-server"]
    }
  }
}

Smithery

To install Adeu using the Smithery package manager:

npx -y @smithery/cli install adeu --client claude

Related MCP server: mcp-server-docx

Agent Workflows

Adeu provides agents with specific tools to read, review, and edit documents safely.

MCP Apps UI: The read_docx tool supports the MCP Apps UI protocol. When an agent reads a document, Adeu dynamically renders a custom, interactive Markdown view directly inside the chat window.

Recommended Agent Prompt: You can guarantee the best behavioral results by adding this context to your agent's system prompt or project instructions:

Role: Document Specialist Tools:
read_docx(clean_view=True): Read the final "clean" version of the text to understand context. Use search_query and page filters to locate specific clauses without reading the whole document.
process_document_batch: Commit & Negotiate Mode. Apply a unified list of changes. Use type: "modify" for specific search-and-replace text edits (supports match_mode="all" and regex=True for bulk updates), and type: "accept", "reject", or "reply" to manage existing Track Changes and Comments by ID.
finalize_document: Pre-Send Scrub. Strip dangerous metadata, author names, and internal tracking IDs, lock the document (protection_mode="read_only"), and prepare it for distribution.

Live MS Word Integration

If you are running on Windows with Microsoft Word installed, Adeu can act as a real-time copilot, editing the active document right in front of you. This requires running the Python MCP server backend (see Developer Tools below).

Developer Tools (Python & TypeScript)

If you are building a legal-tech application, an automated pipeline, or want to use the local CLI, use our SDKs.

The Python CLI

The Python toolchain is managed via uv.

pip install uv
uv tool install adeu

# Extract clean text for RAG or prompting
adeu extract contract.docx -o contract.md

# Generate a visual diff between two versions
adeu diff v1.docx v2.docx

# Apply edits to the DOCX
adeu apply contract.docx edits.json --author "Review Bot"

# Apply valid edits in salvage mode while reporting failing edits
adeu apply contract.docx edits.json --partial

# High-throughput JSON-Lines daemon
adeu serve

# Scrub author metadata and internal trackers
adeu sanitize redline.docx -o clean.docx --keep-markup --author "My Firm" --report

What the text projection preserves exactly, what it normalizes (lists, styles, synthetic pages), and what stays read-only is specified in docs/FIDELITY.md.

The Python SDK

from adeu import RedlineEngine, ModifyText
from io import BytesIO

with open("MSA.docx", "rb") as f:
    stream = BytesIO(f.read())

edit = ModifyText(
    target_text="State of New York",
    new_text="State of Delaware",
    comment="Standardizing governing law."
)

engine = RedlineEngine(stream, author="AI Copilot")
engine.apply_edits([edit])

with open("MSA_Redlined.docx", "wb") as f:
    f.write(engine.save_to_stream().getvalue())

The TypeScript SDK

The entire core parsing and diffing engine is also available in pure TypeScript.

import { readFileSync, writeFileSync } from "fs";
import { DocumentObject, RedlineEngine } from "@adeu/core";

const buffer = readFileSync("MSA.docx");
const doc = await DocumentObject.load(buffer);

const engine = new RedlineEngine(doc, "AI Copilot");
engine.process_batch([{
  type: "modify",
  target_text: "State of New York",
  new_text: "State of Delaware",
  comment: "Standardizing governing law."
}]);

const outBuffer = await doc.save();
writeFileSync("MSA_Redlined.docx", outBuffer);

See the @adeu/core documentation for full installation and usage details.

n8n Community Node

Adeu ships as an n8n community node (n8n-nodes-adeu) for teams who prefer visual workflow automation over code. It exposes the full engine (extract Markdown, apply tracked changes, generate diffs, and finalize documents) as drop-in nodes that work in both deterministic pipelines and AI Agent tool calls.

# In n8n: Settings → Community Nodes → Install: n8n-nodes-adeu

See the n8n-nodes-adeu README for installation, $fromAI recipes, and example workflows.

LangChain Integration

langchain-adeu is an official integration package that exposes Adeu's local, offline-capable document manipulation tools directly to the LangChain ecosystem.

pip install langchain-adeu

Bundle its capabilities as tools in your agent workflow:

from langchain_adeu import AdeuToolkit

# Instantiate and retrieve all document tools
tools = AdeuToolkit().get_tools()

Refer to the LangChain Workspace Guide for full development instructions and detailed parameters.

Ecosystem & Integrations

Adeu is designed as a Virtual DOM for DOCX. Because we keep the core strictly focused on OpenXML safety, we maintain a dedicated ecosystem/ directory for third-party integrations.

The ecosystem folder hosts policies and guidelines for third-party contributions such as legal validation workflows, CLM sync scripts, and specialized multi-agent architectures.

Are you a vendor or builder? We welcome PRs to the ecosystem folder! Please see our Vendor & Integration Policy to get started.

Adeu Cloud

By default, the core Adeu redlining engine and local file tools are fully open-source and execute entirely on your machine. Adeu never phones home with your local documents (though your chosen LLM provider will naturally process the text the agent reads).

However, for teams requiring end-to-end workflows, you can connect to Adeu Cloud to unlock:

Email Processing & Fetching: We offer an extended MCP server with secure email thread fetching, document extraction, and automated drafting capabilities to handle contracts directly from your inbox.

Learn more about Adeu Cloud.

Contributing

We welcome contributions from the community! Whether it's fixing bugs, adding capabilities, or improving documentation, please see our Contributing Guide for instructions on setting up the local uv environment, running tests, and understanding the project's strict XML safety guidelines.

License

MIT License. Open source and free to use in commercial applications.

Available Tools

11 tools

accept_all_changesA

Destructive

Accepts all tracked changes and removes all comments in a single operation, producing a finalized clean document. Use this when a document review is entirely complete and you want to clear all redlines. For selective acceptance/rejection of specific changes, use process_document_batch instead.

ParametersJSON Schema

Name	Required	Description	Default
`docx_path`	Yes	Absolute path to the DOCX file.
`output_path`	No	Optional output path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare destructiveHint=true, and description adds that it removes comments and finalizes the document. This aligns well, though it could explicitly mention irreversibility. Still, combined with annotations, the behavior 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?

Two efficient sentences, each serving a distinct purpose: first explaining the operation, second providing usage guidance. No extraneous information.

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?

For a simple tool with two parameters and an output schema, the description fully covers the operation, its outcome, and usage context. No information gaps.

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?

Input schema provides 100% description coverage for both parameters. Description does not add any additional semantic value beyond what is already in 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 it accepts all tracked changes and removes comments to produce a finalized document. It uses specific verbs and distinguishes itself from process_document_batch by emphasizing single operation vs. selective processing.

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?

Explicit when-to-use (when review is entirely complete) and when-not-to-use (for selective changes), with direct mention of alternative sibling tool process_document_batch.

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

create_email_draftA

Creates an email draft in the user's native draft box (e.g., Outlook/Gmail). Can either start a NEW email, or REPLY to an existing thread. To REPLY, provide 'reply_to_email_id' (the short ID from search_and_fetch_emails). To start a NEW email, omit the ID but provide 'subject' and 'to_recipients'. Allows attaching local files (PDF/DOCX) by providing their absolute paths. The body should be formatted in Markdown.

ParametersJSON Schema

Name	Required	Description
`body_markdown`	Yes	The body of the email in Markdown format. Will be converted to HTML.
`reply_to_email_id`	No	Provide the short email ID to reply to an existing thread.
`subject`	No	The subject line. Required if starting a NEW email.
`to_recipients`	No	List of emails. Required if starting a NEW email.
`attachment_paths`	No	List of absolute file paths on the local system to attach to the draft.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that drafts are created in the native draft box (not sent), supports Markdown body, and accepts attachments (PDF/DOCX) via absolute paths. It does not mention permissions, limits, or what happens on failure. This is adequate but could add more safety context. Score 4.

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 a single, well-structured paragraph that first states the main function, then explains two modes, then attachments, then body format. Every sentence is informative; no redundant or vague statements. It is appropriately sized for the complexity. Score 5.

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?

The tool has 5 parameters and no output schema. The description explains input semantics well but omits what the tool returns (e.g., draft ID or success status). Given the complexity and that sibling tools like search_and_fetch_emails have IDs, the return value is important for chaining. Completeness is slightly lacking, so 3.

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 100%, baseline 3. The description adds significant value by explaining the relationship between parameters and the two modes (NEW vs REPLY). It clarifies that reply_to_email_id is required for REPLY, and subject/to_recipients are required for NEW. This goes beyond individual parameter descriptions and provides usage logic. Score 5.

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 it creates an email draft in the user's native draft box (Outlook/Gmail). It distinguishes between starting a NEW email and REPLYING to a thread, and references the sibling tool search_and_fetch_emails for the reply ID. This specificity and differentiation merits a 5.

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 provides two modes (REPLY vs NEW) with conditions for each: for REPLY, provide reply_to_email_id; for NEW, provide subject and to_recipients. It also instructs on attachment paths. However, it does not state when NOT to use this tool nor list alternatives, missing full comparatives. Still, the guidance is clear and useful, so 4.

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

diff_docx_filesA

Read-only

Compares two DOCX files and generates a text-based Unified Diff. Use this to see exactly what changed between two versions of a document. By default (compare_clean=True), it compares the 'Accepted' finalized states of both documents. Set compare_clean=False if you need to compare the raw underlying text including Tracked Change CriticMarkup.

ParametersJSON Schema

Name	Required	Description
`original_path`	Yes	Path to the base document.
`modified_path`	Yes	Path to the new document.
`compare_clean`	No	If True, compares 'Accepted' state. If False, compares raw text.

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?

Annotations indicate readOnlyHint=true, and the description adds operational details about compare_clean parameter behavior and output format. No contradictions.

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?

Three sentences front-load purpose and usage, with no redundant information. Every sentence earns its place.

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 file comparison tool with output schema and annotations, the description adequately covers behavior and parameters. It does not address error conditions but that is acceptable given the output schema fills return details.

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 descriptions already cover all parameters (100% coverage); the description adds nuanced context about the compare_clean flag's effect on tracked changes, enhancing understanding.

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 'Compares two DOCX files and generates a text-based Unified Diff', specifying a specific verb and resource. It distinguishes from siblings as no other tool performs comparison.

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?

It includes 'Use this to see exactly what changed between two versions of a document', providing explicit guidance. However, it does not mention situations to avoid or alternative tools.

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

login_to_adeu_cloudA

Logs the user into the Adeu Cloud backend. Securely opens a browser window for authentication.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Description adds the key side effect of opening a browser window for authentication, which is not covered by the openWorldHint annotation. It does not detail if user interaction is required or if it's blocking.

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 that are front-loaded and concise. Every word adds value with no redundancy.

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?

The description covers purpose and behavior adequately. With 0 parameters and an output schema available, it is fairly complete, though it could mention idempotency or prerequisites like being logged out first.

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?

Input schema has 0 parameters, so no parameter documentation is needed. Description does not need to add param semantics.

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 logs the user into Adeu Cloud backend via secure browser authentication, with specific verb 'logs' and resource 'Adeu Cloud backend'. It distinguishes from the sibling 'logout_of_adeu_cloud'.

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 for authentication but does not provide explicit guidance on when to use or when not to (e.g., if already logged in). No alternatives are mentioned.

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

logout_of_adeu_cloudA

Logs out of the Adeu Cloud backend by clearing the local API key from the OS Keychain.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Description discloses that the tool clears the local API key from the OS Keychain, which is a destructive action beyond the openWorldHint annotation. No contradiction.

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?

Single sentence, concise, front-loaded with the core action. No unnecessary words.

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 simplicity (no params, output schema exists), the description fully covers purpose and side effects. No gaps.

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?

Tool has no parameters and schema coverage is 100%, so description does not need to add parameter details. It is adequate.

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 action (logs out) and the resource (Adeu Cloud backend), and implicitly differentiates from the sibling tool login_to_adeu_cloud.

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?

Description does not explicitly state when to use or when not to use, but the context of logout vs login makes usage obvious. No exclusions or alternatives are mentioned.

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

open_local_fileA

Opens a local file in its native desktop application (e.g., Microsoft Word for DOCX files).

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Absolute path to the file to open.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

The annotation openWorldHint: true already indicates external side effects. The description adds value by specifying 'native desktop application', clarifying the nature of the side effect. Additional details (e.g., dependency on file associations) would improve transparency.

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?

A single, front-loaded sentence with no redundancy. Every word serves a purpose.

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 tool with one parameter and an output schema (presumably handling success/error), the description is adequate. It could mention the return type or edge cases, but overall completeness is high.

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 100%, and the description does not add meaning beyond the schema's definition of 'file_path' as 'Absolute path to the file to open.' Baseline 3 applies.

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 specifies the action ('opens') and the resource ('local file'), and includes an example ('Microsoft Word for DOCX files') that distinguishes it from sibling tools like read_docx or diff_docx_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., read_docx for content extraction). The description merely states what it does without context for selection.

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

process_document_batchA

Destructive

Applies a batch of structural edits, text modifications, and review actions to a document. This is your primary tool for editing DOCX files.

CRITICAL: All changes in the batch evaluate against the ORIGINAL document state. Do not send sequential edits that depend on each other within the same batch (e.g. rename X to Y, then modify Y). Instead, apply the rename in one batch, then modify Y in a subsequent batch.

The changes parameter is a list of operations. Each item MUST have a type:

'modify': Search-and-replace text. Provide exact target_text (CRITICAL: include surrounding context if the word appears multiple times to ensure unique matching) and new_text (the replacement). new_text supports full Markdown structure: '# Heading 1' through '###### Heading 6' at the start of a line for heading styles, 'bold' and 'italic' inline formatting, and blank lines ('\n\n') to split new_text into multiple paragraphs. Multi-paragraph inserts are tracked as one logical revision. To delete text, make new_text empty. Do NOT manually write CriticMarkup tags ({++, {--, {>>). To add a comment, use the 'comment' parameter.
'accept': Finalize a tracked change. Requires target_id (e.g., 'Chg:12'). (Note: Accepting one half of a paired modify cascades to accept the other half).
'reject': Revert a tracked change. Requires target_id (e.g., 'Chg:12'). (Note: Rejecting one half cascades to reject the other half).
'reply': Reply to a comment. Requires target_id (e.g., 'Com:5') and text.
'insert_row': Insert table row. Requires target_text (anchor), position ('above'/'below'), and cells (Markdown strings).
'delete_row': Delete table row. Requires target_text inside the row to be deleted.

Always provide a realistic author_name for Tracked Changes. This name will be used for attribution in the document's tracked changes and comments.

ParametersJSON Schema

Name	Required	Description
`original_docx_path`	Yes	Absolute path to the source file.
`author_name`	Yes	Name to appear in Track Changes (e.g., 'Reviewer AI').
`changes`	Yes	List of changes to apply. Each change must specify 'type'.
`output_path`	No	Optional output path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations provide destructiveHint: true. The description adds valuable context: all changes evaluate against original state, accept/reject actions cascade, and author_name is required for tracked changes. It also warns against manually writing CriticMarkup tags. This goes beyond the annotation but could mention more about output behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and front-loaded with purpose and critical notes. While it is lengthy, the complexity of the tool justifies the length. Each part earns its place, though minor redundancy exists (e.g., repeated 'CRITICAL').

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 (multiple change types with detailed behaviors), the description covers nearly all necessary context. The schema provides 100% parameter coverage, annotations indicate destructiveness, and an output schema exists (so return values are covered). The description is complete for effective use.

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 100%, but the description adds significant meaning: for 'modify', it emphasizes including surrounding context for unique matching and explains Markdown support; for 'accept'/'reject', it notes cascading behavior; for row operations, it provides details on anchor text. This greatly enhances understanding 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 clearly states the tool applies a batch of structural edits, text modifications, and review actions to DOCX files, and identifies it as the primary editing tool. It distinguishes from sibling tools like accept_all_changes and sanitize_docx by specifying batch operations.

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 states it is the primary tool for editing DOCX files and provides a critical guideline about not sending sequential edits that depend on each other within the same batch. It does not explicitly list when not to use the tool, but the context from sibling tools (e.g., read_docx for reading) implies appropriate use.

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

read_docxA

Read-only

Reads a DOCX file and extracts its text content. Use this to ingest documents into your context window. By default (clean_view=False), it returns text with inline CriticMarkup (e.g., {++inserted++}, {--deleted--}, {==highlighted==}{>>comment<<}) representing Tracked Changes and Comments. Set clean_view=True ONLY if you want to read the final, clean text, ignoring all redlines and comments.

PAGINATION & OUTLINE:

mode='outline' returns a structural map of headings with page numbers, styles, table presence, and referenced footnotes. Body content is omitted. Use this first on large documents to plan targeted reads.
mode='full' (default) returns the document body. Documents over ~19,000 characters are split into pages; use page=N to read a specific page (1-indexed). Documents under the limit are returned in full on page 1.
Page boundaries differ between clean_view=True and clean_view=False.
The Structural Appendix (defined terms, anchors, diagnostics) is repeated on every page.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Absolute path to the DOCX file.
`clean_view`	No	If False (default), returns the 'Raw' text with inline CriticMarkup. If True, returns 'Accepted' text.
`mode`	No	'full' returns body content (paginated for large docs). 'outline' returns a structural heading map with page numbers; body content is omitted.	full
`page`	No	Page number (1-indexed) for mode='full'. Defaults to 1. Ignored when mode='outline'.

TDQS

A4.2/5.0

Behavior5/5

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

The description adds significant behavioral context beyond the readOnlyHint annotation, including pagination behavior, CriticMarkup handling, page boundary differences between clean_view settings, and mode-specific behaviors. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with clear sections and front-loaded purpose. It is moderately detailed but every sentence adds value. Could be slightly more concise, but overall 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 4 parameters and no output schema, the description explains input options and return format (text with CriticMarkup, outline structure, pagination). It covers the essential aspects for a read tool, though lacks error scenarios.

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 baseline is 3. The description adds meaningful explanations: clean_view explains CriticMarkup vs accepted text, mode explains outline vs full, page explains 1-indexed pagination. This adds value beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Reads a DOCX file and extracts its text content', which is a specific verb+resource. It distinguishes between modes and clean_view options. However, it does not explicitly differentiate from sibling tools like diff_docx_files or sanitize_docx, though the purpose is clear.

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 provides explicit guidance on when to use each mode (outline for large documents first, clean_view for final text, page for pagination). It does not state when not to use this tool, but the context is clear enough for an agent to infer appropriate usage.

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

sanitize_docxA

Destructive

Sanitizes a DOCX file by stripping dangerous metadata (rsids, author names, template paths, DMS metadata, hidden text, orphaned content) and producing an audit report of everything removed. Use this before sending documents to external parties. Supports three modes: full scrub (for signing/closing), keep-markup (preserves your track changes and open comments), or baseline (recomputes your delta against the original document).

ParametersJSON Schema

Name	Required	Description
`file_path`	Yes	Absolute path to the DOCX file to sanitize.
`output_path`	No	Output path for the sanitized file. Defaults to <stem>_sanitized.docx.
`keep_markup`	No	Keep existing track changes and open comments. Strips resolved comments and all metadata. Use this when sending a redline to counterparty.
`baseline_path`	No	Path to the original/baseline document. When provided, the tool recomputes your changes as a clean delta against this baseline. Use when Track Changes was off, or to collapse multiple rounds of markup into a single clean redline.
`author`	No	Replace all author names on track changes and comments with this value. Used with keep_markup or baseline_path.
`accept_all`	No	Accept all unresolved track changes (full sanitize mode only). Required if the document contains unresolved changes. The report will list every change that was auto-accepted.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare destructiveHint: true, and the description reinforces the destructive nature by detailing what is stripped and that an audit report is produced. It adds significant context beyond annotations, such as the three modes and the specific metadata removed. No contradiction with annotations.

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 plus a short list of modes. It front-loads the purpose, then usage, then modes. Every sentence provides value with no redundancy. Highly efficient.

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 has an output schema, the description does not need to detail return values. It covers the main behavioral aspects (three modes, audit report, metadata stripping). It could mention handling of invalid files or overwrite behavior, but the input schema provides output_path defaults. Still, it is very complete for a complex tool.

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 description coverage is 100%, but the description enriches parameter meaning by mapping parameters to the three modes (full scrub, keep-markup, baseline). For example, keep_markup corresponds to the keep-markup mode, baseline_path to the baseline mode, and accept_all is used in full scrub. The author parameter is also contextualized.

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 sanitizes a DOCX file by stripping dangerous metadata and producing an audit report. It lists specific items removed (rsids, author names, etc.) and describes three modes, distinguishing it from siblings like accept_all_changes or diff_docx_files.

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?

Explicit usage context is provided: 'Use this before sending documents to external parties.' The three modes give guidance on when to use each (e.g., keep-markup for redline to counterparty). However, it does not directly exclude alternatives or say when not to use; the sibling list provides alternatives but no explicit comparison.

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

search_and_fetch_emailsA

Read-only

Searches the user's live email inbox. By default, searches only the Inbox folder (matching what the user sees in their mail client) — this excludes deleted items, drafts, and spam. Use filters to find specific emails (e.g., 'is_unread=True' for new emails, 'days_ago=7' for last week, 'folder=sent' for sent items, 'folder=all' to search the entire mailbox including trash). It returns a list of lightweight email previews. To read the full email body, thread history, and automatically download attachments to local disk, call this tool again and provide the specific email_id. Emails often contain attachments. It is highly recommended to always provide the working_directory parameter so attachments are saved directly to the user's actual project folder. This directory path refers to the user's native operating system, not the LLM's sandbox environment.

ParametersJSON Schema

Name	Required	Description
`sender`	No	Filter by the sender's email address or name.
`subject`	No	Filter by keywords in the subject line.
`has_attachments`	No	If True, only returns emails that contain file attachments.
`attachment_name`	No	Filter by a specific attachment filename.
`is_unread`	No	If True, returns ONLY unread emails. If False, returns ONLY read emails. Leave empty for both.
`days_ago`	No	Filter emails received in the last N days (e.g., 7 for last week).
`folder`	No	The mailbox folder to search in. Defaults to 'inbox' when omitted, which matches what the user sees in their mail client and excludes deleted items, drafts, and spam. Use 'sent' to search sent items. Use 'all' ONLY when the user explicitly asks to search across the entire mailbox including trash/deleted items.
`limit`	No	Maximum number of emails to retrieve (default: 10).
`offset`	No	Pagination offset to skip the first N emails.
`email_id`	No	If provided, fetches the exact full email and downloads its attachments. Accepts short IDs from search results (e.g., 'msg_abc123') OR direct Adeu IDs (e.g., 'adeu_4052').
`working_directory`	No	Optional. The current working directory of the project or task. If provided, attachments will be saved here under an 'adeu_attachments' subfolder. If omitted, attachments are saved to the system temp directory.

TDQS

A3.7/5.0

Behavior1/5

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

The annotation readOnlyHint=true contradicts the description's claim that the tool downloads attachments to local disk, which is a write operation. This inconsistency misleads the agent about the tool's side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is clear and front-loaded with core purpose. While slightly verbose (10 sentences), each sentence adds value and there is minimal redundancy.

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 tool with 11 parameters and no output schema, the description covers essential context: default folder behavior, fetch mode, attachment handling, and working directory. It lacks details on return format but is otherwise complete.

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%, baseline 3. The description adds value by providing usage examples (e.g., 'is_unread=True', 'days_ago=7'), explaining the behavior of email_id (accepts short IDs or Adeu IDs), and recommending working_directory for attachment storage.

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 searches the user's live email inbox and fetches full email with attachments when an email_id is provided. It differentiates the two modes and is distinct from sibling tools like create_email_draft.

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 the fetch mode (by providing email_id) and gives specific filter examples. It also cautions about using 'folder=all' only when explicitly requested. However, it does not explicitly contrast with sibling tools or exclude any use cases.

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

validate_documentsA

Validates documents for inconsistencies, contradictions, and risk assessments. To START a new validation, provide 'file_paths' as a JSON-encoded string representing a list of file paths. This will immediately return a task_id. To CHECK the status of a validation, call this tool AGAIN and provide ONLY the 'task_id'. The checking process will poll for up to 50 seconds. If it times out, continue checking.

ParametersJSON Schema

Name	Required	Description	Default
`file_paths`	No	A JSON-encoded string of a list of absolute paths to documents (DOCX, PDF) OR directories to start a new job. Example: '["/path/to/doc1.pdf", "/path/to/doc2.docx"]'
`task_id`	No	If resuming a pending check, provide the task ID here.

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses key behavioral traits beyond annotations: it returns a task_id immediately, polls for up to 50 seconds during status checks, and advises to continue if timed out. This aligns with the openWorldHint annotation indicating state mutation. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at four sentences, with the purpose front-loaded. It effectively communicates the essential information without unnecessary detail, though it could be slightly more terse.

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 asynchronous two-phase nature of the tool and the absence of an output schema, the description adequately covers the flow: starting, getting a task_id, checking status with polling, and timeout behavior. It could mention potential errors or result format, but it is generally complete.

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?

Although the input schema covers both parameters (100% coverage), the description adds significant value by explaining the usage pattern: how to start a validation with file_paths and how to check status with task_id. This clarifies the conditional logic that the schema alone does not convey.

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's function: validating documents for inconsistencies, contradictions, and risk assessments. It differentiates between starting a new validation and checking status, using specific verbs and resource terms. This distinguishes it from sibling tools like diff_docx_files or sanitize_docx.

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 provides explicit instructions on when to use the tool for starting vs. checking a validation, including the required parameters for each case. However, it does not mention when not to use it or suggest alternative sibling tools for similar tasks.

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. Dates show when Glama detected each change.

11 tool updatesv1.4.5May 5, 2026
- First observedaccept_all_changes
- First observedcreate_email_draft
- First observeddiff_docx_files
- First observedlogin_to_adeu_cloud
- First observedlogout_of_adeu_cloud
- First observedopen_local_file
- First observedprocess_document_batch
- First observedread_docx
- First observedsanitize_docx
- First observedsearch_and_fetch_emails
- First observedvalidate_documents

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct operation (auth, email, document reading/editing/finalization/comparison/sanitization/validation) with clear boundaries. No two tools serve overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., accept_all_changes, create_email_draft, sanitize_docx). No mixing of styles or vague verbs.

Tool Count5/5

The 11 tools cover the core functionality (document editing, email handling, authentication) without being excessive. Each tool serves a well-defined purpose.

Completeness4/5

The set covers read, edit, finalize, compare, sanitize, search/create drafts, and validate. However, adding new comments is not directly exposed (only replying), which is a minor gap.

Maintenance

ActivityActive

ResponsivenessResponsive

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

docx-document-generator-proposal-contract-markdown
io.github.theluckystrike
Create real Word .docx files from your AI chat: proposals, quotes, contracts, statements of work.
Workplace & Productivity App Automation
1
ClmentOAuth
com.clment
Contract review that keeps your contracts: cited answers, Word redlines, key-date alerts.
Legal & Compliance Documentation Access
1
contractoracle B
io.tooloracle
ContractOracle - 10 contract analysis tools: clause extraction, redlines, DORA mappings.
Legal & Compliance Research & Data
112
transaction-coordinator A
io.github.GordonHal
AI transaction coordinator + legal-matters platform for real estate and law firms.
Real Estate Legal & Compliance
112

Related MCP Servers

doc-tools-mcp
Content Management Systems App Automation
puchunjie
A
license
C
quality
F
maintenance
Word document reading and writing MCP implemented in Node.js
Updated a year ago (2025-03-26 10:52 UTC)
7
90
11
MIT
mcp-server-docx
Workplace & Productivity Developer Tools
jamesmehorter
F
license
B
quality
C
maintenance
Enables creating professional Word documents from markdown or structured content with fast, customized formatting via natural language.
Updated a year ago (2025-10-18 14:56 UTC)
7
1
-
docx-mcp
Legal & Compliance Workplace & Productivity
sontanon
A
license
A
quality
D
maintenance
Legal document redlining engine that applies AI-generated JSON changes as professional tracked changes with comments in .docx files, producing Word-indistinguishable output.
Updated 3 months ago (2026-06-05 23:56 UTC)
6
1
MIT
BitsBound MCP Serverofficial
Legal & Compliance AI & Machine Learning
BitsBound
A
license
A
quality
D
maintenance
Enables AI-powered contract analysis with partner-level redlines and real OOXML Track Changes for Claude Desktop and Claude.ai.
Updated 8 months ago (2025-12-28 07:10 UTC)
12
284
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/dealfluence/adeu'

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

Adeu: Track Changes for the LLM era

Installation

Claude Code (Plugin)

Other Skills-Compatible Agents (Cursor, Windsurf, VS Code Copilot, etc.)

Claude Desktop

Gemini CLI

Other MCP Clients (Cursor, Windsurf, etc.)

Smithery

Agent Workflows

Live MS Word Integration

Developer Tools (Python & TypeScript)

The Python CLI

The Python SDK

The TypeScript SDK

n8n Community Node

LangChain Integration

Ecosystem & Integrations

Adeu Cloud

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

BitsBound MCP Serverofficial

Latest Blog Posts

MCP directory API