Reports the version of the ProAbono MCP Installation server and confirms that its ProAbono configuration is complete. Returns variable names only -- never a key, a secret or an account identifier. Use it to check the server is reachable and configured before running an installation.

Orchestrates the whole In-Site installation: detects the stack from the open project and states its hypothesis, settles the Segment, checks the four prerequisites before generating anything -- an authenticated customer area, a catalogue whose offers carry Features, how a ProAbono customer will exist for a signed-in user, and a page to host the portal -- then runs the three steps in order, Customer Portal, Subscription Workflow, rights synchronization, and records progress in .proabono/installation.json so a later session resumes instead of starting over. Call it when a developer asks to install, set up or integrate ProAbono. It installs ONE way, In-Site by code: it never offers a Widget or a plug-in, whatever the stack. It generates code and returns it; it writes no source file of yours.

Reads .proabono/installation.json in the developer's project and reports where the In-Site installation stands: which steps are done, which were generated but not yet confirmed in place, which were deliberately skipped, what was generated where, and which BackOffice actions are still pending. Call it at the start of a session before generating anything, and whenever a developer asks what is left to do. A project that has never been installed is reported as such, which is an answer and not a failure.

Generates the code that embeds the ProAbono Customer Portal inside a page of the merchant's own site -- current plan, invoices, payment method, billing address, usage -- for the signed-in customer. This is step 1 of the In-Site installation. Returns the server-side security hash computation, the route that renders the page, and the snippet to place in the template. Requires an authenticated customer area: the hosted pages always render for an identified customer.

Generates the embed that renders the ProAbono pricing table inside a page of the merchant's site. Two flavours: anonymous for a public pricing page, or identified for a signed-in customer, who can then subscribe in place -- which needs the customer reference and the security hash. What happens when a plan is chosen is configured in the BackOffice, not in this code.

Generates the round trip of In-Site step 2: the server-side code that fetches a ProAbono object and reads the encrypted workflow query out of its Links by rel, both ways of opening it -- ProAbonoPortal.open({ query }) in the application and a ?pa_query= link for e-mails -- and the single return route the customer comes back to, which re-reads the session user's rights first and then branches on from x outcome for all five outcomes. Reads the account's real offers. Also returns the BackOffice action no API can perform: the redirect URL to configure. Use it for sign-up, plan change, restart, registering a payment method or paying an invoice. Writes the installation state unless record_state is false.

Generates the code that reads a customer's rights from the ProAbono Usage API, caches them correctly and gates access on them -- step 3 of the In-Site installation, and the one that decides what a signed-in user may actually do. Returns the rights module for the stack, the gate at a call site, the write-back for a Feature the application changes (quoted and confirmed with the end customer when it is billable), and the cache expiry policy. Reads the account's real Features so the code names them. Give customer_ref to also diagnose what that customer's Usages currently say, which is how an empty response is told apart from a broken integration. Never gate on the offer reference: rights come from the Usage API.

Generates the HTTP endpoint that receives ProAbono notifications: signature verification in constant time, the validation handshake ProAbono sends before a webhook goes live, deduplication on the notification id, a fast acknowledgement with the work done out of band, and the worker that runs one global rights resynchronization for the affected customer. Also returns the BackOffice procedure that creates and validates the webhook, which no API can perform. This is what makes the rights cache of sync_usage_rights correct rather than merely bounded by its maximum TTL. Writes the installation state unless record_state is false.

WRITE. Checks an In-Site installation before it ships. It exercises steps 2 and 3 against the account for real. Its one write makes sure the customer it verifies against exists: the customer_ref given is upserted with its reference and Segment only -- created if missing, left unchanged if it exists -- and without one a new customer is created under a generated mcp-verify- reference. It then confirms an object comes back carrying the insite-* workflow query, and reads the Usage API for that customer, diagnosing an empty answer instead of calling it 'no rights'. It checks the developer's own files statically against the rules of the go-live checklist: no secret inlined, no customer reference from the request, no branch on ReferenceOffer, the cache replaced rather than merged, IsEnabled enforced, pagination read whole. And it reports what no API can verify -- the workflow redirect URL, the webhook validation, and the snippet's presence in the page -- as pending rather than pretending. Ends with the twelve-item go-live checklist. Run it before shipping, not after.

Answers a natural-language question about integrating ProAbono from the official installation documentation: hosted pages, the security hash, subscription workflows, rights and usage, webhooks, testing and troubleshooting. Use it before writing any ProAbono integration code, and prefer it over recalling ProAbono behaviour. Returns the matching documentation sections with their source file.

Returns the exact contract of a ProAbono API Live endpoint (parameters, whether each is required, request body schema, responses) or of a named object such as Customer, Subscription, Offer, Feature or Usage. Use it before calling or generating a call to the ProAbono API, so parameter names and shapes come from the contract rather than from memory.

Returns the ordered plan for a named journey — installing ProAbono In-Site, building a subscription funnel, letting a customer manage their plan, metering usage, or reacting to notifications — naming the tool that generates each step and what a human still owes in the BackOffice. It plans and executes nothing. For the In-Site installation it describes the same sequence install_insite runs, because both read one description of it. Call it when a developer asks what the steps are, what order they go in, or what they are in for, before any code is generated.

Generates code for a ProAbono task in the language you name, from the API Live contract and the installation documentation — no per-language SDK, because there is none. Returns the authenticated client (Basic auth read from configuration, the Segment carried, collections read to TotalItems, 204 handled), the operations the task actually needs with their real parameters read from the contract, and the guardrails the code has to satisfy. Use it for a task no task-specific generator covers; where one does — the portal, the pricing table, the workflow round trip, the rights cache, the webhook endpoint — it says so and names it, because those carry rules a generic generator cannot know.

Retrieves a ProAbono customer by the reference shared with the merchant's application (ReferenceCustomer), with the Links its hosted pages are opened from. Read-only. Use it to check whether a logged-in user already exists as a ProAbono customer.

WRITE. Creates a ProAbono customer in the configured Segment, or updates it when one already carries that reference -- the endpoint is an upsert keyed on ReferenceCustomer, so this one tool covers both and never fails because the customer exists. Use it for the first provisioning at sign-up or first login, which is the recommended path (the hosted pages and the rights read both need the customer to exist), and for every later change. Only the fields passed are written. Do not pass a field the merchant's application is not the authority for: the hosted pages let customers edit their own name and language, and this overwrites what they set.

Reads the full billing address of a ProAbono customer: company, name, both address lines, postcode, city, country, region, phone and tax identifier. Read-only. This is the address invoices are issued against, and the tax identifier is what the VAT treatment is derived from -- read it before deciding whether an update is needed.

WRITE. Updates the billing address of a ProAbono customer. Only the fields passed are changed. The address is what invoices are issued against, and the tax identifier is what VAT treatment is derived from, so it must be the customer's own data -- never a placeholder.

Reads the payment settings of a ProAbono customer in one call: the active payment type, the billing mode, whether the customer is grey-listed, the note printed on upcoming invoices, and the date of the next billing. Read-only. These are the settings that set_payment_method, set_invoice_note and set_next_billing_date each write one field of.

WRITE. Sets the date of the next billing of a ProAbono customer, and changes nothing else about their payment settings. Use it to align a customer's billing on a date the merchant chose -- a common anniversary, or the end of a negotiated period. Read the current value with get_payment_settings first: moving the date forward skips a period rather than compressing it.

WRITE. Sets the note printed at the bottom of every upcoming invoice of a ProAbono customer, and changes nothing else about their payment settings. Use it for a purchase order number, a cost centre, or anything the customer's own accounting needs on the document. It applies to invoices issued from now on, never to ones already issued.

WRITE. Records the manual payment method a ProAbono customer settles their invoices with -- bank transfer, cash, cheque or other -- and changes nothing else about their payment settings. Manual methods only: Card and DirectDebit are driven by the payment gateway and the endpoint refuses them here, so a customer paying by card is set up through the Customer Portal instead, never through this tool.

WRITE, AND IRREVERSIBLE. Erases the personal data of a ProAbono customer -- name and email -- and keeps their invoices and their subscription history, which is what a GDPR erasure asks of a billing system. There is no de-anonymization: the Live API offers none, and the erased values cannot be recovered from ProAbono by any means. This is the only tool in this server whose effect cannot be undone. Use it to serve an erasure request, never to tidy up test data, and confirm with the developer that this is the customer they mean before calling it -- the reference is the only thing identifying them, and a typo anonymizes somebody else. ProAbono refuses the call while the customer still has a due invoice: settle or cancel what is outstanding first.

Retrieves one ProAbono subscription of a customer, with its state, its dates and the Features it carries. Read-only. The customer reference is required: the Live API has no retrieve-by-identifier operation for subscriptions, so a subscription is always reached through the customer who holds it. Pass subscription_id as well when the customer has several and a specific one is meant; without it, the customer's current subscription comes back. Use list_subscriptions to see them all.

Lists ProAbono subscriptions, optionally those of one customer, with their state and the Features they carry. Read-only. Use it to see what a customer is actually subscribed to, or to explain why a customer has no rights. Reads every page.

WRITE. Creates a ProAbono subscription linking an existing customer to an offer. This is the API path; a customer choosing a plan themselves goes through a hosted subscription workflow instead. The subscription is created as a copy of the offer -- pass an override only where the merchant genuinely departs from their own catalogue. Set start_now to activate it immediately; a subscription left in Draft grants no rights. A draft one is activated later with start_subscription.

WRITE. Activates a ProAbono subscription that is in Draft, and restarts one that was suspended -- it is the same transition, and this is the tool to reach for to unsuspend a subscription; there is no separate resume or unsuspend operation. A subscription grants no rights until it is started, so this is what turns a created subscription into usable access. Re-read the customer's rights afterwards with get_usages.

WRITE. Moves a ProAbono subscription to another offer -- an upgrade or a downgrade, the same operation either way. It terminates the current subscription and creates a new one on the target offer, which means the returned identifier is a new one and the customer's rights change: re-read them with get_usages afterwards, and stop using the old identifier. By default the move takes effect at the end of the current term; set immediate to apply it now.

WRITE. Suspends a ProAbono subscription. A suspended subscription stops granting rights and stops being billed, and is not terminated: start_subscription restarts it, which is the difference from terminate_subscription. Re-read the customer's rights with get_usages afterwards.

WRITE. Terminates a ProAbono subscription. By default it takes effect at the end of the current term, so it is not an immediate loss of access: the customer keeps their rights until then, and an application that revokes access on the call is wrong. Set immediate to end it now, or termination_date to schedule it for a chosen date. A terminated subscription cannot be restarted -- suspend_subscription is the reversible one.

Lists the ProAbono offers the configured Segment exposes, with the Features each one carries and its pricing. Read-only. This is the catalogue: what the merchant sells, to anyone. Use it to show a pricing page, to pick the offer a subscription or a pricing table targets, or to check the prerequisite that at least one offer exists and carries at least one Feature. For what one named customer may take, or what a running subscription can move to, use list_offers_for_customer instead. Reads every page, not just the first.

Lists the ProAbono offers a named customer may take right now, which is not the same set as the catalogue: it accounts for what they already hold. Read-only. Set upgrade_only, with the subscription's identifier when the customer holds several, to get the upgrade and downgrade options of a running subscription -- the answer to "what can this customer move to?", which list_offers cannot give. Use list_offers for the public catalogue. Reads every page.

Retrieves a single ProAbono offer by its reference, with its Features, pricing and the Links it exposes. Read-only. Use it when the offer reference is already known.

Lists the ProAbono Features of the account: the definitions the business owns, each with its type (OnOff, Limitation or Consumption). Read-only. These are what an application can gate access on. A Feature is the definition; a customer's value for it is a Usage, read with get_usages. Reads every page.

Reads a customer's Usages: what that customer may do right now, as ProAbono sees it, one entry per Feature carried by their running subscriptions. Read-only. This is the source an application gates access on -- never the offer reference. An empty result is ambiguous: check the customer's subscriptions with list_subscriptions before concluding they have no rights.

Prices an intended Usage change without applying it, and checks that it is allowed: what the customer would be charged now, and, with next_term, what their recurring cost would become. Read-only -- nothing is written. Call it before push_usage_increment, push_usage_quantity or push_usage_enabling whenever the change is billable, and show the amount to the end customer for confirmation before the write. Pass exactly one of increment, quantity_current or is_enabled, matching the Feature's type.

WRITE. Adds an increment to the current quantity of a Consumption Feature of a customer -- the metered kind: messages sent, API calls made, gigabytes stored. Report what was just consumed, not a running total: the value is added to what ProAbono already holds. Consumption Features only; use push_usage_quantity for a Limitation Feature and push_usage_enabling for an OnOff one. A repeated call double-counts -- there is no absolute mode to fall back on for a metered event, so the caller is responsible for not sending the same consumption twice, including on a retry after a timeout. Quote it first with quote_usage_change when it is billable.

WRITE. Sets the current quantity of a Limitation Feature of a customer to an absolute value -- seats, projects, users. Send the quantity the application has provisioned, the seats bought and not the seats occupied: that is what ProAbono bills on. The value is absolute, so sending it twice is harmless, which is why this write takes no increment. Limitation Features only; use push_usage_increment for a metered Feature and push_usage_enabling for an OnOff one. Quote it first with quote_usage_change when it is billable.

WRITE. Enables or disables an OnOff Feature in the active subscription of a customer -- an option they switch on or off. OnOff Features only; use push_usage_increment for a metered Feature and push_usage_quantity for a Limitation one. The value is absolute, so repeating the call is harmless. Note that what the application must then enforce is IsEnabled, not IsIncluded: a Feature included in the offer can still be switched off. Quote it first with quote_usage_change when enabling is billable.

Retrieves one ProAbono debit invoice with all its detail -- status, amounts, dates, payment method, the note printed on it -- and its PDF URL, taken from the document's own Links. Read-only. Identify it by internal identifier or by full number; pass one, not both. A credit note is a different document: use get_credit_note for it. If the identifier turns out to name one, this tool says so rather than returning it as an invoice.

Retrieves one ProAbono credit note with all its detail: its TypeCredit -- Refund when a paid invoice was given back, Voiding when one was cancelled before payment -- the Reason it was issued for, its amounts and its PDF URL, taken from the document's own Links. Read-only. Identify it by internal identifier or by full number; pass one, not both. A credit note is an invoice carrying TypeCredit, and the Live API serves both kinds from the same endpoint: if the identifier names a debit invoice, this tool says so rather than returning it as a credit note. Use get_invoice for a debit invoice.

Lists the billing documents of a ProAbono customer: debit invoices and credit notes together, as the Live API returns them, with TypeCredit telling the two apart -- present means a credit note, absent means a debit invoice. Read-only. There is no kind filter, here or in the API: filter the returned list yourself if only one kind is wanted, and say so in the answer, because the count reported here is the customer's full document history. Reads every page.

WRITE. Creates a line in the balance of a ProAbono customer: a debit when the amount is positive, a credit when it is negative. The amount is in cents, in the Segment's currency. This does not invoice anything -- it puts an amount in the balance, waiting. bill_customer is what turns the balance into an invoice, and the pair is only useful in that order. Use it for a one-off charge or a goodwill credit that the catalogue does not cover.

WRITE. Creates an invoice from the lines currently sitting in a ProAbono customer's balance, and returns it. Whatever is in the balance is what gets invoiced, so create_balance_line is what decides the amount and runs first -- billing an empty balance invoices nothing. The invoice is issued for real and, for a customer on an automated payment method, a charge is attempted immediately. Read it back afterwards with get_invoice, whose answer carries the PDF URL.