Skip to main content
Glama
Sign In

Squish

by co.squish
OverviewDiscussionsAdmin

Toggle autorenew

toggle_autorenew

Turn auto-renew on or off for a domain the customer owns. Two-step usage: (1) call with confirm:false to fetch the current state and preview the change. If turning OFF, make sure the user understands the domain will expire if they don't renew manually. (2) ONLY after explicit user yes, call with confirm:true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "enabled": "<enabled>"
    },
    "name": "toggle_autorenew"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYesDomain to toggle.
confirmNofalse (default) returns preview; true applies. Pass true ONLY after explicit user confirmation.
enabledYestrue to turn auto-renew on; false to turn it off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, idempotentHint=false, destructiveHint=false; the description adds the substantive behavior the annotations cannot convey: that the call is two-phase, that the first phase is a read-only preview, and that disabling autorenew risks domain expiry. It stops short of describing the preview payload's contents or failure modes, which keeps it from a 5.

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 sentences, front-loaded with the action, then the numbered two-step procedure. The expiry warning is attached to the exact step where it matters, and no sentence restates the name or title.

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?

For a 3-parameter mutation with no output schema, the description covers the safety-critical path: preview, confirmation, and the consequence of disabling. It does not say what the preview returns or how a domain not owned by the customer is handled, a small gap given the absence of an output schema.

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?

Schema coverage is 100%, so all three parameters are already documented, including confirm's preview/apply meaning. The description's additional value is the sequencing rule (call confirm:false before confirm:true), which is genuinely beyond the schema, but 'domain' and 'enabled' receive no extra semantic depth beyond what the schema states — baseline 3 with a modest lift.

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 and resource: 'Turn auto-renew on or off for a domain the customer owns.' That scope (a domain the customer owns) plus the on/off binary state makes it unambiguous, and no sibling tool covers autorenew, so there is nothing to confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It prescribes an explicit two-step protocol (confirm:false first to preview, confirm:true only after explicit user yes) and adds a conditional warning for the OFF case. When-to-use, ordering, and the confirmation gate are all stated rather than implied.

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

All Squish toolsInspect
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