Skip to main content
Glama
Sign In

Pageree

by com.pageree
OverviewDiscussionsAdmin

Set submission rules

set_form_rules
DestructiveIdempotent

Set the rules that mark a page's form submissions invalid instead of delivering them, such as repeat email addresses, countries, email domains, throwaway mailboxes, domains that cannot receive mail (every rule type is listed below). The visitor always sees success; an invalid submission is kept 30 days in the Submissions inbox, not delivered and not counted as a conversion, and the owner can release it. This REPLACES the whole list: call get_page_information first and send back every rule to keep, with its id. Load get_skill_form_management before using this. Rule types (at most 20 rules per page):

  • country — Marks a submission invalid by the visitor's country, from IP geolocation. "allow" accepts only the countries listed; "block" refuses the ones listed. A visitor whose country is unknown passes. VPNs and private relays move people, so a strict allow list will catch some real visitors: the owner can release them. config: {"mode":{"type":"string","enum":["allow","block"]},"countries":{"type":"array","items":{"type":"string"},"description":"ISO 3166-1 alpha-2 codes, e.g. ["US", "CA", "GB"]."}}

  • email_domain — Marks a submission invalid by the email address's domain. "allow" accepts only the domains listed; "block" refuses the ones listed. An entry covers the domain and its subdomains, so "acme.com" also matches mail.acme.com, and "edu" (or ".edu") matches every address under .edu. config: {"field":{"type":"string","description":"The form field with type="email"."},"mode":{"type":"string","enum":["allow","block"]},"domains":{"type":"array","items":{"type":"string"},"description":"Domains, e.g. ["acme.com", ".edu"]."}}

  • disposable_email — Marks a submission invalid when the email address is a throwaway mailbox (mailinator.com and about ten thousand others, from a public list). config: {"field":{"type":"string","description":"The form field with type="email"."}}

  • mail_server — Marks a submission invalid when the email address's domain cannot receive mail (it does not exist or has no mail server), which catches made-up domains and typos like gmial.con. It does not check that the mailbox itself exists. config: {"field":{"type":"string","description":"The form field with type="email"."}}

  • email_verification — Checks the email address with the owner's own verification provider (ZeroBounce, Kickbox, Emailable, Bouncer) and marks the submission invalid when the provider says the mailbox does not exist; with riskyIsInvalid, also catch-all domains, role and disposable addresses. Each check spends the owner’s credits with that provider. The owner adds the provider’s API key in the console, never in chat. List more than one provider to fall back when the first cannot answer; when none can, the submission is delivered and the owner is emailed. config: {"field":{"type":"string","description":"The form field with type="email"."},"providers":{"type":"array","items":{"type":"string","enum":["zerobounce","kickbox","emailable","bouncer"]},"description":"In order of preference, at most 3, e.g. ["zerobounce"]."},"riskyIsInvalid":{"type":"boolean","description":"Also mark catch-all, role and disposable addresses invalid. Default false."}}

  • phone_verification — Checks the phone number with the owner's own provider (Twilio or Veriphone) and marks the submission invalid when it is not a real number, or when its line type is one the owner blocks (for example "voip"). A number without a country code is read as the visitor’s country’s. Each check spends the owner’s credits with that provider (Twilio charges for line types). The owner adds the provider’s credentials in the console, never in chat. config: {"field":{"type":"string","description":"The form field with type="tel"."},"provider":{"type":"string","enum":["twilio","veriphone"]},"blockedLineTypes":{"type":"array","items":{"type":"string","enum":["mobile","landline","voip","toll_free","premium","other"]},"description":"Line types to mark invalid. Default []."}}

  • duplicate_email — Marks a submission invalid when the same email address was already accepted in the last 90 days, on this form ("form") or on any form in the account whose duplicate rule is also account-wide ("account"). Only a keyed fingerprint of the address is kept, for 90 days; the page's privacy policy must say so (see get_skill_privacy_and_consent). config: {"field":{"type":"string","description":"The form field with type="email"."},"scope":{"type":"string","enum":["form","account"],"description":"Default "form"."},"ignorePlusTags":{"type":"boolean","description":"Treat jane+news@example.com and jane@example.com as one address. Default false."}}

  • content_check — Marks a submission invalid when its message is spam (sales pitches, scams, gibberish), contains profanity, or is not in an accepted language: the checks listed in "checks". An AI model reads every on the form, with email addresses, phone numbers and links removed; a form without one is skipped until it has one. It holds back very few ordinary enquiries, but can hold back as spam a genuine offer or a customer giving bank details for a refund, and as profanity a real customer who swears; the owner can release them. Messages under three words pass the language check, and close neighbours count as each other (Danish and Norwegian, Croatian and Serbian). The page's privacy policy must name the model's provider (see get_skill_privacy_and_consent). config: {"checks":{"type":"array","items":{"type":"string","enum":["spam","profanity","language"]},"description":"Any of "spam", "profanity", "language"."},"languages":{"type":"array","items":{"type":"string"},"description":"With the "language" check: the ISO 639-1 codes accepted, e.g. ["en", "es"]."}}

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": {
      "pageId": "<pageId>",
      "rules": "<rules>"
    },
    "name": "set_form_rules"
  }
}

Input Schema

NameRequiredDescriptionDefault
rulesYesThe complete list of rules for the page. [] removes every rule.
pageIdYesThe pageId returned when the page was published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint, idempotentHint) by disclosing that the visitor still sees success, invalid submissions are retained 30 days and excluded from conversions, owners can release them, and verification rules spend provider credits. It also flags side effects and prerequisites like API keys being set in the console, never in chat.

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 critical replace-all constraint and prerequisite calls are front-loaded in two sentences, and the rule-type list is structured and skimmable. The body is long, but each entry documents a distinct config shape that would otherwise be undocumented, so the bulk is largely justified.

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 destructive, replace-all mutation on a polymorphic nested payload with no output schema, the description covers ordering, retention, side effects, failure modes, provider costs, privacy obligations, and per-type config. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description is the sole source of meaning for the polymorphic `config` object — listing each type's fields, enum values, defaults, and semantics (e.g. allow/block behavior, subdomain matching, provider fallback order). This adds substantial meaning beyond 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?

Opens with a specific verb and resource: 'Set the rules that mark a page's form submissions invalid instead of delivering them', and enumerates the eight rule types. This clearly separates it from siblings like set_delivery and set_goal, which configure different page behavior.

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?

Explicit sequencing is given: call get_page_information first, send back every rule to keep with its id, and load get_skill_form_management beforehand. It also names a dependency for one rule type (get_skill_privacy_and_consent) and states the replace-all semantics that determine when this tool is the right call.

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

All Pageree 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