proton-mcp

Overview Schema Source Related Servers Discussions Admin

Open the configuration interface

open_configuration

Read-only

Returns the local configuration interface address so users can view or change server settings, sign in, inspect folders and sent items, check permissions, or resolve missing credentials.

Instructions

Returns the address of the local configuration interface, which runs for as long as this server does and is where everything about this server can be seen and changed. Give it to the user whenever they ask for the interface, the panel, the settings, the web page, the address or the link, however they phrase it, and also when they ask where to sign in, where to see what has been sent, where the folders are listed, what the assistant is allowed to do, or when another tool reports that no credentials are available. The address is fixed and shared by every running server; changes on the page may need a PIN that only the user knows and that must never be asked for in the conversation.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "open_configuration"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Jul 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations it discloses real behavior: the address is fixed and shared by every running server, the interface stays up for the life of the server, edits on the page may require a PIN, and the PIN must never be requested in conversation. That safety-critical constraint is exactly the sort of thing annotations cannot convey.

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 core fact (it returns an address) is front-loaded, and the trailing enumeration of trigger phrases is purposeful for matching. The middle sentence is a long comma-chained list that could be tightened, which keeps it just below the top mark.

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 zero-parameter, read-only lookup with no output schema, the description supplies everything needed: what is returned, its lifetime and sharing properties, when to surface it, and the PIN handling rule. No obvious gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate. Baseline applies; no credit beyond it is possible.

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 gives a specific verb and resource: it 'returns the address of the local configuration interface', and it scopes that interface as running alongside this server. Nothing in the sibling list overlaps with it, so an agent can route to it unambiguously.

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?

It enumerates the user phrasings that should trigger the call (interface, panel, settings, web page, address, link) and adds the less obvious cases: where to sign in, where sent items are visible, what the assistant may do, and the fallback when another tool reports missing credentials. That is explicit when-to-use guidance rather than inference.

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