Skip to main content
Glama

Define a customer

well_define_customer
Idempotent

Define one company or one private individual as a customer of this workspace: records that the workspace's own company bills it.

REQUIRED: entity_id and entity_kind, both from a row of well_list_customers, or from the company or person you just created for the customer. Pass the row's customer_kind too: "person" for a private individual (a person record), "company" for a company record. Call it only after the user chose that row on the card; never pick a customer from a name alone. A registry row's entity_id adds the company to the workspace first, then defines it.

The write is idempotent: defining a customer that is already defined succeeds with created: false. It never edits the company itself, and it refuses the workspace's own company. To bill the customer, pass the returned entity_id as the invoice's receiver company_id when customer_kind is "company", or as the receiver person_id when it is "person".

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
entity_idYesThe `entity_id` of a `well_list_customers` row.
entity_kindYesThe row's `entity_kind`, stated rather than inferred.
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.
customer_kindNoThe record `entity_id` names: "company" or "person". Left out, it names a company record.
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
createdNo
successYes
customerNo
error_reasonNo
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.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
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. Changed2 schema fields changed
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed3 schema fields changed
    • addedInput schema / properties / customer_kind
      Added value: +{
      +  "description": "The record `entity_id` names: \"company\" or \"person\". Left out, it names a company record.",
      +  "enum": [
      +    "company",
      +    "person"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / customer / properties / customer_kind
      Added value: +{
      +  "enum": [
      +    "company",
      +    "person"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / customer / required
      Previous value: -[
      -  "entity_id",
      -  "entity_kind",
      -  "name"
      -]New value: +[
      +  "entity_id",
      +  "entity_kind",
      +  "customer_kind",
      +  "name"
      +]
  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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the idempotent success shape (`created: false`), the side effect that a registry row's entity_id adds the company before defining it, the hard refusal of the workspace's own company, and the guarantee that it never edits the company itself. Annotations only say idempotent/non-destructive; the description supplies the operational semantics an agent needs.

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?

Front-loads purpose, then required inputs, then behavior, then workspace routing — a sensible order with no filler sentences. Slightly padded by the trailing workspace paragraph, which largely restates the workspace_id schema text, and the odd phrasing 'this read will not guess' for a write tool.

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?

An output schema exists, so return values need no explanation, yet the description still tells the agent how to consume the returned entity_id (as invoice receiver company_id or person_id). Combined with idempotency, refusal behavior, and workspace scoping, nothing needed to call it correctly is missing.

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; the description adds real meaning by tying entity_kind to a specific source ('the row's entity_kind, stated rather than inferred') and instructing that the row's customer_kind be passed alongside, which is a distinction the schema alone states without explaining. It leaves the entity_kind vs. customer_kind divergence only partly explained.

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?

States a specific verb and resource ('Define one company or one private individual as a customer of this workspace') and adds the exact business meaning ('records that the workspace's own company bills it'). This distinguishes it from well_list_customers (discovery), well_create_company/well_create_person (creation), and well_issue_invoice (billing).

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?

Explicit prerequisites and exclusions: call only after the user chose that row on a card, never pick a customer from a name alone, and source entity_id/entity_kind from a well_list_customers row or a just-created company/person. It also gives routing guidance for the workspace ambiguity case (single-workspace token vs. multiple).

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