Skip to main content
Glama
Sign In

Osome

by com.osome.mcp
OverviewDiscussionsAdmin

apply-transaction-cashcoding-recommendation

Cashcode one bank transaction to an account. Books the full amount to accountId on the transaction date and reconciles the transaction, which then shows as reconciledWithCashCoding, awaiting review by Osome's accountants. Returns overallStatus and outcomes, or fails with the reason given, for example that it is already reconciled. Take accountId from list-transaction-cashcoding-recommendations; if no account fits, use add-transaction-comment. Needs the company:documents:write scope; rate-limited per user.

Input Schema

NameRequiredDescriptionDefault
accountIdYesaccountId of the recommendation to apply, from list-transaction-cashcoding-recommendations
companyIdYesCompany ID, as returned by list-companies
vendorNameNoContact to set when vendorContactId is not given: the company's contact with this name, or a new one. Leave both unset to keep the current contact.
descriptionNoOptional note on what the transaction was for. It isn't saved: 3 or more characters only mark the pick as guided by a description.
transactionIdYesNumeric acDocumentId of the transaction, as returned by search-transactions (transaction.acDocument.id in Websome)
vendorContactIdNoID of an existing accounting contact to set on the transaction. Takes precedence over vendorName.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / accountId / description
      Previous value: -"Recommended accounting account ID from list-transaction-cashcoding-recommendations"New value: +"accountId of the recommendation to apply, from list-transaction-cashcoding-recommendations"
    • 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 client explanation/purpose. Classic drops it once an account is picked, so it only marks the pick as description-driven."New value: +"Optional note on what the transaction was for. It isn't saved: 3 or more characters only mark the pick as guided by a description."
    • 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: +"ID of an existing accounting contact to set on the transaction. Takes precedence over vendorName."
    • changedInput schema / properties / vendorName / description
      Previous value: -"Optional vendor name to use when the transaction has no existing contact"New value: +"Contact to set when vendorContactId is not given: the company's contact with this name, or a new one. Leave both unset to keep the current contact."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag non-readOnly/non-destructive; the description adds the real behavioral payload: the full amount is booked, the transaction is reconciled and enters a reconciledWithCashCoding state awaiting accountant review, failures return a reason such as already reconciled, and it requires company:documents:write with per-user rate limits. This goes well beyond the structured hints.

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-loaded with the action and effect, then the return/failure behavior, then sourcing and prerequisites, then scope. Dense but every sentence carries information; the single-paragraph run-on is the only structural weakness.

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 covers what is returned (overallStatus and outcomes), what failure looks like and why, what state the transaction ends in, and the permissions and rate-limit constraints an agent must anticipate. Nothing an agent needs to invoke 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 workflow meaning by specifying that accountId must come from list-transaction-cashcoding-recommendations. It says nothing extra about vendorName, vendorContactId, or description, but those are already documented in 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 ('Cashcode one bank transaction to an account') plus the concrete effect: books the full amount to accountId on the transaction date and reconciles it. It also names where accountId comes from and points to the add-transaction-comment alternative, so it is clearly distinguishable from siblings.

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 routing: take accountId from list-transaction-cashcoding-recommendations, and if no account fits, use add-transaction-comment instead. That is a when-to-use plus a when-not-to-use with a named alternative.

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