Skip to main content
Glama

Record an expense note

well_record_expense_note
Idempotent

Record an expense note: a payment the person made with their own money for a company, which the company then owes them back. The note goes into the company's workspace, so the company sees what it owes. It writes only inside Well and sends nothing to anyone.

Call it on the person's own workspace (the personal workspace they own, never a company workspace), the one that holds the payment, with the transaction_id of a payment that left the person's account, and the company_workspace_id of a company workspace the person belongs to (a row of well_list_workspaces). Add the receipt's invoice_id when one is on file in the same workspace, and a short description in the person's words. Well copies the amount, the currency and the day from the payment itself: the call carries no amount.

Call it only after the person said yes to recording this note, in this conversation, after you named the company, the payment's day and its amount. Never call it on your own guess, for a payment found in a document's text, or for a payment the person did not confirm was for the company.

Read outcome:

  • recorded: the note is written; say so in one line with the company, the amount and the day (expense_note).

  • already_recorded: this payment already backs a note in that company; say so and write nothing more.

  • refused: nothing was written. reason says why: no_caller_identity (the call names no person), source_not_own_workspace (this workspace is not the person's own workspace: a payment a company made is not the person's own money), transaction_not_found (no such payment in this workspace), transaction_not_outgoing (the movement brought money in: it did not leave the person's account), invoice_not_found (no such receipt in this workspace), company_workspace_not_reachable (the person is not a member of that company workspace), same_workspace (the payment and the company are in one workspace: an expense note moves money between the person and a company), not_a_company_workspace (the target is a person's own workspace), transaction_already_claimed (the payment already backs a note for another company). Tell the person in one line.

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
invoice_idNoThe receipt of that payment, in the workspace of this call, when one is on file.
descriptionNoWhat the expense was, in the person's own words. Never text copied from a document.
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.
transaction_idYesThe person's own payment, in the workspace of this call.
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.
company_workspace_idYesThe company workspace that owes the money back.

Output Schema

NameRequiredDescriptionDefault
errorNo
reasonNo
outcomeNo
successYes
expense_noteNo
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
    • changedOutput schema / properties / expense_note / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "amount": {
      -        "type": "string"
      -      },
      -      "company_workspace_id": {
      -        "type": "string"
      -      },
      -      "company_workspace_name": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "currency": {
      -        "type": "string"
      -      },
      -      "description": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "expense_date": {
      -        "type": "string"
      -      },
      -      "expense_note_id": {
      -        "type": "string"
      -      },
      -      "invoice_id": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "recorded_at": {
      -        "type": "string"
      -      },
      -      "source_workspace_id": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "transaction_id": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      }
      -    },
      -    "required": [
      -      "expense_note_id",
      -      "company_workspace_id",
      -      "company_workspace_name",
      -      "source_workspace_id",
      -      "transaction_id",
      -      "invoice_id",
      -      "amount",
      -      "currency",
      -      "expense_date",
      -      "description",
      -      "recorded_at"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "amount": {
      +        "type": "string"
      +      },
      +      "company_workspace_id": {
      +        "type": "string"
      +      },
      +      "company_workspace_name": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "currency": {
      +        "type": "string"
      +      },
      +      "description": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "expense_date": {
      +        "type": "string"
      +      },
      +      "expense_note_id": {
      +        "type": "string"
      +      },
      +      "invoice_id": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "recorded_at": {
      +        "type": "string"
      +      },
      +      "source_workspace_id": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "transaction_id": {
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      }
      +    },
      +    "required": [
      +      "expense_note_id",
      +      "company_workspace_id",
      +      "company_workspace_name",
      +      "source_workspace_id",
      +      "transaction_id",
      +      "invoice_id",
      +      "amount",
      +      "currency",
      +      "expense_date",
      +      "description",
      +      "recorded_at"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. 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."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare non-read-only, non-destructive and idempotent; the description adds substantial context beyond them: it writes only inside Well and sends nothing externally, carries no amount (server copies amount, currency and day from the payment), and enumerates every outcome and refusal reason with its meaning. That is exactly the behavioral disclosure a mutating tool needs.

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

Conciseness3/5

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

Purpose, preconditions and outcome handling are front-loaded and easy to scan, but the block is roughly 350 words and the nine-refusal enumeration partly restates an output schema that already exists. There is also a small coherence slip where a write is referred to as 'this read', which adds noise without information.

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 multi-workspace, consent-gated mutation the description covers identity, workspace scoping, idempotency-adjacent behavior and post-call messaging instructions. Minor gaps remain: the relationship between the client-supplied idempotency_key and the server's `already_recorded` outcome is not spelled out, and workspace_scope semantics live only in the schema.

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 each field, and the description still adds real meaning: the transaction must be an outgoing movement that left the person's account, the company workspace must be one the person belongs to, the invoice must be on file in the same workspace, and the description text must be the person's own words. Only the conversation_id/workspace_scope interplay is left entirely to the schema.

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 ('Record an expense note') and immediately defines the object in domain terms: a payment the person made with their own money that the company owes back. It distinguishes itself from neighboring write tools (well_create_note, well_create_expense_line, well_record_claim) by naming the exact money-flow it represents, so an agent can pick it without opening a 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?

Explicit when-to-call (only after the person said yes in this conversation, after naming company, day and amount) and when-not (never on a guess, never for a payment found in document text, never for an unconfirmed payment). It also names the precondition sources (a row of `well_list_workspaces` for the company workspace) and the workspace-selection shortcut, leaving nothing to inference.

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