Allows interaction with Infomaniak's API to discover services, inspect resources, review and approve exact changes, and execute controlled operations such as DNS and mailbox writes, along with read-only diagnostics for domains, DNS audits, and DNS propagation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Infomaniak AI list the DNS records for example.com"
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.
An independent, unofficial AI plugin for Infomaniak. Discover services, inspect resources, review an exact change, approve it independently, execute and verify. Not affiliated with or endorsed by Infomaniak.
Version 0.2 has a local MCP server, an optional authenticated HTTP service, a human approval interface and a durable operation journal. The complete public catalogue is searchable; execution is limited to reviewed handlers.
Coverage | Current state |
Public catalogue | 1,514 method/path pairs across 15 product groups |
Pinned public schemas | 16 selected operation definitions |
Reviewed operations | 12 reads (3 diagnostics), 8 writes; VPS reads need the existing MCP adapter |
Writes | Disabled on initialization; scoped grants and independent approval required |
Application deployment / VPS lifecycle writes | Not implemented |
Live compatibility | Reads checked live; write qualification script ready, not yet run |
Catalogue discovery is not proof that an operation is implemented or permitted. See coverage and safety, validation and the remaining roadmap.
Every customer uses their own credentials. With only INFOMANIAK_API_TOKEN (or
its private _FILE source), the server starts a read-only discovery edition:
accounts, products and the full public catalogue. No author account, backend,
private policy or server hosting is needed for that starting point. It exposes
four tools and cannot plan or execute writes.
A scoped policy enables resource-level reads and the controlled write lifecycle. The original backend configuration remains supported separately.
Related MCP server: agent-mcp-workflow-platform
Requires Node.js 22.13+; the controlled edition uses Node's SQLite API. No server hosting is required.
npm ci --ignore-scripts
npm testInitialize a new private directory using your actual account ID. Replace the capitalized placeholders; omit product options you do not need:
node dist/admin.js init \
--directory "$HOME/.config/infomaniak-ai" \
--account ACCOUNT_ID \
--zone example.com \
--dns-source _infomaniak-ai-test \
--mail-hosting MAIL_HOSTING_ID \
--mailbox MAILBOX_NAMEThis writes a private policy, a client connection token and a separate human approval key. Their values are never printed. All writes and writable resource grants start disabled. Existing installations are never overwritten.
Configure the provider token in the client's secret store or in
INFOMANIAK_API_TOKEN. Alternatively set INFOMANIAK_API_TOKEN_FILE to an
absolute regular secret-file path with mode 0600. Do not configure both sources,
or paste credentials into a conversation.
For a generic MCP client, use command node with arguments:
/absolute/path/to/infomaniak-ai/dist/server.js
--config
/absolute/path/to/private/access.local.jsonThe default local policy also starts the approval interface at localhost:8787/approvals. Its human key belongs in the browser/interactive human terminal, outside the AI client's configuration.
node dist/server.js --config /absolute/path/to/access.local.json --doctorDoctor checks configuration and optional backend integrity, without provider calls.
The policy-driven edition exposes eight tools:
Tool | Purpose |
| Coverage, configured adapters and connection policy |
| Relevant operations and reviewed schemas on demand |
| Paginated public metadata by product/method |
| A reviewed read within account/resource grants |
| Persist a preview; no provider mutation or approval |
| Execute an independently approved exact plan once |
| Status or read-only reconciliation |
| Cancel before execution starts |
There is no MCP approval tool or generic HTTP/shell executor. Search can return disabled catalogue entries with the reason they cannot execute.
Reviewed operations carry Infomaniak-specific notes in search results: which
ID is which, the . zone apex, MX priority inside the target, UTC expiry dates,
what the forwarding flags mean. The skill has the
full table.
Operation | What it checks |
| Registration expiry in UTC, days left, expired/expiring/ok |
| SPF (missing, duplicate, |
| Google, Cloudflare and Quad9 answers for one name, compared with the zone; a failed lookup is disagreement |
They read the stored zone and public resolvers. They are not mail delivery or signing tests.
Start with explicitly disposable resources. An operator must grant all of:
The exact reviewed operation in the principal's operations list.
writes: "disposable-only" and an exact resource binding with
disposable: true and writable: true.
A fresh independent human approval of the complete plan.
Named DNS grants use resources.dns_names["example.com:_infomaniak-ai-test"].
Update/delete calls include expected_source when using such a narrow grant.
A writable whole-zone grant permits broader changes; a zone inventory grant
does not. Mailbox grants use resources.mailboxes["HOSTING_ID:MAILBOX_NAME"],
separate from mail-hosting inventory grants.
A human reviews account, resource, before/after values, impact and recovery limits
at /approvals, then types APPROVE. The model receives a plan ID/hash; neither
can grant approval. Local administrators can also use admin.js plans, show
and interactive approve with the separate human key.
Stale or expired plans cannot execute. Conflicting writes serialize through resource locks. Uncertain requests remain locked and reconcile through reads; mutations are never automatically retried. A verified provider state does not prove DNS propagation, delivery, SSH reachability or application health.
To qualify writes on your own account, pick a zone and a throwaway mailbox and run:
INFOMANIAK_API_TOKEN=... node scripts/qualify-writes.mjs \
--account ACCOUNT_ID --zone example.com --mail-hosting MAIL_HOSTING_ID --mailbox throwawayIt only touches the DNS name _infomaniak-ai-test and the alias ik-ai-test,
plans each change, waits for you to approve it with node dist/admin.js approve
in a second terminal, then executes, reads back and finally checks that the zone
and aliases match their starting state. It never approves anything itself.
Use writes: "enabled" only after disposable live qualification and a deliberate
policy review. It still requires writable resource grants, operation grants and
per-plan independent approval. Credentials, purchases, arbitrary API execution,
VPS reinstall and other unreviewed operations remain unavailable.
The original three-tool read-only edition remains available without a policy file.
It requires INFOMANIAK_API_TOKEN, INFOMANIAK_MCP_SERVER_PATH (absolute reviewed
dist/server.js) and INFOMANIAK_MCP_SHA256. It runs the backend with browser
auth disabled and a GET-only fetch guard.
The controlled edition can reuse that adapter for token-only VPS reads via:
{
"backend": {
"path": "/absolute/path/to/infomaniak-mcp-agent/dist/server.js",
"sha256": "SHA256_OF_REVIEWED_ENTRY_FILE"
}
}This is a policy fragment, not a complete configuration. The checksum covers the entry file, not its dependency graph. Use an audited build; a guard is not an OS sandbox for an untrusted executable. The reviewed VPS companion capability is required. Upstream npm 0.15.2 returned 404 during the earlier validation, so no working upstream package-install command is assumed.
For Claude Code:
claude plugin validate .
claude --plugin-dir .Select the optional private policy file for the controlled edition, or supply the reviewed backend path/checksum for the original edition. Manifest validation is separate from native-client onboarding, which has not been proven end to end.
This plugin grew out of contributions to two existing open-source projects, and reuses what was learned there:
peaktwilight/infomaniak-cli,
a Python CLI for the Infomaniak API. Open pull requests add DNS propagation and
sync fixes, a DNS audit fix, hosting discovery, read-only mode, --dry-run
previews and mailbox commands.
Mogacode-ma/infomaniak-mcp-agent, a TypeScript MCP server with two-phase confirmation. Open pull requests add DNS export/diff/propagation tools, token-only VPS inventory and firewall reads, tests, read-only mode, alias deletion and mailbox forwarding.
Use the CLI for scripting, the MCP server for a broad tool surface driven by an agent, and this plugin when you want scoped grants and approval by a separate human for every write.
The authenticated Streamable HTTP edition uses separate application-specific
client and human-approval credentials, plus an isolated provider token per user.
Run node dist/server.js --config /private/access.local.json --http.
See the Infomaniak VPS deployment guide for the pinned Docker image recipe, Caddy HTTPS proxy, private state, backup and restart procedure. Nothing is deployed by building this repository. OAuth-only client onboarding and a public managed service remain future work.
npm run packageThis creates artifacts/infomaniak-ai-0.2.0.tgz with compiled code, catalogue,
skill and plugin manifest. A whitelist excludes tests, local policies, credentials
and operation databases. The package remains marked private during development
to prevent accidental registry publication; the local bundle is installable.
A public registry/marketplace release has not occurred.
To test the bundle in a separate local installation:
npm install --prefix "$HOME/.local/share/infomaniak-ai" \
--ignore-scripts ./artifacts/infomaniak-ai-0.2.0.tgzConfigure the MCP client's command as node, with the installed absolute
node_modules/infomaniak-ai/dist/server.js path as its argument and your provider
token in its secret environment. With no policy or backend configuration, this
starts the four-tool discovery edition. Run python3 scripts/bundle-smoke.py to
check the bundle in a disposable clean Node container using fake credentials.
npm run typecheck
npm test
python3 -m unittest discover -s tests -p 'test_*.py'
npm run format:checkFixture tests use fake credentials and APIs. The container smoke test disables networking and uses a disposable state directory. Live evidence stays outside this repository. This package is private to prevent accidental publication.
MIT licensed. Provider adapter fixes remain separate upstream contributions.
Browse all public API metadata by product/method. Discovery does not grant execution.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| method | No | ||
| offset | No | ||
| product | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), lowering the burden on the description. The line 'Discovery does not grant execution' adds genuinely useful behavioral context about side effects, but pagination behavior and the shape of returned metadata are left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the purpose leads and the caveat follows. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally sketch what the catalog returns and how pagination works, which it does not. It does establish the discovery-only nature of the operation, which is the most important thing an agent needs, but the 0% parameter coverage leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters, so the description carries the full burden and mostly fails it. The phrase 'by product/method' loosely maps to the product and method filters, but limit and offset receive no explanation of ordering, defaults, or page-size behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Browse all public API metadata by product/method'), which is clearly a discovery/catalog operation distinct from the search, read, and status siblings. It stops short of naming those siblings or explicitly contrasting the tool with them, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is the caveat 'Discovery does not grant execution', which clarifies an outcome but not when to pick this tool over infomaniak_search or infomaniak_read. There are no conditions, prerequisites, or exclusions stated, leaving the agent to infer the use case from the word 'browse'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a reviewed read within this connection's account/resource grants.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | ||
| operation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that operations must be 'reviewed' and are bounded by the connection's account/resource grants, which is genuine extra context about authorization scope, but it omits what happens on an ungranted or non-reviewed operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, which is structurally clean. However, it is abstract and jargon-heavy ('reviewed read', 'grants') rather than genuinely front-loading the essential information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic dispatcher with a free-form required 'operation' string and a nested, free-form 'arguments' object at 0% schema coverage and no output schema, the description is far too thin. It should explain how operations are identified and what argument shapes are expected, especially alongside an infomaniak_catalogue sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, so the description carries the full burden and largely fails: it never explains what values 'operation' takes, how they are discovered, or how 'arguments' should be shaped for each operation. Only the grant-scoping hint gives any signal about valid operation values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool's own name ('read') and adds only a vague scope phrase, 'within this connection's account/resource grants.' It never says what resource is being read or how it differs from siblings like infomaniak_search or infomaniak_catalogue. An agent cannot tell what this tool actually retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools that likely cover overlapping ground (search, catalogue, status). The word 'read' faintly implies a read path, but nothing tells the agent when this is preferable to infomaniak_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover public API operations. Catalogue entries may be unavailable; reviewed schemas load on demand.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| include_unavailable | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, idempotent, open-world profile, so the bar is lower. The description adds genuine behavioral context beyond them: catalogue entries may be missing and reviewed schemas are fetched lazily, which tells the agent results can be partial and a follow-up read may be needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler, and the core purpose is front-loaded ahead of the caveats. The second sentence is slightly telegraphic ('load on demand') but earns its place by conveying the lazy-loading behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should ideally clarify what a search result contains (operation identifiers usable with infomaniak_read), which it does not. With annotations covering safety and only three simple params, it is minimally adequate but leaves the result shape and workflow linkage underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters. The phrase 'catalogue entries may be unavailable' loosely gestures at include_unavailable, but limit and query are entirely unexplained and no formats, defaults, or range guidance are given in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Discover public API operations' — an agent knows this is a discovery/search tool. It implicitly distinguishes itself from infomaniak_read (which fetches a reviewed schema) but never names siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Reviewed schemas load on demand' hints at a search-then-read workflow, suggesting this is the entry point before infomaniak_read. However, it never states when to use this over infomaniak_catalogue or infomaniak_read, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check catalogue coverage, connection policy and reviewed capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only vague nouns ('connection policy', 'reviewed capabilities') without saying what state is inspected, whether it performs a live connection check, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no padding, so nothing needs trimming. Its brevity, however, comes at the cost of substance rather than being earned by density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only diagnostic with no output schema, the description should state what the status payload covers. It hints at three areas but leaves the actual returned information and the meaning of 'coverage' unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'check' and the objects 'catalogue coverage, connection policy and reviewed capabilities' gesture at a diagnostic/status resource, but the phrasing is jargon-heavy and never says plainly what the tool reports or returns. It also does not distinguish itself from siblings infomaniak_catalogue and infomaniak_search, which plausibly overlap with 'catalogue coverage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when this tool should be chosen over infomaniak_search, infomaniak_catalogue or infomaniak_read, and no preconditions or exclusions are given. The agent must guess at the intended trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0infomaniak_catalogueinfomaniak_readinfomaniak_searchinfomaniak_statusScored across 4 tools
status and read are clearly distinct (policy check vs. executing a reviewed read). search and catalogue both address API metadata discovery and could be confused, though the descriptions hint at different scopes (operation discovery vs. browsing by product/method).
All four tools use the same infomaniak_ prefix with snake_case suffixes. The pattern is entirely predictable across the set.
Four tools is reasonable for a discovery-plus-read server. Slightly thin, but each tool maps to a distinct capability (status, search, browse, execute read).
The surface is intentionally read-only with discovery, so no mutation/execution tools exist. This covers metadata lookup and reads but leaves a notable gap for any write workflow, which agents cannot work around.
Read-only ArcadeOps discovery for developer docs, OAuth, OpenAPI and synthetic sandbox.
Manage API keys, identities, permissions, rate-limit overrides and verification analytics.
Read-only discovery of Framekeep capabilities, security boundaries, and public resources.
One API, all things verified — control, delegation, human approval, anti-impersonation.
