ModelsLab Agent Control Plane

Agent Subscription Management

agent-subscriptions

Manage subscriptions for the authenticated user.
Actions: list-plans (view available subscription plans + pay-as-you-go options),
list, create (headless with payment_method_id, or checkout URL without it),
confirm-checkout (confirm Stripe checkout session), status (check subscription status),
update (change plan), pause, resume, reset-cycle,
charge-amount (set paid model charge amount), fix-payment.
Headless flow: get publishable key via agent-billing stripe-config → tokenize card via Stripe API
→ pass payment_method_id to create. All actions require authentication.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes	The subscription action: list-plans, list, create, confirm-checkout, status, update, pause, resume, reset-cycle, charge-amount, fix-payment
`amount`	No	Charge amount in USD, $5-$10000 (required for charge-amount)
`plan_id`	No	Plan ID to subscribe to (required for create)
`session_id`	No	Stripe checkout session ID (required for confirm-checkout)
`new_plan_id`	No	New plan ID to switch to (required for update)
`plan_category`	No	Plan category: "enterprise", or "imagen" for the standard ModelsLab subscription (optional for fix-payment; defaults to the subscription's own category)
`idempotency_key`	No	Idempotency key for mutation actions (optional — auto-generated if omitted for create)
`subscription_id`	No	Subscription ID (required for update, pause, resume, reset-cycle, fix-payment)
`payment_method_id`	No	Stripe payment method ID for headless subscription (optional for create — if provided, charges immediately without checkout redirect)
`stripe_subscription_id`	No	Stripe subscription ID (optional override for fix-payment)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations only supply openWorldHint=true, so the description carries most of the burden; it does add real value by stating "All actions require authentication" and that idempotency keys are auto-generated for create. However, mutation actions like update, pause, reset-cycle and fix-payment get no disclosure of side effects, reversibility, or billing impact.

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 opening line states purpose, then actions and the headless flow are grouped into scannable blocks. It is dense but front-loaded and wastes little, though the raw action list is long and partially redundant with the schema's action enum.

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

Completeness4/5

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

For a 10-parameter action-dispatch tool with no output schema and only an openWorldHint annotation, the description supplies the action taxonomy, auth requirement, and the ordering of the headless flow, which is enough to invoke correctly. It omits any indication of what the read actions return or how errors surface.

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 every parameter is already documented with its purpose, required actions, and constraints such as the $5-$10000 amount range. The description mainly restates action names already present in the action enum documentation, adding little parameter meaning 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 gives a specific verb+resource ("Manage subscriptions for the authenticated user") and enumerates all eleven actions supported, so an agent knows exactly what capability sits behind this tool. It is distinguishable from siblings like agent-billing and agent-wallet, and it even names the dependency (agent-billing stripe-config) that the flow reaches into.

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 clearly explains the split between create with payment_method_id (headless, immediate charge) versus without it (checkout URL), and lays out the ordering of the headless flow across tools. It does not state exclusions or when NOT to use this tool versus agent-billing/wallet, so it falls short of the explicit alternatives bar.

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

All ModelsLab Agent Control Plane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?