Skip to main content
Glama
Sign In

Osome

by com.osome.mcp
OverviewDiscussionsAdmin

list-transaction-cashcoding-recommendations

Read-only

Ask Osome's model which account to cashcode a bank transaction to. It ranks the accounts clients can use in the company's jurisdiction from the transaction's description, amount, direction and contact, plus any description or vendorName you pass. Returns suggestions, best first, each with accountId, name, source and accuracy (the model's confidence); the list can be empty. Apply one with apply-transaction-cashcoding-recommendation, or if none fits, explain the transaction with add-transaction-comment.

Input Schema

NameRequiredDescriptionDefault
topKNoHow many recommendations to return: 1 or 3 (default 3). 2 makes the call fail.
companyIdYesCompany ID, as returned by list-companies
vendorNameNoWho was paid or who paid, such as a merchant name. The model uses it to rank accounts.
descriptionNoWhat the transaction was for, such as client lunch or software subscription. The model uses it to rank accounts.
transactionIdYesNumeric acDocumentId of the transaction, as returned by search-transactions (transaction.acDocument.id in Websome)
vendorContactIdNoAccepted but not used to rank accounts; pass vendorName instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / companyId / description
      Previous value: -"Company ID"New value: +"Company ID, as returned by list-companies"
    • changedInput schema / properties / description / description
      Previous value: -"Optional transaction purpose/description to improve recommendations"New value: +"What the transaction was for, such as client lunch or software subscription. The model uses it to rank accounts."
    • changedInput schema / properties / topK / description
      Previous value: -"Number of account recommendations to return, 1 to 3, default 3"New value: +"How many recommendations to return: 1 or 3 (default 3). 2 makes the call fail."
    • 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)"
    • changedInput schema / properties / vendorContactId / description
      Previous value: -"Optional existing accounting contact ID for the vendor"New value: +"Accepted but not used to rank accounts; pass vendorName instead."
    • changedInput schema / properties / vendorName / description
      Previous value: -"Optional vendor name to improve recommendations"New value: +"Who was paid or who paid, such as a merchant name. The model uses it to rank accounts."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish that this is a read-only, non-destructive, non-open-world operation, and the description adds useful behavior: suggestions are returned best first, each includes accountId, name, source, and accuracy confidence, and the list can be empty. This covers the return variability and output shape that matter for an agent deciding how to act. No annotation contradiction is present.

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?

The description is front-loaded with the core action, followed by ranking inputs, return shape, and downstream alternatives. Every sentence contributes useful information, and there is no redundant restatement of the tool name or annotations.

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?

There is no output schema, but the description explains the return structure and that the list may be empty. Annotations cover the safety profile, and the 100%-covered input schema documents all six parameters. The definition gives an agent everything needed to invoke and interpret the tool.

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 the baseline is 3 even without extra parameter detail in the description. The description reinforces that description and vendorName are ranking inputs, but the schema already documents those same roles and additionally covers topK constraints and the vendorContactId caveat. The description adds little semantic value beyond 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?

The description states a specific verb and resource: asking Osome's model which account to cashcode a bank transaction to, and returning ranked account recommendations. It distinguishes the operation from downstream siblings by naming apply-transaction-cashcoding-recommendation and add-transaction-comment. An agent can tell what this tool does without opening the 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?

The description explicitly says to apply a recommendation with apply-transaction-cashcoding-recommendation and to use add-transaction-comment when none fits. It also clarifies that the optional description and vendorName can be passed to influence ranking. The when-to-use and alternative paths are stated rather than inferred.

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

All Osome toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources