Skip to main content
Glama

get-transaction-conversation

Read-only

Read the comments on one transaction, oldest first. Returns conversation (read and answered state, last message times) and messages, each with text, createdAt and a sender showing whether an Osome agent or bot wrote it. Without filters you get the latest 50; to page back, pass the oldest createdAt you have as createdBefore. A transaction with no comments returns conversation null. Use add-transaction-comment to post, and search-transactions to find the transactionId.

Input Schema

NameRequiredDescriptionDefault
limitNoMost comments to return, 1 to 100 (default 50). When set, totalCount counts every matching comment instead of only those returned.
companyIdYesCompany ID, as returned by list-companies
createdAfterNoISO 8601 date-time, such as 2026-10-21T09:00:00Z. Returns the earliest comments created after it instead of the latest. Cannot be combined with createdBefore.
createdBeforeNoISO 8601 date-time. Returns the latest comments created before it; pass the oldest createdAt you have to page back. Cannot be combined with createdAfter.
transactionIdYesNumeric acDocumentId of the transaction, as returned by search-transactions (transaction.acDocument.id in Websome)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / companyId / description
      Previous value: -"Company ID"New value: +"Company ID, as returned by list-companies"
    • changedInput schema / properties / createdAfter / description
      Previous value: -"Only comments created after this ISO timestamp"New value: +"ISO 8601 date-time, such as 2026-10-21T09:00:00Z. Returns the earliest comments created after it instead of the latest. Cannot be combined with createdBefore."
    • changedInput schema / properties / createdBefore / description
      Previous value: -"Only comments created before this ISO timestamp"New value: +"ISO 8601 date-time. Returns the latest comments created before it; pass the oldest createdAt you have to page back. Cannot be combined with createdAfter."
    • changedInput schema / properties / limit / description
      Previous value: -"Max comments to return"New value: +"Most comments to return, 1 to 100 (default 50). When set, totalCount counts every matching comment instead of only those returned."
    • changedInput schema / properties / transactionId / description
      Previous value: -"Transaction accounting document ID from Websome/Roberto transaction.acDocument.id"New value: +"Numeric acDocumentId of the transaction, as returned by search-transactions (transaction.acDocument.id in Websome)"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover only the read-only/non-destructive safety profile, and the description adds substantive behavior the agent cannot get elsewhere: the return shape (conversation plus messages with text, createdAt, sender), the default page of 50, the paging mechanism, and the null-conversation edge case for transactions without comments.

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?

Four dense sentences with no filler: what it reads, what it returns, how paging works, and where the sibling tools fit. The core action is front-loaded in the first clause.

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?

No output schema exists, yet the description describes the returned payload and its edge case (null conversation) precisely, and it covers the paging workflow for a 5-parameter tool. Nothing an agent needs to call it correctly is absent.

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% and already documents limit, createdBefore and createdAfter, so the baseline is 3; the description goes slightly further by framing createdBefore as the paging cursor ('pass the oldest createdAt you have'), but the 50 default and ISO format notes largely restate 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 ('Read the comments on one transaction') plus ordering ('oldest first') and explicitly names add-transaction-comment and search-transactions as the tools for related tasks, so it is distinguishable from every sibling 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?

Gives explicit routing advice: use add-transaction-comment to post, search-transactions to obtain the transactionId, and pass the oldest createdAt as createdBefore for paging. When-to-use and which-alternative conditions are both stated.

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