Skip to main content
Glama
Sign In
Commonpost MCP for Thunderbird

Commonpost MCP for Thunderbird

by commonpost
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Create Contact

createContact

Add a new contact to a Thunderbird address book with details such as name, email, phone, and note. Search first to avoid duplicates and update an existing contact instead.

Instructions

Add a contact to an address book (addressBookId from searchContacts, else the first writable one); set at least one field. No duplicate check: search first with searchContacts, and change an existing contact with updateContact.

Input Schema

NameRequiredDescriptionDefault
noteNoContact note; may contain multiple lines
emailNoPrimary email address
titleNoJob title
emailsNoAll addresses, replacing the list; primary: the flagged one or the first
phonesNoPhone numbers; replaces the list, [] clears it
birthdayNoBirthday as YYYY-MM-DD or --MM-DD when the year is unknown
lastNameNoLast name
addressesNoPostal addresses; replaces the list, [] clears it
firstNameNoFirst name
displayNameNoDisplay name
organizationNoOrganization or company name
addressBookIdNoAddress book ID (addressBookId of searchContacts rows)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.19.2
    • changedInput schema / properties / addressBookId / description
      Previous value: -"Address book directory ID (from searchContacts results). Defaults to the first writable address book."New value: +"Address book ID (addressBookId of searchContacts rows)"
    • removedInput schema / required
      Removed value: -[]
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write; the description adds real behavior on top: no duplicate detection, a silent default address book when the id is omitted, and a minimum-content constraint. It stops short of saying what comes back or whether the new contact's id is retrievable, which matters for a create with no output schema.

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 tight clauses, front-loaded with the action, then the address-book resolution, then the duplicate-check warning. No sentence is redundant and nothing is buried.

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 12-parameter create tool with no required fields, the description covers the critical gaps: address book selection and the absence of deduplication. The remaining omission is the return value (whether the created contact or its id is returned), which is left undefined because no output schema exists.

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 100%, so the baseline is 3, but the description adds meaning the schema does not: where addressBookId should come from (searchContacts rows) and what happens if it is omitted. "Set at least one field" is a non-obvious constraint given that the schema declares zero required parameters.

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 ("Add a contact to an address book") and immediately scopes it against the two siblings that could be confused with it, searchContacts and updateContact. An agent can distinguish create from update from lookup without opening any schema.

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 gives explicit routing: search first with searchContacts because there is no duplicate check, and use updateContact to change an existing contact. It also states the fallback when addressBookId is unknown (the first writable book), which is the main decision an agent faces before calling.

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