Version

Tools Reference

Every MCP tool the Subscriby server exposes today, grouped by what it works on, with the ability each one enforces.

161 tools across 19 groups: 56 read, 97 write (82 of them destructive), 7 analytics and one async-polling tool. Every write goes through the same business-logic layer that powers the dashboard, so plan-limit enforcement, cache invalidation and policy gates all run identically. Every count and list on this page is generated from the server's own export.

Machine-readable catalog

The authoritative, auto-generated list is published at:

GET https://api.subscriby.net/mcp-tools.json

Sibling artifacts at the same host — regenerated on every deploy:

  • https://api.subscriby.net/abilities.json — full ability catalog.
  • https://api.subscriby.net/error-codes.json — error code / HTTP status / remediation.
  • https://api.subscriby.net/webhook-events.json — every outbound webhook event.

Tools by group

Each group below is one page of the reference. A page opens with what the group's tools are for, lists them, and then documents every tool in full: its arguments as the server validates them, what it returns, how it fails, the REST endpoint that runs the same action, the webhook events it fires, example prompts and the tools/call request an MCP client sends. A row here opens the tool on its page.

Access Code Tools

An access code is a pre-generated, single-use activation a creator hands out; redeeming it claims a pending subscription. Open the group.

Account Tools

The account behind the token: who is acting, which team the session is scoped to and what it may do. Open the group.

Analytics & Reports Tools

Every figure the creator dashboard renders is readable here, from revenue and churn to the transaction list, computed by the same service layer, so an agent and the dashboard never disagree. Open the group.

Connector Tools

A project runs on connectors: the platforms it gates access on, messages through and takes payments from. Open the group.

Coupon Tools

A coupon is one code many buyers can redeem for money off at checkout, the multi-use counterpart of an access code. Open the group.

Creator Task Tools

A creator task is a grant no connector can hand over: a perk the creator delivers by hand once a purchase entitles a member to it. Open the group.

Disaster Recovery Tools

Disaster Recovery is Subscriby's answer to a connector outage or a lost channel: what the probes found, what was recovered and whether it can still be undone. Open the group.

Member Tools

Members are a project's subscribers, the people every payment is made for and every access grant resolves to. Open the group.

Observability Tools

Where to look when something did not happen: webhook endpoints and their deliveries, the activity log of every mutation, and the status of a job another tool queued. Open the group.

Payment Tools

A project sells through one or more payment providers, each connected in test or live mode. Open the group.

Plan Tools

Plans are what a project sells, and every plan has a kind that decides its shape: a subscription that renews on a cycle, a pass that sells dated windows, or a series that sells a slate of windows at once. Open the group.

Project Tools

A project is the container for one membership business: its plans, members, payment methods, resources and connectors. Open the group.

Resource Tools

A resource is what a plan unlocks: a place a connector gates, or a perk tracked by hand. Open the group.

Role & Group Tools

A role is the permission set one collaborator holds; a group is a bundle several collaborators share. Open the group.

Subscription Tools

A subscription is one member's purchase of one plan, and it is never created through a tool: checkout and access codes do that. Open the group.

Support Tools

The support inbox holds one durable conversation per member and channel, the saved replies a team answers with, and the project's support settings. Open the group.

Team Member Tools

Team members are the people who collaborate inside a team, distinct from a project's members. Open the group.

Team Tools

A team groups creators, roles and projects, and every token is scoped to exactly one. Open the group.

Token Tools

Personal access tokens authorise every REST and MCP call, and the plaintext value exists exactly once. Open the group.

Async polling

One tool, get_job_status, checks on work another tool queued (today only bulk_generate_access_codes queues). Visibility is locked to jobs the caller originally kicked off, which is why no separate ability gates it — polling reveals nothing you did not already cause, and the tool that enqueued the work enforced its own ability.

See async jobs for the full lifecycle.

Resource catalogs

Alongside tools, the server exposes 6 read-only resources:

  • subscriby://enums/ability — API Ability Catalog: Every ability a Sanctum personal access token can carry — core CRUD gates plus top-level scopes for team, role, group, token, payment, pass-window, support-canned-reply, webhook-endpoint, webhook-delivery, broadcast, bot, account, billing, dashboard, activity, platform admin and distribution. MCP and REST answer to the same catalog: a tool requires the same ability its REST equivalent does, so mint for the operations you intend to call rather than for the channel. Read once at session start to know what the current token can do and to mint future tokens with the minimum-privilege list. Returns { abilities: [{value, category, label}], core_count, extras_count, total }.
  • subscriby://enums/error-code — API Error Code Catalog: Every error code the API surface and MCP tools can emit. Each entry carries HTTP status, default message, remediation hint, and a docs_url anchor. Read this whenever a tool response carries an error envelope so the agent can pick the right remediation before retrying. Returns { error_codes: [{code, http_status, message, remediation, docs_url}] }.
  • subscriby://connectors/catalog — Connector Catalog: Every connector Subscriby knows, lane by lane: status (available, beta, paused, in_development, coming_soon), installable, official, badges, category, tagline, links and, for a connector that exists as a package, its manifest (resource kinds with their grant mode, capabilities, messaging limits, pacing, the management commands it renders and the ones it misses, recovery facets) and the declarative install and settings fields a client renders as the connect form. Read this before proposing a connector for a project or explaining what one can do. Returns { connectors: [card], total }.
  • subscriby://enums/payment-provider — Payment Providers: The payment-provider keys Subscriby supports: the gateway codes (Stripe, PayPal, Razorpay, Paystack, CoinPayments, Skrill, CeyPay), access codes, and one connector:provider key per native currency a connector brings, which can only be configured on a project where that connector is connected. Most flows use payment-method UUIDs from list_payment_methods rather than provider codes; consult this resource only when you need the canonical provider string. Returns { payment_providers: [{value, connector, requires_connector, legacy_alias}] }; platformcurrency is the legacy alias earlier native rows were stored under.
  • subscriby://enums/subscription-status — Subscription Status Catalog: Every status a subscription or payment row can hold, with the human label and the dashboard color family. Read this before reasoning about lifecycle — e.g. is past_due a dunning trigger, is capturable retryable, is canceled terminal? Avoids hard-coding free-text status strings on the agent side. Returns { subscription_statuses: [{value, label, color}] }.
  • subscriby://enums/webhook-event — Outbound Webhook Event Catalog: Every outbound webhook event Subscriby can emit, grouped by family (project, plan, member, subscription, payment, access-code, etc.). Each row carries the minimum ability a subscribing creator must hold to receive that event. Read this before configuring a webhook endpoint or wiring up an external automation (Zapier, n8n) so the event allow-list lines up with the events the source actions actually produce. Returns { webhook_events: [{name, family, required_ability}], families: [string] }.

Clients that support resource browsing pick any of these as context before driving the tools. See the resources reference for payload shapes.

How is this guide?

Version

On this page

Subscriby is a product
designed by you — for you.
No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request