Look up invoices, estimates and clients in your Invoice Mama account, see what's unpaid or overdue, and create unsent invoice and estimate drafts from Claude, ChatGPT, Cursor and other AI tools.
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 8 tools
Most tools have distinct resource+action purposes, but list_recent_invoices (which can narrow by status or customer) overlaps noticeably with list_unpaid_invoices and list_overdue_invoices, so an agent may hesitate between them.
All eight tools follow a clean verb_noun pattern (create_draft_*, find_*, get_invoice, list_*), with consistent snake_case and no deviations.
Eight tools is well-scoped for an invoicing/estimating server, with each tool covering a distinct operation and none appearing redundant.
Create/find/get/list coverage exists for invoices, but there is no way to create or update clients, no get_estimate or get_client, and no send/mark-paid/update/delete operations for the core invoicing lifecycle.
Save a draft estimate for a customer who is already in this business. It is not sent. Open the link to review it.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| notes | No | ||
| title | No | ||
| clientId | Yes | ||
| currency | No | ||
| issueDate | No | ||
| expiryDate | No | ||
| idempotencyKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description usefully adds that the estimate is not sent and that a review link is returned, which is genuine behavioral context, but it says nothing about permissions, idempotencyKey handling, or what happens on repeat calls.
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, front-loaded sentences with no filler. Slightly informal phrasing ('Open the link to review it') but every sentence carries 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?
With 8 parameters at 0% schema coverage, no output schema, and nested item objects, the definition is under-specified. It omits any explanation of the line-item structure, date/currency semantics, or the idempotency key that a mutation tool of this complexity needs.
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 0% across 8 parameters, so the description must carry the burden and largely does not. Only the clientId requirement is implied ('customer who is already in this business'); items, notes, currency, issueDate, expiryDate, and idempotencyKey are left entirely unexplained.
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 (save) and resource (draft estimate) plus a scoping condition ('for a customer who is already in this business'). This implicitly separates it from the sibling create_draft_invoice, though it never names the sibling or explicitly contrasts the two.
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 phrase 'for a customer who is already in this business' hints at a prerequisite (the client must already exist, e.g. via find_clients) and 'It is not sent' hints at the draft vs. send distinction. However, no alternative tool is named and no explicit when-to-use/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a draft invoice for a customer who is already in this business. It is not sent, and it is not marked paid. Open the link to review it.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| notes | No | ||
| title | No | ||
| dueDate | No | ||
| clientId | Yes | ||
| currency | No | ||
| issueDate | No | ||
| idempotencyKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully clarifies the resulting state ('not sent, not marked paid') and hints that a review link is returned, which matters since there is no output schema, but it says nothing about idempotency semantics for idempotencyKey or any permission requirements.
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, front-loaded with the core action and its scope. The state clauses ('not sent, not marked paid') earn their place by preventing incorrect assumptions about side effects, though the phrasing is a bit repetitive.
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 an 8-parameter mutation tool with 0% schema description coverage and no output schema, the description is far too thin. It omits required-parameter expectations (items structure with description/quantity/unitPrice), currency handling, date semantics, and idempotency behavior — all things an agent needs to invoke this 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?
Schema description coverage is 0% across 8 parameters, so the description carries the full burden and largely fails it. Only clientId is obliquely addressed via 'a customer who is already in this business'; items, currency, dates, notes, and especially idempotencyKey get no explanation at all.
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 verb and resource ('Save a draft invoice') and adds a scope condition ('for a customer who is already in this business'). It does not explicitly distinguish itself from the nearest sibling, create_draft_estimate, so it stops 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?
The phrase 'for a customer who is already in this business' implies a precondition (the client must already exist) and by extension the find_clients flow. However, there is no explicit when-to-use guidance or direction to the alternative create_draft_estimate for estimates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search customers by name, email, or phone for the business you picked.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that the search spans name, email, and phone; it says nothing about result limits, pagination, or what happens when no match is found.
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?
One sentence, front-loaded with the verb and resource, with the scoping qualifier at the end. 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 simple read-only single-parameter search with no output schema, the description covers purpose, matched fields, and the business scope. Missing only result-set behavior (limits or empty-result handling), which is a minor gap for this tool's complexity.
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 0%, so the description must carry the burden for the single `query` parameter. It does clarify that the query can match name, email, or phone, which is real added meaning, but gives no guidance on matching semantics (fuzzy vs. exact, multi-field strings, formatting).
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 (search) and resource (customers) plus the fields that can be matched (name, email, phone), so an agent knows exactly what the tool does. It does not explicitly differentiate itself from find_estimates or the other lookup siblings, but the resource is 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 phrase "for the business you picked" implies a required prior selection of a business context, which is useful scoping guidance. However, it never states when to prefer this tool over find_estimates or the list_* siblings, nor any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search estimates by number, title, or customer for the business you picked.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the session-scoping constraint (the current business), which is useful, but says nothing about matching semantics (exact vs substring), result caps, or ordering.
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?
A single sentence with the searchable fields front-loaded and zero filler. Nothing could be removed without losing 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 one-parameter, read-only search tool with no output schema and annotations covering safety, the description is nearly sufficient: it covers purpose, match fields, and scoping. Only the result-set behavior (limits, ordering, exactness of match) is left unstated.
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 0%, so the description carries the full burden for the single 'query' parameter, and it does add real meaning by stating that the query matches number, title, or customer. It still omits whether matching is partial/fuzzy or case-sensitive, which would be the remaining useful detail.
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?
Names a specific verb (search) and resource (estimates) and lists the three searchable fields (number, title, customer). It distinguishes itself from the list_* siblings by being a query-driven lookup, though it never explicitly contrasts itself with find_clients or the list tools.
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?
'for the business you picked' implies a prerequisite (a business must already be selected) and the presence of a query implies the search use case, but there is no explicit when-to-use versus alternatives such as list_recent_invoices or find_clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open one invoice, including line items and the pay link when one is ready.
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — the pay link is conditional ('when one is ready') — but says nothing about auth scope, not-found behavior, or pagination.
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?
One front-loaded sentence with no filler; the payload contents are stated immediately. 'Open' is a slightly loose verb for a read-only retrieval, but nothing is wasted.
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 must describe returns and it does so partially (line items, conditional pay link). For a low-complexity one-parameter read whose annotations cover safety, this is adequate, but the identifier format and error/not-found behavior remain unaddressed.
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 single invoiceId parameter has 0% schema description coverage, so the description carries the burden and does not meet it: it never states the identifier's format, source, or whether it accepts the invoice number vs an internal ID. 'Open one invoice' only restates that an identifier is needed.
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 and resource ('Open one invoice') and enumerates the payload ('line items and the pay link'), which separates it from the list_* siblings that return collections. It does not name an alternative, but the singular scope is 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?
There is no when-to-use statement, no prerequisite (e.g. where invoiceId comes from), and no routing away from list_overdue_invoices/list_recent_invoices/list_unpaid_invoices or find_estimates. Usage is only weakly implied by 'one invoice'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See invoices that are past their due date for the business you picked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the definition of 'overdue' (past due date) and no ordering, pagination, date-range, or inclusion rules, so it contributes modest extra context.
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?
A single short sentence that front-loads the resource and its filter with no filler. It is efficient, though it is arguably under-specified rather than genuinely concise.
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 annotations covering the read-only safety profile and an empty input schema, the core mechanics are adequately conveyed. The missing piece is routing: nothing tells the agent how this differs from list_unpaid_invoices or list_recent_invoices.
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 tool takes zero parameters, so per the baseline the schema needs no compensating explanation. The phrase 'the business you picked' references ambient context rather than any documented input, which is mildly ambiguous but not a true parameter gap.
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 resource (invoices) and a scope qualifier (past their due date), so the filter is clear. However, it never differentiates itself from the sibling list_unpaid_invoices, which an agent could easily confuse with 'overdue' since the two filters overlap but are not identical.
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 when-to-use guidance, no mention of alternatives (list_unpaid_invoices, list_recent_invoices), and no stated conditions for choosing this tool. The trailing phrase 'for the business you picked' hints at an implicit selected-business context but does not explain how or when that context is set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See the newest invoices for the business you picked. You can narrow them by status or customer.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| status | No | ||
| clientId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context (results are ordered by recency and scoped to the selected business) but says nothing about default page size, limits, or whether the 'query' parameter is free-text search.
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 short sentences, front-loaded with the core action, and no filler. Some of the limited space is spent on the vague phrase 'the business you picked' instead of the undocumented limit/query parameters.
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?
A simple four-parameter read tool with no required params and no output schema, so return-value explanation is not needed. However, ordering, default result count, and the purpose of the query and limit parameters are all unstated, which leaves meaningful gaps for an agent to guess at.
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 0%, so the description must carry the parameter burden, yet it only loosely maps 'status' and 'customer' to the status and clientId parameters. The limit and query parameters are never explained, leaving half the parameters undocumented in both schema and description.
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 concrete verb+resource ('See the newest invoices') and adds scope ('for the business you picked'), which lets an agent distinguish it from get_invoice or the create_* siblings. It does not explicitly distinguish itself from list_overdue_invoices/list_unpaid_invoices, which are the closest alternatives.
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?
Usage is only implied: the tool lists the newest invoices, so it is the general listing entry point versus the filtered list_overdue_invoices/list_unpaid_invoices siblings. No when-to-use, when-not-to-use, or alternative is named, so the agent must infer routing from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See invoices that still have a balance for the business you picked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the scoping semantics of "unpaid" (a non-zero balance) and hints at an implicit business context, but says nothing about ordering, result limits, or pagination.
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?
One short sentence, front-loaded with the verb and resource, with no filler. The trailing clause "for the business you picked" is the only slightly murky element, but it does not bloat the text.
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 zero-parameter read-only list tool with annotations covering safety and no output schema, this is nearly adequate. The gap is that the business scope is referenced but never explained, and ordering/limits are unstated, so an agent cannot fully predict what it will get back.
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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. "The business you picked" gestures at implicit session context but cannot be acted on through any parameter, so it adds no actionable parameter meaning.
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 gives a specific verb ("See") and resource ("invoices") qualified by a real condition ("still have a balance"), which effectively defines what "unpaid" means. It does not, however, distinguish itself from sibling list_overdue_invoices or list_recent_invoices, which an agent could easily confuse it with.
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 when-to-use or when-not-to-use guidance, and no mention of alternatives such as list_overdue_invoices or list_recent_invoices. The phrase "for the business you picked" implies a prior selection context but never states how or where that selection happens, leaving usage ambiguous.
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.
create_draft_estimatecreate_draft_invoicefind_clientsfind_estimatesget_invoicelist_overdue_invoiceslist_recent_invoiceslist_unpaid_invoices
Add one secure layer between your agents and this server.