Squatch Stack

Ways to support Squatch Stack

support_options

Read-onlyIdempotent

The ways to back Squatch Stack's open hardware and audio work: monthly tiers and one-time options with their price and what the supporter gets, GitHub Sponsors and the store. Gives a checkout link only for options whose card checkout is live; it never starts a payment (the person opens the link and pays). Squatch.CC LLC is a for-profit business; support is not tax-deductible.

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": "support_options"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 16, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, and the description still adds real context beyond them: links are only returned for live card-checkout options, no payment is ever initiated, and the entity is a for-profit with non-deductible contributions. These are exactly the behavioral/legal facts an agent needs before surfacing a checkout link.

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?

Front-loaded with the resource, then two pay-off sentences covering link behavior and legal status. Every sentence carries information, though the tax-deductibility clause and the parenthetical about who pays add slight redundancy.

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 and no parameters, the description carries the full burden and does well: it enumerates the returned content (tiers, prices, benefits, sponsorship sources) and the checkout-link condition. It could say more about how options are grouped or ordered, but nothing essential for correct invocation 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate, and it correctly does not invent parameter talk.

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?

States a specific resource — the ways to back Squatch Stack (monthly tiers, one-time options, prices, supporter benefits, GitHub Sponsors, the store) — with a concrete enumeration of what comes back. It also distinguishes itself from start_checkout by clarifying it only supplies a link rather than initiating payment.

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 line 'Gives a checkout link only for options whose card checkout is live; it never starts a payment (the person opens the link and pays)' implicitly routes the agent: use this to present support options, use start_checkout to actually pay. No named alternative or explicit 'use when the user asks how to donate' trigger, so it stops short of a 5.

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

All Squatch Stack 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?