SignupBouncer

Change an app's rules

update_rules

DestructiveIdempotent

Needs an API key. Changes the Rules settings of one of your apps, which changes live signup blocking for that app: the next real signups are scored and refused under the new settings. Send only the settings to change. The others stay as they are. Setting mode to "enforce" starts refusing signups marked block, and "shadow" stops refusing any. If one value is wrong, nothing changes and the answer says which. Returns the app's rules afterwards, with the settings that changed. Confirm the change with the user first. A key made for one app changes that app, so leave out "app". An older all-apps key needs "app". The settings are saved, including any text such as block_message, until they are changed again or the app is removed.

Input Schema

Name	Required	Description
`app`	No	The app id (app_...). Leave it out with a key made for one app. An older all-apps key needs it.
`mode`	No	enforce refuses signups. shadow only logs.
`checks`	No	Per check: "default" (our points), "off", "challenge" (always challenge) or "block" (always block, for checks that do not already block). A check above your plan keeps its setting.
`block_at`	No	The score that marks block. Higher than challenge_at.
`velocity`	No	Earlier signups in the window before a velocity rule adds points: 0 turns one off, or 2 to 10,000. app counts this app. account counts all your apps and is 0 or at least app.
`why_link`	No	Add the "Why was this refused?" link to refusals.
`challenge_at`	No	The score that marks challenge.
`block_message`	No	The message a refused person sees, 200 characters at most after we trim spaces from both ends. Empty restores our default, which we word to fit the reason for each refusal.
`challenge_action`	No	What the Supabase and Ory hooks do with a signup marked challenge.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / velocity / properties / domain

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "account": {
+      "description": "0 turns this count off. Otherwise 2 to 10000.",
+      "oneOf": [
+        {
+          "const": 0
+        },
+        {
+          "maximum": 10000,
+          "minimum": 2,
+          "type": "integer"
+        }
+      ],
+      "type": "integer"
+    },
+    "app": {
+      "description": "0 turns this count off. Otherwise 2 to 10000.",
+      "oneOf": [
+        {
+          "const": 0
+        },
+        {
+          "maximum": 10000,
+          "minimum": 2,
+          "type": "integer"
+        }
+      ],
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedOct 21, 2026

changedInput schema / properties / challenge_action / description

Previous value: -"What the Supabase hook does with a signup marked challenge."New value: +"What the Supabase and Ory hooks do with a signup marked challenge."

addedInput schema / properties / checks / properties / ai_agent

Added value: +{
+  "enum": [
+    "default",
+    "off",
+    "challenge",
+    "block"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedOct 20, 2026

changedInput schema / properties / block_message / description

Previous value: -"The message a refused person sees, 200 characters at most after we trim spaces from both ends. Empty restores our default."New value: +"The message a refused person sees, 200 characters at most after we trim spaces from both ends. Empty restores our default, which we word to fit the reason for each refusal."

addedInput schema / properties / checks / properties / stale_list_domain

Added value: +{
+  "enum": [
+    "default",
+    "off",
+    "challenge",
+    "block"
+  ],
+  "type": "string"
+}

AddedOct 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already flag this as a destructive, idempotent write, and the description adds real behavioral context beyond them: the change takes effect on live traffic, updates are partial ("Send only the settings to change. The others stay as they are"), validation is atomic ("If one value is wrong, nothing changes and the answer says which"), settings including block_message persist until changed or the app is removed, and the response returns the post-change rules. It stops short of saying whether the change is reversible or how to undo it, so it sits just under the top mark.

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

Conciseness3/5

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

The API-key prerequisite and the core effect are front-loaded well, but the middle is a string of short choppy sentences that repeat ground already covered by the schema (mode enforce/shadow, the app-id key rule). It is informative but could be tightened without losing substance.

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?

For a 9-parameter, nested-object, destructive write with no output schema, the description covers authentication, partial-update semantics, live effect, atomic failure mode, return value and persistence. An agent has everything needed to call it safely and 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?

Schema coverage is 100%, so 3 is the baseline, but the description adds meaning the schema does not: what enforce vs shadow actually do to real signups, that untouched settings are preserved and that block_message text persists across calls. It does not explain the checks or velocity knobs at all, leaving those entirely to the schema.

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 states a specific verb and resource ("Changes the Rules settings of one of your apps") and immediately names the observable consequence — live signup blocking changes and the next real signups are scored under the new settings. That effect plus the note that it "Returns the app's rules afterwards" clearly separates it from the read-only sibling get_rules.

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?

It gives strong operational guidance: confirm with the user first, send only the settings to change, and how to pick the key (per-app key omits "app", older all-apps key requires it). It states when to use it (to change rules) but never explicitly names get_rules as the read-only alternative, so the alternative-selection guidance is implicit rather than stated.

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

All SignupBouncer 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?