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.

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 Live API 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.

Lists the ProAbono offers the configured Segment exposes, with the Features each one carries and its pricing. Read-only. Use it to show a catalogue, 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. Reads every page, not just the first.

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.

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.

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.

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.

WRITE. Creates a ProAbono customer in the configured Segment, keyed by the reference the merchant's application uses for the logged-in user. The endpoint is an upsert on that reference: if a customer with it already exists, this updates them instead of failing. Provisioning the customer early -- at sign-up or first login -- is the recommended path, because the hosted pages and the rights read both need the customer to exist.

WRITE. Updates a ProAbono customer identified by its shared reference. The endpoint is an upsert: if no customer carries that reference, one is created rather than an error raised. Only the fields passed are changed. Do not pass a field the merchant's application is not the authority for -- the hosted pages let the customer edit their own name and language, and this overwrites what they set.

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.

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.

WRITE. Moves an existing ProAbono subscription: upgrade or downgrade it to another offer, start a draft one, suspend it, or terminate it. Identify the subscription by its internal identifier, which list_subscriptions returns. Terminating is not an immediate loss of access unless immediate is set -- by default it takes effect at the end of the current term. An upgrade terminates the current subscription and creates a new one on the target offer, so the customer's rights change: re-read them afterwards with get_usages.

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.