Client retainers held on account: record one, draw it down against invoices, refund it.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 11 tools
Each tool targets a distinct action on deposits: apply, balance, delete, list, record, refund, report, statement (pdf/text), and license management. There is no meaningful overlap; even similar tools like balance vs report or list vs statement have clearly different purposes and outputs.
Most deposit tools follow a consistent 'deposit_<verb/noun>' pattern, but 'deposits_report' uses a plural prefix, and license tools use a separate 'license_' prefix. The deviation is minor and does not hinder readability.
11 tools is well-scoped for a deposit management domain, covering lifecycle actions (record, apply, refund, delete) and reporting (balance, report, statements) without excess. The license tools add necessary meta-management without bloat.
The tool surface covers core deposit workflows: recording, applying, refunding, listing, balancing, reporting, and generating statements. A notable gap is the absence of a tool to edit/correct an existing deposit after it has moved money, though the delete tool partially covers correction for untouched deposits.
Apply part of a held deposit to one invoice: it records that amount as a PAYMENT through the invoice server. amount_minor defaults to the lesser of held and owed. More than either, or a pre-arrival date, is refused.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Deposit id such as DEP-2026-0001, or an exact client name | |
| date | No | YYYY-MM-DD, the day the deposit was set against the invoice. Defaults to today | |
| note | No | Free text kept on the application row | |
| invoice | Yes | The invoice number to apply it to, e.g. INV-2026-0001 | |
| amount_minor | No | How much of the deposit to apply, in minor units. Defaults to the smaller of what is held and what the invoice still owes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a mutating (readOnlyHint=false), non-idempotent operation, and the description adds what gets created ('a PAYMENT through the invoice server') and two rejection conditions (over-application, pre-arrival dates). This goes beyond the boolean hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences around 45 words: purpose and effect first, then default behavior, then failure conditions. Every sentence carries distinct information, and nothing merely echoes the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 5 parameters are documented in the schema and the behavioral contract — effect, defaults, and preconditions — is stated. The main gap is that with no output schema, the description could say what the call returns on success, but this does not seriously impede correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds one schema-missing constraint — the pre-arrival date refusal for the date parameter — but restates amount_minor's default that the schema already documents. It complements the schema without meaningfully extending it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Apply'), resource ('a held deposit to one invoice'), and the downstream effect ('records that amount as a PAYMENT'). This distinguishes it from sibling operations like deposit_record (recording money in) and deposit_refund (returning held money), and 'part of' clarifies it handles partial application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first clause conveys the exact scenario for use: applying part of a held deposit to a single invoice. The refusal conditions ('More than either, or a pre-arrival date, is refused') delimit invalid uses. However, it never names sibling tools or states when to prefer deposit_refund or deposit_record, so it stops short of explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer "how much of theirs am I holding?" for one client or everyone: received, applied to invoices, refunded and still held, one row per currency, never added across them. Reads only; deposit_list shows each deposit.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | YYYY-MM-DD, count only deposits received on or before this day | |
| client | No | Client id, exact name or a name containing this text. Leave out for every client |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says 'Reads only,' but the annotations declare readOnlyHint: false. This is an annotation contradiction: an agent cannot trust whether the tool mutates state or not. The aggregation behavior and per-currency warning are helpful, but the contradiction dominates this dimension.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core question, the aggregation components, the currency constraint, and the key sibling distinction. There is no filler, and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does a good job explaining the return shape: one row per currency, with received, applied, refunded, and still-held components. It also warns against summing across currencies. The only notable gap is the read-only contradiction, which affects trust rather than completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents as_of and client. The description adds some interpretation, such as 'one client or everyone' for the client parameter and the no-cross-currency aggregation rule, but it does not add substantial parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly answers a specific client question: 'how much of theirs am I holding?' and describes the resource as aggregated client-held funds across received, applied, refunded, and still-held amounts. It also distinguishes itself from deposit_list by emphasizing balance aggregation rather than individual deposits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for one client or everyone and for aggregate balances, and explicitly names deposit_list as the alternative that shows each individual deposit. It does not fully enumerate all sibling alternatives, but the core read-vs-detail distinction is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a deposit that never moved money, freeing that month's free-tier slot. One with anything applied or refunded is refused, naming it, since a payment or refund would be left with nothing behind it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Deposit id such as DEP-2026-0001, or an exact client name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds meaningful beyond-annotation context: deletion is refused if anything was applied or refunded, with a rationale about leaving payments/refunds with nothing behind them. It also explains the consequence of freeing the month's free-tier slot, which is not inferable from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the action, then give the safety condition and rationale in minimal words. There is no repetition of schema or annotation content and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool with annotations covering destructive behavior and 100% parameter schema coverage, the description provides the essential business logic: when deletion is valid, when it will be refused, why it is refused, and what the deletion accomplishes. Nothing critical is missing for an agent to decide whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter is fully described in the schema as a deposit ID or exact client name. The tool description does not add any extra parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete a deposit') and narrows scope with a precise condition ('that never moved money'). It clearly distinguishes the tool from siblings like deposit_record and deposit_refund by its deletion intent and safety restriction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use condition (only deposits that never moved money) and a clear when-not condition (anything applied or refunded is refused). However, it does not name an alternative tool such as deposit_refund for the refused cases, so it stops short of fully routing the agent to the correct fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deposits newest first: DEP number, client, kind, date, reference and what was received, applied, refunded and still held, with the same four totalled per currency. Filter by client, status, kind, date.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD, latest received date | |
| from | No | YYYY-MM-DD, earliest received date | |
| kind | No | Default "all" | |
| client | No | Only deposits for this client id, exact name, or a name containing this text | |
| status | No | Default "all". held means some of the money is still held |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds useful behavioral details: the ordering (newest first) and the output structure (fields and totals per currency). It doesn't add side-effect warnings, but none are needed given the annotations. It does go beyond annotations by specifying the output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one dense, information-rich sentence. It front-loads the core action ('List deposits newest first') and then packs in the output fields and filtering options without any filler. Every clause earns its place, and the structure is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential return values (fields and currency totals) and the ordering, which is sufficient for a read-only list tool. It does not mention pagination, result limits, or whether all matching deposits are returned, but given the absence of an output schema and the simple nature of the tool, this is a minor gap. The annotations cover safety, so the overall context is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, with each parameter having a descriptive comment (e.g., 'YYYY-MM-DD, latest received date' for 'to' and a detailed note for 'client'). The description merely mentions 'Filter by client, status, kind, date' without adding any new semantics or examples. Since the schema already documents all parameters, the description adds no extra value here, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'deposits' and immediately specifies the output fields (DEP number, client, kind, date, reference, and the four amounts) plus the ordering ('newest first'). This clearly distinguishes it from sibling tools like deposit_balance (which likely gives balances) or deposit_statement_text (which likely produces a statement), so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the filtering options (client, status, kind, date) which implies when to use it for listing deposits, but it does not explicitly mention when not to use it or point to alternatives. It does not say 'use deposit_balance for totals' or 'use deposit_statement_text for a formatted statement', leaving the agent to infer the use case from the tool's name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a security or retainer deposit received from a client, in minor units, with its currency, the date it arrived and the bank reference. Returns the DEP-YYYY-NNNN id.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | security: held against damage or non-payment. retainer: held against work not yet invoiced | |
| notes | No | Free text kept on the record and printed on the statement | |
| client | Yes | Client name or client id. A name the invoice server already knows brings its address, email and VAT id onto the deposit | |
| currency | No | Defaults to your business default currency | |
| reference | No | Bank reference, transfer note or cheque number the money arrived with | |
| amount_minor | Yes | What was received, in MINOR units: 50000 = 500.00 EUR, 50000 = JPY 50000. Never a decimal | |
| client_email | No | Only if the user gave it; otherwise the stored client's email is used | |
| client_vat_id | No | Client VAT / tax registration id | |
| received_date | No | YYYY-MM-DD, the day the money arrived. Defaults to today | |
| client_address | No | Postal address for the statement's client block, newlines allowed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is a mutating, non-read-only action and that it is not idempotent. The description adds the useful fact that it returns a DEP-YYYY-NNNN id, but it does not disclose downstream effects such as how the deposit affects balances or statements. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core action and then immediately gives the most important return detail, the DEP-YYYY-NNNN id. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully self-describing 10-parameter schema, annotations for mutating behavior, and no output schema, the description covers the essential outcome and return ID. It is slightly thin on downstream effects and selection guidance, but for creating a record it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries the full burden of documenting the 10 parameters. The description adds high-level context by naming minor units, currency, arrival date, and bank reference, but it does not add parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb ('Record') and resource ('security or retainer deposit received from a client'), enumerates the key fields (minor units, currency, date, bank reference), and mentions the resulting DEP-YYYY-NNNN id. This clearly distinguishes it from siblings like deposit_apply, deposit_refund, and deposit_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives such as deposit_apply, deposit_refund, or deposit_list. The only implied context is that it is for recording a newly received deposit, which is not enough guidance to prevent an agent from confusing it with related deposit operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give part or all of a held deposit back to the client, with the date and how it was sent. Refuses more than is still held. The invoice server is not touched: a refund is not a payment.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Deposit id such as DEP-2026-0001, or an exact client name | |
| date | No | YYYY-MM-DD, the day the money went back. Defaults to today | |
| note | No | Free text kept on the refund row | |
| method | No | How it was sent, e.g. "bank transfer to the account it came from". Printed on the statement | |
| amount_minor | No | How much to give back, in minor units. Defaults to everything still held |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral detail beyond the annotations: it enforces a hard limit with 'Refuses more than is still held' and clarifies an external side-effect boundary with 'The invoice server is not touched: a refund is not a payment.' These are exactly the kind of constraints an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver the purpose first, then the key constraint and the external-boundary clarification. There is no filler, and every sentence contributes to correct tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description is complete: it covers partial/full refunds, over-refund refusal, recording date and method, and isolation from the invoice server. An agent has enough context to decide when to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description mentions 'part or all' and 'the date and how it was sent,' which aligns with amount_minor, date, and method, but it adds no new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific operation—'Give part or all of a held deposit back to the client'—with a clear resource and scope. It distinguishes the tool from payment-related actions by noting 'a refund is not a payment,' which helps separate it from deposit_apply and invoice concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the core use case: returning money from a held deposit. However, it does not explicitly name sibling alternatives or state when not to use this tool. The 'not a payment' caveat hints at boundaries, but the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The deposit book at a date: held per currency, received, applied and refunded, the oldest holdings with days held, and every deposit older than N days with nothing applied. Pro; deposit_balance is free.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | YYYY-MM-DD to count from. Defaults to today | |
| limit | No | How many oldest held deposits to list. Default 10 | |
| older_than_days | No | Flag deposits received this many days ago or more with nothing applied. Default 90 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context about report contents and as-of/age-based selection, but it does not mention output shape, pagination, or Pro-access implications beyond the cryptic 'Pro' note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is one dense, front-loaded sentence that conveys the report's scope efficiently. The final 'Pro; deposit_balance is free' is a bit cryptic and could be clearer, but it does not add significant bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only report with three optional, fully documented parameters and no output schema, the description covers the essential content and selection behavior. It lacks a clear mention of the return format, but the listed output sections are likely sufficient for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description maps all three parameters to report sections: 'at a date' maps to as_of, 'oldest holdings' to limit, and 'older than N days with nothing applied' to older_than_days. This helps an agent connect parameter values to the resulting report without opening the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies exactly what is reported—held per currency, received, applied and refunded, oldest holdings, and stale unapplied deposits—so an agent knows this is a deposit-book report. It does not use an explicit verb like 'generates' and only hints at sibling differentiation via 'deposit_balance is free,' so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to choose deposits_report over deposit_balance, deposit_list, or deposit_statement_text. The 'Pro; deposit_balance is free' note implies a pricing/alternative relationship, but it does not explain when one should be selected instead of the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool to render one client's A4 deposit statement and return a download link valid for one hour. Titled DEPOSIT STATEMENT, every movement in date order, closing with what is still held. Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | YYYY-MM-DD printed as the statement date. Defaults to today | |
| client | Yes | Client id, exact name or a name containing this text | |
| currency | No | Only needed when the client has deposits in more than one currency | |
| out_path | No | Name for the downloaded file, e.g. acme-deposits. Defaults to the client and currency; the statement comes back as a download link valid for one hour |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's safety burden is low. It meaningfully adds that the tool returns a temporary download link valid for one hour, that the document is titled DEPOSIT STATEMENT, and that movements appear in date order with a closing balance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and each key clause conveys needed information about invocation and return format. The trailing 'Pro.' is cryptic and adds little, which prevents a 5, but the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only and idempotent annotations plus complete schema coverage, the description covers the main missing piece: the output is a one-hour download link. It does not address error cases, multi-match client resolution, or permission requirements, but those are not essential for a basic correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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; the schema already documents as_of, client, currency, and out_path. The description reinforces that one client is targeted and that the result is a link rather than a file, but it does not add meaningful details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific deliverable — one client's A4 deposit statement rendered as a PDF with a download link — and the PDF return clearly distinguishes it from siblings like deposit_statement_text. The verb 'render' plus the resource and format is concrete and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a positive directive ('Call this tool to render...') and clarifies the single-client scope, which helps the agent avoid multi-client report tools. However, it never explicitly contrasts with deposit_statement_text, deposits_report, or other siblings, nor explains when the text variant should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn one client's deposits into a plain-text statement to paste into an email: every movement in date order and the closing balance held. Pass currency when they have more than one. Also a .txt download link valid one hour. Free on every tier.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | YYYY-MM-DD printed as the statement date. Defaults to today | |
| client | Yes | Client id, exact name or a name containing this text | |
| currency | No | Only needed when the client has deposits in more than one currency | |
| greeting | No | Opening line, default "Hello" plus the client name | |
| sign_off | No | Closing line, default your business name from the shared profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds meaningful behavioral details beyond that: all movements are included in date order, the .txt download link is valid for one hour, and the tool is free on every tier. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, each adding distinct value: the core purpose, the currency guidance, and the download-link behavior. Information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only text-generation tool with fully documented parameters and no output schema, the description sufficiently explains the result (plain-text statement), its content, and the temporary download link. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the currency condition but adds no new parameter semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation: converting one client's deposits into a plain-text statement in date order with the closing balance. This clearly differentiates it from siblings like deposit_statement_pdf and deposits_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use: when a plain-text statement is needed to paste into an email, and when to pass currency. It does not explicitly mention alternatives or when not to use this tool, but the intended scenario is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
deposit_applydeposit_balancedeposit_deletedeposit_listdeposit_recorddeposit_refunddeposit_statement_pdfdeposit_statement_textdeposits_reportlicense_activatelicense_statusSecurity and retainer deposits per client: hold, apply to an invoice, refund, statement.
Double-entry bookkeeping: accounts, journal entries, bank feeds, reconciliation, and reports.
Accounting for German SMBs: invoices, clients, bank transactions, journal entries, VAT.
Calculate sales tax & VAT, record transactions and refunds, manage products and customers.
Add one secure layer between your agents and this server.
