Skip to main content
Glama

Set auto-reload

set_auto_reload
Idempotent

Turn automatic credit reloads on or off (admin only): when the balance drops below a threshold, the card on file is charged for a top-up pack — SERVER-SIDE, even with no app open. Requires a saved card, added once in the app at first checkout/top-up; if there's none the tool tells you exactly where to add it. After that one-time card setup, agents can manage auto-reload, top-ups and plan links fully. Members (read-only billing) get an 'ask an admin' message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
enabledYestrue to turn auto-reload on, false to turn it off
reloadCreditsNohow many credits to add each reload — must match a credit pack size (see buy_credits)
thresholdCreditsNoreload when the balance drops below this many credits

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable behavior beyond that: server-side execution ('even with no app open'), the one-time card setup prerequisite, and the specific error message for members. This gives agents a fuller picture of side effects and preconditions.

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 a few sentences long, front-loaded with the core action and role, then explaining mechanics, prerequisites, and error paths. Every sentence adds necessary operational detail without filler. It is appropriately concise for the complexity of the tool.

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?

Cover the behavioral outcome, prerequisites (saved card), error handling for members, and the fact that it is server-side. While it does not describe the return value, this is acceptable for a configuration tool with no output schema. It feels complete for an agent to decide when and how to invoke it.

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?

The schema covers all three parameters fully (100% coverage) with clear descriptions. The tool description adds the overall mechanism tying thresholdCredits and reloadCredits together, but does not add significant new information beyond the schema. Baseline 3 is appropriate; the description reinforces but does not extend parameter understanding.

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 opens with a specific verb-resource pair ('Turn automatic credit reloads on or off') and scopes it to admins. It clearly distinguishes this from manual credit purchase (buy_credits) by describing the automated mechanism (balance threshold, card on file, server-side execution). An agent can immediately understand what this tool does and how it differs from related tools.

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?

States that it is admin-only, requires a saved card, and explains behavior for members (read-only billing) and what to do if no card exists. It gives clear context for when this tool is appropriate (managing auto-reload) versus manual top-ups, though it does not explicitly name an alternative tool like 'buy_credits' as the fallback for manual purchases.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation2/5

With 293 tools, the surface is enormous and many tools have overlapping purposes—multiple posting tools (post_to_meta, post_to_linkedin, schedule_post, etc.), multiple analytics tools per channel, and several search tools (search_meta_ads, search_instagram, search_reddit...). While each description is detailed, the volume makes it difficult for an agent to reliably distinguish between similar tools without careful reading, leading to frequent misselection.

Naming Consistency4/5

The naming is largely consistent with a verb_noun pattern (post_to_*, list_*, create_*, delete_*, update_*, manage_*). There are clear families for major operations. A few outliers like 'google_business_account', 'hermoso_capabilities', and 'store_get' break the pattern, but the overwhelming majority follow a predictable structure, making navigation somewhat easier.

Tool Count1/5

293 tools is far beyond any reasonable scope for a single MCP server, even for a comprehensive marketing platform. The calibration guide flags 50+ as an extreme mismatch, and this is nearly six times that threshold. Such a large surface overwhelms context windows, increases the probability of misselection, and makes it impractical for agents to learn or use effectively.

Completeness4/5

The tool set covers a vast domain: ad creation and rendering, posting across nine+ social channels, analytics and reporting, file management (Drive/OneDrive), competitor research, brand management, and more. It appears to provide CRUD and lifecycle coverage for most resources. While there may be minor gaps given the immense scope, the overall coverage is impressively comprehensive.