Skip to main content
Glama
SubscriptionTech

ProAbono MCP Installation

Official
by SubscriptionTech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Verify the In-Site installation, and run the go-live checklist (write)

verify_insite_installation

Validates an in-site installation before shipping: exercises the live wiring against the account, audits your code against the go-live checklist, and flags what only you can confirm.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offer_refNoAn offer to check the subscribe workflow against. It is what makes the `insite-subscribe` query appear on the customer at all.
customer_refNoA customer to exercise the wiring against — ideally one that has subscribed, since only a subscribed customer has rights to read. It is upserted with its reference and Segment only, so an existing customer is left unchanged. Without it, a new customer is created under a generated `mcp-verify-` reference.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / customer_ref / description
      Previous value: -"A customer to exercise the wiring against — ideally one that has subscribed. Without it, steps 2 and 3 cannot be verified end to end and are reported as unverified rather than as passing."New value: +"A customer to exercise the wiring against — ideally one that has subscribed, since only a subscribed customer has rights to read. It is upserted with its reference and Segment only, so an existing customer is left unchanged. Without it, a new customer is created under a generated `mcp-verify-` reference."
  2. Addedv0.3.1

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It declares 'WRITE' up front, explains that steps 2 and 3 are exercised against the real account, details the exact upsert behavior on customer_ref (created if missing, left unchanged if existing, generated mcp-verify- reference otherwise), describes static file checks against go-live rules, and explicitly reports unverifiable items as pending instead of pretending.

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 long but appropriately detailed for a complex verification tool with many checks. It is front-loaded with 'WRITE' and the core purpose, and each sentence describes a distinct behavior or check, though the density is high and could be slightly more scannable.

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?

Given the tool's complexity, lack of annotations, and absence of an output schema, the description is complete enough. It covers the write side effect, the execution scope, the static checks, the unverifiable items reported as pending, and the final twelve-item checklist, leaving no major gaps for an agent to call it correctly.

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 documents all three parameters in detail. The description adds context around the customer_ref upsert and offer_ref's effect on the insite-subscribe query, but most of this is duplicative rather than supplementary, so the baseline of 3 is appropriate.

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 states a specific verb (verify/checks) and resource (In-Site installation before shipping), and distinguishes itself from installation tools by describing a verification-and-checklist role. However, it does not name or contrast with siblings such as installation_status or install_insite, so sibling differentiation is implied rather than explicit.

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 gives a clear usage condition: 'Run it before shipping, not after.' This tells the agent when to invoke the tool. It does not name alternatives or when-not-to-use, but the context is unambiguous for a pre-ship verification step.

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