Skip to main content
Glama

agentcard

by sh.agentcard

manage_subscription

Manage a recurring meal/grocery SUBSCRIPTION (e.g. Locale) — NOT a one-time purchase, and no payment is taken (the subscription auto-bills the card on file at the merchant). action: 'menu_search' (browse the recurring menu; items flagged inPlan are covered by the plan), 'get_skip_dates' (list skipped/paused deliveries), 'skip'/'unskip' (one upcoming delivery date), 'set_skip_dates' (replace the full skip set; [] resumes all), 'update_setting' (change a setting). Locale settings: subscription_size (meals, e.g. 8), calorie_preference (low_calorie|both|moderate), diets (array), longevity_allergens (array), ingredient_allergies (array), default_window ('9am - 6pm'|'3pm - 7pm'|'9am - 12pm'), delivery_instructions (text). Link the merchant first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoskip/unskip: one ISO delivery date (YYYY-MM-DD)
datesNoset_skip_dates: FULL set of ISO dates to skip ([] resumes all)
limitNomenu_search: max items
queryNomenu_search: term over the recurring menu (e.g. 'salmon'); '' lists everything
valueNoupdate_setting: the new value (number, string, or array of strings)
actionYesthe management action
settingNoupdate_setting: the setting key (see description)
merchantYesmerchant slug (e.g. locale)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesHuman-readable result or next step.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds key behavioral details: no payment taken, auto-billing, actions like skip/unskip affecting deliveries, and the need to link the merchant first. This fully compensates for minimal annotation info.

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 fairly concise given the complexity, with front-loaded purpose. Every sentence earns its place, though it could be slightly more structured (e.g., bullet lists). Still effective.

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 (8 parameters, various actions), and existence of an output schema, the description covers all necessary context: actions, settings, prerequisite linking. It is complete enough for an agent to use correctly.

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?

With 100% schema coverage, baseline is 3. The description adds significant value by explaining the action enum values and providing a detailed list of settings for 'update_setting', which goes beyond the schema's brief descriptions.

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 clearly states it manages recurring meal/grocery subscriptions (e.g., Locale), explicitly distinguishes from one-time purchases, and lists specific actions. This differentiates it from sibling tools like 'buy', which are likely for purchases.

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?

The description provides clear context: it's for subscription management, not one-time purchases, and no payment is taken. It also mentions linking the merchant first. However, it lacks explicit when-not-to-use guidance relative to siblings, though many are unrelated.

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

All agentcard toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, especially in areas like card management and shopping. However, the KYC flow has multiple overlapping tools (start_kyc, get_kyc_status, check_kyc_document, submit_kyc_document, submit_kyc_fields) that could confuse an agent despite detailed descriptions.

Naming Consistency4/5

Tool names consistently use snake_case with a verb_noun pattern (e.g., add_funds, create_card, list_cards). A few exceptions like surprise_me and whoami break the pattern but are still intuitive overall.

Tool Count3/5

50 tools is on the high side for a single server, but the broad domain (cards, shopping, KYC, support, settings) partially justifies it. Some tools could be merged (e.g., KYC flow tools) without losing clarity.

Completeness4/5

The tool surface covers core workflows: CRUD for cards, transactions, KYC, support, shopping, and account management. Minor gaps exist (e.g., no update_card general, no cancel order in shopping), but overall the set is comprehensive for the stated purpose.

Resources