Skip to main content
Glama
hl9020

mcp-all-inkl

by hl9020

kas_mail

Manage All-Inkl email infrastructure: create, update, delete, and list mailboxes, forwards, mailing lists, and filters via the KAS SOAP API.

Instructions

Manage email: mailboxes, forwards, mailing lists, filters. Actions:

  • list/create/update/delete: mailboxes (params: mail_login, mail_password, ...)

  • list_forwards: list all email forwards

  • create_forward: params {local_part, domain_part, target_0, target_1, ...} - target_N are the forward destinations (numbered from 0), e.g. target_0="user@example.com"; may fail with "fetch failed" on first attempt, retry once

  • update_forward: params {mail_forward, target_0, target_1, ...} - mail_forward is the full address e.g. "alias@example.com"; note: update may fail with "in_progress" right after creation, retry after a few seconds

  • delete_forward: params {mail_forward} - mail_forward is the full address e.g. "alias@example.com"

  • list_lists/create_list/update_list/delete_list: mailing lists

  • list_filters/add_filter/delete_filter: mail filters Optional params for all tools: "pick" (array of field names to return, reduces tokens) and "filter" (object to match, e.g. {"record_type":"MX"} returns only matching entries).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pickNoReturn only these fields from each result (reduces token usage)
actionYes
filterNoFilter array results by field values, e.g. {record_type: "MX"}
paramsNo
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses important behavioral details: create_forward may fail with 'fetch failed' on first attempt, update_forward may fail with 'in_progress' after creation, and explains retry guidance. This goes beyond the basic action list, though it omits information about auth, rate limits, or destruction warnings.

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 moderately long but well-structured with action bullets and concrete examples. Every sentence adds value, and the front-loaded purpose statement makes it easy to parse. The length is justified by the tool's many actions.

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 there is no output schema and the tool has many actions, the description provides a solid overview, including param formats and failure/retry notes. It does not cover params for lists/filters, but the overall picture is sufficiently complete for an agent to select and invoke the tool correctly in most cases.

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 only 50%, so the description compensates by explaining key parameters: mail_login/mail_password for mailboxes, target_0/target_1 for create_forward, and mail_forward as the full address for update/delete. It also clarifies the optional pick and filter parameters, adding meaning beyond the bare 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 'Manage email: mailboxes, forwards, mailing lists, filters' which is a specific verb+resource, and enumerates concrete actions. It distinguishes from sibling tools (ssl, cronjob, dns, etc.) by explicitly focusing on email management.

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 clear context (email-related operations) but does not explicitly mention when not to use this tool or name alternative tools. The list of actions implies usage scenarios, but there are no exclusions or comparative guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/hl9020/mcp-all-inkl'

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