Skip to main content
Glama
soil-dev

capsulemcp

by soil-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

add_party_email_address

Add a single email address to a party with one atomic PUT, appending exactly one entry without replacing existing addresses.

Instructions

Append a single email address to a party. Atomic — one PUT to Capsule. Use this instead of update_party.emailAddresses when you want to add exactly one entry; the bulk array on update_party is append-only and won't replace.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoFree-form label, e.g. 'Work', 'Home'.
addressYes
partyIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.1
    • changedInput schema / properties / address / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. Changed1 schema field changedv2.3.0
    • changedInput schema / required
      Previous value: -[
-  "address"
-]New value: +[
+  "partyId",
+  "address"
+]
  3. Addedv1.7.0
  4. Removedv1.6.2
  5. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses 'Atomic — one PUT to Capsule,' revealing atomicity and the underlying transport operation, which the annotations do not convey. It also clarifies the append-only, non-replacing semantics versus the bulk alternative. A small gap remains: no mention of error behavior or idempotency, but the disclosed traits add real value beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: the core action, the atomicity/transport trait, and the routing guidance against the sibling. The most decision-relevant information is front-loaded in the first sentence, and there is no filler or restatement of the tool name.

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?

For a simple 3-parameter append operation with no output schema, the description covers the key decision factors: operation semantics, atomicity, and when to prefer it over update_party. The main omission is the response shape on success or failure, but with annotations already establishing the mutation/safety profile and the operation being low-complexity, nothing an agent needs to select or invoke it correctly is materially missing.

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

Parameters3/5

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

Schema description coverage is only 33% (only `type` has a natural-language description), so the description carries some burden. It contextualizes `address` as a single entry and the operation as append-only, but it does not elaborate on `partyId` or the label semantics of `type` beyond the schema. The parameter names are self-evident, which softens the gap, but the description only partially compensates for the low schema coverage.

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 opens with a specific verb+resource: 'Append a single email address to a party.' The word 'single' scopes the operation precisely, distinguishing it from bulk array updates and from the sibling add_party_phone_number/add_party_address tools, which target different resources. No ambiguity about what this tool does.

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?

The description explicitly names the alternative ('update_party.emailAddresses'), states the condition that selects this tool ('when you want to add exactly one entry'), and explains the behavioral difference ('the bulk array on update_party is append-only and won't replace'). This is textbook when-to-use/when-not-to-use routing with zero inference required.

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

Deploy Server

Other Tools