Skip to main content
Glama

Explain a transaction's category

well_get_transaction_category_rationale
Read-only

Explain why one transaction sits in its category: the provenance of the category line, read from the transaction and the classifier's receipt of it.

explanation.kind says which holds. user: a person picked the category, date is the pick. affirmed: the classifier put it there and a person confirmed it, date is the confirmation. rule: a fixed rule set it, with no date. matches_rule: the classifier put it there under the written rule as it still reads, line is that rule line verbatim and rule_source says whose text it is. rule_changed: the written rule changed after the classifier put it there, quote no line. no_rule: the classifier put it there and no written line names the category, date is the sorting. no_record: no record of the sorting is stored.

Quote line word for word and never compose a reason. Writes nothing.

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
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
transaction_idYesThe transaction's transaction_id, found with well_query_records on the transactions root.
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.
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
successYes
explanationNo
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. Changed6 schema fields changed
    • removedOutput schema / properties / explanation / properties / category / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / explanation / properties / category / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / explanation / properties / date / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / explanation / properties / date / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • 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. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/true and destructiveHint/false, and the description reinforces with 'Writes nothing'. It adds genuine behavioral value with the anti-hallucination constraint ('quote line word for word and never compose a reason') and the per-kind semantics of date/line/rule_source. Only the enumeration itself could be moved to the 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.

Conciseness3/5

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

The purpose sentence is front-loaded and strong, but the middle is a dense run of backticked kind cases that reads as prose where a list would be clearer. The closing workspace paragraph largely duplicates the workspace_id schema description and 'Writes nothing' repeats the annotations.

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?

With annotations, full schema coverage and an output schema, the definition is sufficient to invoke and interpret the call correctly. The heavy kind taxonomy is arguably the output schema's job, but its presence does not leave an agent under-informed.

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 100%, so all four parameters are already documented, including the workspace_id rule the description repeats. Coverage baseline of 3 applies; the description adds no new syntax or format detail for transaction_id, conversation_id or workspace_scope.

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 — explaining why one transaction sits in its category — and scopes it to the provenance of the category line. That is clearly distinct from well_set_transaction_category (changing it), well_update_transaction_category_rule (editing rules) and well_list_uncategorized_window.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent must infer that this is the tool for a 'why is this categorized like this' question. The final paragraph gives real invocation guidance about workspace_id, but that is covered by the schema, and no sibling alternative or when-not-to-use case is named.

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