Skip to main content
Glama
SubscriptionTech

ProAbono MCP Installation

Official
by SubscriptionTech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Scaffold the ProAbono notification (webhook) endpoint

scaffold_notification_endpoint

Generate the HTTP endpoint for ProAbono notifications: signature verification, handshake, dedup, fast ack, and out-of-band rights resync. Also returns the BackOffice webhook setup procedure.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stackYesThe host project's stack. Detect it from the open project (package.json, composer.json, requirements.txt, Gemfile, .csproj) and confirm with the developer. Use "generic" when none fits.
project_rootNoRoot of the developer's project, where `.proabono/installation.json` is written. Defaults to the directory this server was launched in, which is the project for every MCP client that starts the server inside it. Pass it when that is not the case.
record_stateNoRecord this step in `.proabono/installation.json`. Default true. Set false to generate code without touching the developer's filesystem at all.
endpoint_pathNoPath the endpoint is served at, e.g. "/webhooks/proabono". Defaults to that. It must be reachable over HTTPS from the public internet: ProAbono does not deliver to a local address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so thoroughly. It discloses security behavior, handshake handling, deduplication, async processing, the manual BackOffice requirement, and the side effect of writing installation state unless record_state is false.

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 dense but every clause contributes meaningful behavioral or usage information. The main sentence front-loads the core purpose before listing details; it could be slightly more scannable, but it is not padded.

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

Completeness5/5

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

For a high-complexity scaffold tool with no annotations and no output schema, the description is unusually complete. It covers what is generated, how it behaves, the required manual procedure, and how it relates to sync_usage_rights, leaving the agent with a clear model of the tool's function.

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 parameters are already well documented. The description adds a little context around record_state by restating the installation-state side effect, but it does not substantially enrich parameter understanding beyond the schema.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Generates the HTTP endpoint that receives ProAbono notifications'. It then enumerates distinctive capabilities—signature verification, validation handshake, deduplication, out-of-band acknowledgement, and a worker—that clearly separate it from siblings like sync_usage_rights and generate_integration_code.

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?

The description provides clear context for when this tool matters, especially the sentence tying it to sync_usage_rights and explaining that the BackOffice procedure is needed because 'no API can perform' it. It does not explicitly list exclusions or alternative tools, so it stops short of a 5.

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

Deploy Server

Other Tools