Skip to main content
Glama

explain

Read-only

State the governed US-GAAP treatment FOR A PAYMENT TYPE — a rebate, incentive, chargeback, or trade-spend payment — under ASC 606 (customer rebate / consideration payable to a customer / variable consideration), ASC 705-20 (vendor rebate), or ASC 340-40 (sales commission). It CLASSIFIES the payment and returns the governed treatment, the exact ASC citation, and the rule applied — deterministic and grounded, it will not guess and asks which payment type applies when unclear. It is NOT a free-form accounting Q&A or advisory debate: it does not argue a position, weigh a contrary opinion, or answer open questions beyond the payment-type classification (the scenario text is context only). For anything past the treatment of a payment type, run the engagement (compose/ingest the agreement, then compute).

Input Schema

NameRequiredDescriptionDefault
paymentNoThe nature of the payment. customer_rebate = you pay/credit your customer (sell side); spa_or_billback = a special pricing agreement / billback credit to the customer; chargeback = a channel chargeback / price protection; vendor_rebate = a vendor pays/credits you (buy side); internal_commission = you pay your own salesperson. Omit if unknown and the tool will return the options to choose from.
scenarioNoOptional free-text description of the user's scenario, for context.
fair_value_cap_usdNoRequired only when buys_distinct_good_or_service is true: the fair value of that distinct good/service. The payment is a purchase only up to fair value; any excess reverts to the default treatment.
buys_distinct_good_or_serviceNoTrue if the payment is in exchange for a distinct good or service the counterparty actually transfers (e.g. advertising, data, slotting with proof-of-performance), as opposed to a plain price concession. This can reclassify the treatment (ASC 606-10-32-26 / 705-20-25-2).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true/non-destructive, so this tool is safe; the description adds behavior beyond that: it is deterministic and grounded, will not guess, asks which payment type applies when ambiguous, and returns treatment + ASC citation + rule applied. The 'will not argue a position' clause sets expectations no annotation could convey.

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 purpose and standards, then the exclusions and the handoff — every sentence earns its place. Slightly penalized for ALL-CAPS emphasis and a dense run-on framing that makes it heavier to parse than necessary.

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, but the description states what is returned (governed treatment, exact ASC citation, rule applied), how ambiguity is handled, and where to go for anything beyond a payment type. Nothing an agent needs to call 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 still adds meaning: it clarifies that `scenario` text is context only and does not drive classification, and that a missing payment type yields an options prompt rather than a failure. These are useful agent-facing behaviors even though most param detail lives 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 precise verb+resource (state the governed US-GAAP treatment for a payment type) and enumerates the exact standards/classification it covers. It is unmistakably distinct from the sibling compute_* tools, which run calculations rather than explain classification.

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?

Explicitly scopes in (payment-type treatment) and out (free-form Q&A, advisory debate, open questions), and routes the agent onward: 'For anything past the treatment of a payment type, run the engagement (compose/ingest the agreement, then compute).' That names both the exclusion and the alternative workflow.

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