get_signatureFetch the signature mailmcp appends beneath replies for a specified account: HTML with inline images when enabled, otherwise the plain-text token signature.
Returns the signature mailmcp appends under replies: the newest message in "mailmcp-signature" (HTML, inline images) when the account uses it, else the plain-text signature from the token.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | list_accounts id |
Changes observed during successful MCP inspections.
v0.13.12Input schema / properties / account / descriptionPrevious value: -"Account id from list_accounts"New value: +"list_accounts id"v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: the two-tier resolution logic (folder message first, token fallback) and the returned content shape (HTML with inline images vs plain text). It stops short of saying what happens when no signature exists at all.
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 that leads with the verb and resource, then qualifies the resolution path. The quoted folder name and parenthetical format note are dense but each earns its place; there is no filler.
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 correctly carries the burden of describing the return value, and it does so in detail (source folder, HTML vs plain text, inline images). The only real gap is behavior when neither signature source exists, which an agent would want to know.
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 100% and the sole parameter (account) is documented in the schema as a "list_accounts id". The description adds nothing about the parameter — e.g. that it selects which account's signature is resolved — so the baseline 3 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?
States a specific verb ("Returns") and resource (the signature appended under replies), and goes further by explaining where the value comes from — the newest message in the "mailmcp-signature" folder or the plain-text token fallback. It implicitly contrasts with the write-side set_signature but never names it, so sibling differentiation is left to inference.
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 description explains what the tool returns but gives no when-to-use, when-not-to-use, or alternative guidance, despite set_signature being an obvious sibling. An agent must infer that this is the read counterpart to set_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.