DakNode MCP server
DakNode's API as MCP tools, over stdio. The client launches it as a subprocess; there is no hosted endpoint and no infrastructure.
Install
Python 3.10+. With uv, nothing needs installing
up front — the client starts it with uvx. Otherwise pipx install daknode-mcp.
Get an API key with the two-request signup at https://daknode.com/developers.
Configure
{
"mcpServers": {
"daknode": {
"command": "uvx",
"args": ["daknode-mcp"],
"env": { "DAKNODE_API_KEY": "…" }
}
}
}
With pipx, use "command": "daknode-mcp" and no args. From a repository
checkout, "command": "python", "args": ["-m", "mcp_server.server"].
The key comes from the environment and never from a command-line argument:
argv is visible to every process through ps, and shells record it in history.
The server refuses to start without it, so a misconfiguration is obvious at
launch rather than looking like a broken tool.
Tools
create_inbox · list_threads · list_messages · get_thread · get_message
· search · send
Every tool is 1:1 with a published API operation. That is architecture.md
§0 consequence 4, and it is the boundary this server exists inside: DakNode
exposes operations, the agent decides which to call. A tool like
reply_to_latest or auto_respond would cross that line — DakNode would be
choosing which message to answer — while looking like a convenience.
tests/test_mcp_server.py enforces it rather than leaving it to review.
What is deliberately absent
Erasure. It is irreversible, and an agent that can erase a data subject through a tool call is a liability no convenience justifies. It stays an explicit API call a human integrates.
Console and operator APIs. Not a product surface.
Notes for whoever uses this
send without thread_id opens a new conversation in the recipient's
client. Pass thread_id to reply into an existing one — the server then derives
In-Reply-To and References from that thread's latest received message.
search returns identifiers and scores, not content. Resolve them with
get_message or get_thread.
body_text is already cleaned: quoted history and signatures are stripped.
Check risk_level before feeding content to a model — high means
prompt-injection patterns were detected in mail from the internet.
Metadata
Release files for daknode-mcp 0.3.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| daknode_mcp-0.3.0.tar.gz | 5.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| daknode_mcp-0.3.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 11.5 kB
Release files / daknode_mcp-0.3.0.tar.gz
| Download URL | daknode_mcp-0.3.0.tar.gz |
|---|---|
| Size | 5.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
acdea1e1d5cbf261278f71aeb3746bde9db145c86ac8d2199e9990bdadb17a51
|
|
BLAKE2b-256 checksum How to use checksums |
a368e323f838482ded6196ee69476b6368c7f1ac26c4f4f909cd67c41e034e0a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.
Transparency logRelease files / daknode_mcp-0.3.0-py3-none-any.whl
| Download URL | daknode_mcp-0.3.0-py3-none-any.whl |
|---|---|
| Size | 6.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
055b4a87eb6b4a0edd1a2dd2cdb659a21121d4b5ed014b3ca068299ec3017dd1
|
|
BLAKE2b-256 checksum How to use checksums |
9b62db9fae57df615b7254ab7ac8fcb5afada7c10522a7fb5a1d18540a17cc23
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.
Transparency log