Skip to main content
Glama

Search submissions across forms

search_submissions
Read-onlyIdempotent

Searches the 25 most recently active forms the connection can read and returns matches with the form each came from. Use it when you do not know which form holds what you are looking for; use list_submissions when you do, because that one pages through a single form completely. Takes the same filters. When the answer carries complete false, say the search was partial and narrow it with form_ids, team_id or a date range.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoAny field contains this text, matched literally and without case. Use it first when you do not know which field holds the text. On some forms it covers only the fields recent submissions carry, so reach an older field by name with a field filter.
readNo
fieldNoUp to 5 filters keyed by field name, spelled the way the submissions spell it. Each is an object with one of eq, contains, starts_with, exists or in. Several filters combine with AND. Example: {"email": {"contains": "@example.com"}, "plan": {"in": ["pro", "team"]}}.
limitNoMatches in total across every form searched. There are no pages here, so ask for what you need in one call.
fieldsNoOnly return these submitted fields, separated by commas, such as "email,name". Use it when you are scanning many submissions for one or two values, so the rest does not come back.
statusNoinbox
countryNoTwo-letter uppercase country code. For several, separate them with commas, such as "DE,AT,CH". Max 20.
team_idNoSearch this team only (from list_teams). Defaults to every team the connection covers.
form_idsNoSearch only these forms, separated by commas (from list_forms). Forms the connection cannot read are left out whether or not you name them. Defaults to the 25 most recently active.
created_afterNoRFC 3339 date or time, inclusive.
created_beforeNoRFC 3339 date or time, exclusive.
has_attachmentsNo

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?

Beyond the readOnly/idempotent hints, the description discloses the 25-form scope, that results include the originating form, and that an incomplete result is signaled by complete false. This materially explains behavior an agent otherwise could not infer from annotations or schema.

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 dense sentences front-load purpose, then provide selection guidance, then cover partial-result behavior. No filler or redundant restatement of the schema.

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 complex 12-parameter search tool with no output schema, the description still conveys scope, return association, cross-tool filter equivalence, and post-processing instructions for partial results. Combined with a richly described schema, this is sufficient for correct invocation.

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?

With 75% schema coverage, the schema already documents most parameters. The description adds useful cross-tool guidance with 'Takes the same filters' and ties form_ids, team_id, and date-range parameters to narrowing partial results, though a few booleans (read, has_attachments) still rely on inherited filter semantics.

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 begins with a precise verb and resource: 'Searches the 25 most recently active forms the connection can read and returns matches with the form each came from.' It clearly differentiates from list_submissions by stating when to use which tool.

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 explicitly says to use search_submissions when you do not know which form holds what you are looking for and list_submissions when you do, because that one pages through a single form completely. It also instructs what to do when the answer carries complete false: say partial and narrow with form_ids, team_id or a date range.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources