get_planFetch a single plan by id (optionally a specific version). Autumn API: POST /v1/plans.get.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | The ID of the plan to retrieve. | |
| version | No | The plan version to get. Defaults to the latest. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds the concrete Autumn API endpoint and optional-version behavior, but does not disclose return shape, error cases, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the action and resource, and the endpoint reference provides useful grounding without unnecessary detail. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only fetch with two well-documented parameters and no output schema, this is nearly complete. It omits an explicit statement of the return value, but the tool name and purpose make it obvious, and the endpoint reference adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema fully describes plan_id and version, including the default behavior. The description's 'optionally a specific version' largely restates schema information, adding minimal semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') with a precise resource ('a single plan by id') and an optional qualifier ('specific version'). This clearly distinguishes it from list_plans and other siblings, making the tool's scope immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single plan id is known, and 'single' hints at not using this for listing. However, it never explicitly names alternatives like list_plans or states when not to use it, leaving the agent to infer routing from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
All tools have clearly distinct purposes: get/list for various resources, mutation tools like attach_plan, track_usage, and special tools like preview_attach and autumn_request for edge cases. No overlap in functionality.
Most tools follow a verb_noun pattern (get_customer, list_plans, create_entity), but a few like autumn_request, preview_attach, and open_customer_portal break the pattern. Still, the naming is clear and predictable overall.
18 tools is slightly above the typical 3-15 range, but each tool serves a distinct purpose in the billing domain, covering customers, plans, features, entities, invoices, usage, and portal access. The count is justified by the complexity of the domain.
The tool set covers CRUD for most resources (customers, features, plans, entities, invoices) plus billing operations like attach, check, preview, track usage, and customer portal. Missing delete operations and potential detach, but the read-only autumn_request may cover gaps. Minor gaps, not severe.