Skip to main content
Glama
Sign In

BootForm

by com.bootform
OverviewDiscussionsAdmin

Check a form for spam

bootform_check_spam
Read-onlyIdempotent

Checks one form for a spam problem and returns facts, not a verdict: inbox, archived and spam counts over the last days days; the spam folder by reason (honeypot filled, honeypot missing, moved by hand); the form's spam protection; and inbox signals (submissions with links, several from one IP within a minute, identical messages) with their ids. Read a sample with bootform_get_submissions and judge for yourself. Then propose fixes in this order: turn the honeypot on if it is off (bootform_configure_form honeypot_enabled, and put the field on the page); if it is on and spam still gets through, renaming it does not help (these bots leave every hidden field empty), so suggest Turnstile, which the person sets up in the dashboard (never ask for CAPTCHA keys). Offer to move spam to the spam folder (bootform_mark_submission spam: true) or delete it (bootform_delete_submissions), naming the ids and asking first.

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": {
      "form_id": "<form_id>"
    },
    "name": "bootform_check_spam"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoHow many days back to look (default 14, max 90)
form_idYesThe form's id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already establish that this is a read-only, idempotent, non-destructive lookup. The description adds substantial behavioral context: it returns facts rather than a verdict, lists the exact categories of returned data, includes submission ids, warns never to ask for CAPTCHA keys, and requires confirmation before destructive follow-up actions.

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 description is front-loaded and every section is useful, but it is unusually long and includes a full remediation workflow rather than only what is needed to select and invoke this tool. It remains dense and readable rather than padded, so it is strong but not maximally concise.

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?

There is no output schema, so the description carries the burden of explaining return values. It does so thoroughly by naming the counts, spam-reason breakdown, protection information, inbox signals, and ids, leaving the agent well equipped to call and interpret the tool.

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 the two parameters are already fully documented in the schema. The description only reinforces that the tool checks one form and uses a `days` window for counts, which adds little beyond the schema's own descriptions.

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: it checks one form for spam and returns facts such as inbox, archived, spam counts, spam reasons, protection status, and inbox signals. It explicitly distinguishes its role from bootform_get_submissions by saying the agent should read a sample there and judge for itself.

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 gives explicit usage guidance: use bootform_get_submissions to inspect a sample, then propose fixes in a specified order. It names the relevant sibling tools for honeypot setup, Turnstile, moving spam, and deletion, and says to ask first before moving or deleting.

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

All BootForm toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources