Skip to main content
Glama
Sign In

McpStamp Credit Notes and Purchase Orders

by io.github.theluckystrike
OverviewDiscussionsAdmin

Credit an invoice

credit_note_create

Credit one invoice: the whole invoice, a GROSS amount_minor split over its VAT rates, or named lines. Amounts store negative, reusing the invoice's own rates. Free: 5 a month. Send it with credit_note_text.

Input Schema

NameRequiredDescriptionDefault
linesNoCredit only these invoice lines. Leave out with amount_minor for a full credit note
notesNoFree text printed under the totals
reasonYesWhy the money is being given back, e.g. "returned goods" or "billed twice". Printed on the document
invoiceYesThe invoice number to credit, e.g. INV-2026-0001
issue_dateNoYYYY-MM-DD, defaults to today in your business profile's timezone
amount_minorNoCredit this GROSS amount, VAT included, in minor units. Split across the invoice's VAT rates in proportion to each rate's share of the total

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / lines / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / lines / items / properties / line / maximum
      Added value: +9007199254740991
    • removedInput schema / properties / lines / items / properties / quantity / minimum
      Removed value: --1000000000000
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this as a non-destructive write that is not idempotent. The description adds meaningful behavioral context beyond that: amounts are stored negative, the invoice's own VAT rates are reused, and there is a free-tier limit of five per month.

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?

The description is short and front-loads the core modes before adding storage and quota details. 'Free: 5 a month' and 'Send it with credit_note_text' are abrupt but still informative rather than wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter write tool with full schema coverage and annotations, the description covers the important creation modes, rate behavior, quota, and companion workflow. It does not explain failure cases or return data, but no output schema exists and the annotations already carry the safety profile.

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 schema already explains each parameter thoroughly, including amount_minor's gross VAT-inclusive behavior and line quantity semantics. The description reinforces the mutually exclusive modes but adds little parameter meaning that the schema does not already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Credit one invoice') and enumerates three operating modes: full credit, gross amount_minor, or named lines. It distinguishes create from the text companion by saying 'Send it with credit_note_text', though it does not clarify differences from other credit-note siblings like get/list/delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly frames the three supported credit scenarios and the follow-up workflow with credit_note_text. It does not state explicit exclusions or when to choose this over sibling tools, so the guidance is strong but not complete.

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

All McpStamp Credit Notes and Purchase Orders 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