Skip to main content
Glama

Optional supporter checkout link

supporter_checkout_link

Creates the existing fixed-price $3 USD Oil Baron Stripe Checkout link for the connected fan, only when they ask. The human must open and confirm on Stripe. Never collect card data or complete payment. The free credential stays available.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
urlYes
enabledYes
messageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations, the description discloses that the human must open and confirm on Stripe, that card data must never be collected, and that the tool must never complete payment, which is important context for a mutation-adjacent tool. It does not state whether repeated calls mint new sessions, whether links expire, or rate limits; and note that openWorldHint=false sits awkwardly with a tool that produces a Stripe-hosted link, though the external step is attributed to the human.

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

Conciseness5/5

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

Three short sentences, with the action stated first, followed by the gating condition and the safety constraint. No wasted wording and nothing buried.

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 zero parameters and an output schema present, the description need not explain return values, and it covers the action, the trigger, and the human-in-the-loop boundary. Minor gaps remain around link lifetime and repeat-call behavior, but nothing an agent needs to call it correctly is missing.

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?

There are zero parameters, so the baseline is 4. The description still adds meaning the empty schema cannot convey: the price is fixed at $3 USD and denominated in USD, so the agent knows no amount argument exists or is needed.

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 states a specific verb and resource: creating a fixed-price $3 USD Oil Baron Stripe Checkout link for the connected fan. That is far more concrete than the title alone. It does not name a sibling it is distinct from (e.g., connect_account), so it stops short of full sibling differentiation.

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 phrase 'only when they ask' gives an explicit trigger condition, and 'the free credential stays available' signals that this is optional and not a required step. There is no explicit when-not clause or named alternative among the siblings, but the usage context is clear.

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.

Resources