stub

Get plan

get_plan

Read-only

The business's plan, what it includes, what each plan includes and the trial days left; for actions used this period use get_action_usage, and for the plan's billing line items use get_subscription. plan: the plan they are on by its customer name, whether it is legacy, its price, status and trialing; trial (trialists only) has the start and end dates, days_left and actions_cap, the actions a trial period grants; features is what is on today, lacks each plan-gated feature they do not have with the lowest plan that has it, and not_by_plan what a card and verification turn on instead; automatic_bank_sync and history_limit_months are this business's sync terms. plans: every live plan cheapest first with its features, what it adds over the plan below, its actions and seats, and the free plan's limits. Prices for other plans are not here: look them up in the guide. A feature no plan lists is on every plan.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_plan"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

readOnlyHint=true already covers the safety profile, and the description goes further by disclosing conditional shapes ('trial' present for trialists only), the semantics of derived fields ('lacks' names the lowest plan that has a feature), and the default rule 'A feature no plan lists is on every plan'. It stops short of stating pagination or ordering caveats beyond 'cheapest first' for plans.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Almost every clause carries real information and the most important framing (scope plus sibling redirects) is front-loaded, so there is little filler. However, the body is one dense run-on block of backticked field names separated by semicolons, which makes it hard to scan and separates related fields (plan/trial/features) from the catalogue block only by a semicolon.

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?

With no output schema, the description carries the full burden of explaining return values, and it does so field by field for both the 'plan' object and the 'plans' catalogue. It is close to complete for a read-only zero-param tool; only minor gaps remain, such as what happens when no plan is set or how legacy plans appear in the catalogue.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; it correctly spends its space on return semantics instead. Baseline for a zero-parameter tool is a 4.

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 names the specific resource (the business's plan, its trial state, features and the catalogue of plans) and immediately separates it from get_action_usage and get_subscription. It is a noun-phrase inventory rather than a verb-led statement, but an agent can still tell precisely what it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes two adjacent needs to their siblings ('for actions used this period use get_action_usage', 'for the plan's billing line items use get_subscription') and adds an exclusion with a redirect ('Prices for other plans are not here: look them up in the guide'). Nothing about when to call this vs. alternatives is left to inference.

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

All stub 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?