Provides tools to list and search contacts across all address books in an Infomaniak account via the Infomaniak Contacts API.
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 Contact MCP Server search for John Doe"
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.
MCP Server for the Infomaniak Contacts API.
contact_list
List all contacts across all address books in your Infomaniak account
Returns: Full contact records with name, emails, phones, and other fields
contact_search
Search contacts by name, email, or phone number
Required inputs:
query (string): Search query string
Returns: Matching contacts with full details
Related MCP server: contacts-mcp
Create a token linked to your user:
Visit the API Token page
Choose "contacts" scope
Add the following to your claude_desktop_config.json:
{
"mcpServers": {
"contact": {
"command": "npx",
"args": [
"-y",
"@infomaniak/mcp-server-contact"
],
"env": {
"CONTACT_TOKEN": "your-token"
}
}
}
}{
"mcpServers": {
"contact": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"CONTACT_TOKEN",
"infomaniak/mcp-server-contact"
],
"env": {
"CONTACT_TOKEN": "your-token"
}
}
}
}CONTACT_TOKEN: Required. Your Infomaniak API token with contacts scope.
If you encounter permission errors, verify that:
The token has the "contacts" scope
The token is correctly copied to your configuration
Docker build:
docker build -t infomaniak/mcp-server-contact -f Dockerfile .This MCP server is licensed under the MIT License.
List all contacts from your Infomaniak account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says it lists contacts. It does not say whether results are paginated, capped, or ordered, which is critical for a "list ALL" tool that could return a large account-wide collection, nor does it note permission/auth requirements.
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 tight sentence with no filler, front-loading the verb and scope. It is efficient but so brief that it leaves behavioral gaps unaddressed.
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?
There is no output schema, so the description should say something about the shape or volume of the returned list; it says nothing. For a zero-param listing tool this is a moderate but not fatal gap, since the operation itself is simple.
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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no inputs are needed.
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 specific verb and resource ("List all contacts") scoped to an Infomaniak account, so the agent knows exactly what is returned. It does not name or distinguish itself from the sibling contact_search, but the word "all" hints at the unfiltered variant.
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 explicit when-to-use or when-not-to-use guidance and the sibling contact_search is never mentioned, so the agent must infer that this is the unfiltered listing and search is the filtered alternative. That inference is plausible but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search contacts by name, email, or phone
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. 'Search' implies a read-only operation, but nothing is said about match semantics (partial vs exact), result caps, pagination, or ordering — all relevant for an agent deciding how to interpret or page results.
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 short, front-loaded fragment with zero filler. It is appropriately sized for a one-parameter tool, though it is a phrase rather than a complete sentence and omits any routing hint.
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?
The tool is simple (one required string, no output schema, no nesting), so little explanation is needed. Still missing are match behavior and result-limit details, which matter for an agent composing queries and handling responses.
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 coverage is 100% and the single parameter is already documented as 'Search query string'. The description goes beyond that by clarifying which attribute types the query may target (name, email, phone), which meaningfully improves how an agent constructs the value.
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 specific verb (Search) and resource (contacts) plus the fields matched (name, email, phone), so the agent knows exactly what the tool does. It does not distinguish itself from the sibling contact_list, so it falls short of a 5.
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?
Mentioning that search operates on name/email/phone implies the use case (find a specific contact when you have identifying text), but there is no explicit when-to-use or when-to-prefer-contact_list guidance despite the sibling existing.
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.
v1.0.2contact_listcontact_searchScored across 2 tools
contact_list and contact_search are mostly distinct: one enumerates all contacts, the other filters by query. There is minor overlap since listing all contacts is a degenerate search, but an agent can reasonably choose between them.
Both tools follow a clear and consistent contact_verb pattern (contact_list, contact_search). The naming is predictable and easy to generalize.
Two tools is thin for a contact management server, which typically needs more operations. The count is not extreme, but it feels under-scoped for the domain.
The surface only supports reading and searching; there is no create, update, delete, or get-by-ID operation. This leaves significant gaps for any contact lifecycle workflow.
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Your IMAP mailbox as an MCP server: read, search and (if you allow it) organize mail. Open source.
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
