Skip to main content
Glama

Add contact channel

well_add_contact_channel

Add a contact channel to a company or person.

Wraps the resource-scoped REST endpoints (POST /v1/{companies,people}/:id/{emails,phones,web-links,locations}).

channel + the matching value field:

  • email → value.email

  • phone → value.e164_number (E.164; a leading "+" is added if missing)

  • web_link → value.url (+ optional value.platform, default "website")

  • location → value.city, value.country (+ optional address_line1/2, region, postal_code) value.label is optional (defaults to "work").

For a company address read from a public company registry hit (well_search_company_registry), pass the hit's id as registry_ref: the address is stored with "registry" as its source. The call is refused, with nothing written, when that hit is not from an official registry, is for another registry number or country than the company's, or does not carry every address part given.

On an invoice draft, pass draft_party with the draft's invoice_id: "receiver" says the parent is the draft's customer (its company or its person), "issuer" says the parent is the company that issues it. The call is refused, with nothing written, when the parent is not that party. While the conversation has an open draft, a call whose parent is the workspace's own company and that has no draft_party is refused before any confirmation: a detail the person gives on a draft is the customer's unless they say it is their own company's, and when their words do not say which, ask them in one line first. Otherwise, without draft_party, the parent is checked only to be a live record of the workspace.

NOTE: adding a phone is supported on a PERSON but NOT on a company (no endpoint) — that combination returns a clear error. To READ existing channels, use well_query_records on the parent (companies/people) or the channel root.

Input Schema

NameRequiredDescriptionDefault
valueYesChannel value — fill the field(s) for the chosen channel
parentYesParent record type: company or person
channelYesChannel to add: email | phone | web_link | location
parent_idYesUUID of the parent company or person
draft_partyNoSet on an invoice draft: the call is refused unless the parent is this party of the draft
registry_refNoCompany location only: the id of the registry hit the address was read from
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
errorNo
parentNo
channelNo
successYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / registry_ref
      Added value: +{
      +  "description": "Company location only: the id of the registry hit the address was read from",
      +  "maxLength": 2000,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / draft_party
      Added value: +{
      +  "description": "Set on an invoice draft: the call is refused unless the parent is this party of the draft",
      +  "properties": {
      +    "invoice_id": {
      +      "description": "UUID of the invoice draft being worked on",
      +      "format": "uuid",
      +      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +      "type": "string"
      +    },
      +    "party": {
      +      "description": "receiver = the draft's customer; issuer = the company that issues it",
      +      "enum": [
      +        "receiver",
      +        "issuer"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "invoice_id",
      +    "party"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  4. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • addedOutput schema / properties / newly_connected
      Added value: +{
      +  "description": "Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "type": "string"
      +      },
      +      "service_id": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "service_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  6. Changed4 schema fields changed
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_note
      Added value: +{
      +  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_source
      Added value: +{
      +  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
      +  "enum": [
      +    "host_meta",
      +    "argument",
      +    "minted"
      +  ],
      +  "type": "string"
      +}
  7. Changed9 schema fields changed
    • addedInput schema / properties / value / properties / address_line1 / maxLength
      Added value: +255
    • addedInput schema / properties / value / properties / address_line2 / maxLength
      Added value: +255
    • addedInput schema / properties / value / properties / city / maxLength
      Added value: +255
    • addedInput schema / properties / value / properties / country / maxLength
      Added value: +2
    • addedInput schema / properties / value / properties / e164_number / maxLength
      Added value: +255
    • addedInput schema / properties / value / properties / email / maxLength
      Added value: +320
    • addedInput schema / properties / value / properties / postal_code / maxLength
      Added value: +255
    • addedInput schema / properties / value / properties / region / maxLength
      Added value: +255
    • addedInput schema / properties / value / properties / url / maxLength
      Added value: +255
  8. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Target workspace. Omit to use the only authorized workspace, or (for read tools) to query all authorized workspaces grouped by workspace. Required for write tools when the token authorizes more than one workspace."New value: +"Target workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which."
  9. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare a non-read-only, non-destructive, closed-world write. The description adds substantial context: refusals are atomic ('nothing written'), phone is unsupported on a company and errors clearly, a leading '+' is normalized onto phone numbers, label/platform default to 'work'/'website', and the draft/registry guardrails are spelled out. This is precisely the behavior an agent needs before attempting the write.

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?

Purpose is front-loaded and the bulleted channel mapping is scannable and waste-free. The draft_party paragraph is a dense multi-clause sentence that partly restates the schema's own description of that parameter, costing some readability without adding much new information.

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 10-parameter tool with nested objects and an output schema, the description covers every decision point an agent faces: which value fields to fill per channel, when registry_ref or draft_party applies, the unsupported company-phone combination, and where to go to read. Return values are covered by the output schema, so no 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?

Schema coverage is 100%, so the schema already documents field meanings and defaults. The description still adds value by presenting the channel→value-field mapping as a compact contract and by disclosing the automatic '+' prefixing for E.164 numbers, which the schema does not mention. It largely mirrors the schema for label/platform defaults, so it sits just above the baseline rather than far above it.

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?

Opening sentence gives a specific verb and resource ('Add a contact channel to a company or person') and is immediately followed by the exact REST endpoints it wraps. It also differentiates from siblings by naming well_query_records as the tool for reading existing channels.

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?

Goes well beyond naming alternatives: it specifies when to pass registry_ref (only for an address read from a registry hit), when to pass draft_party ('receiver' vs 'issuer' on an invoice draft), and the exact refusal conditions for each. It also states the fallback rule for ambiguous draft conversations ('ask them in one line first') and routes reads to well_query_records.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources