Skip to main content
Glama
dragosh29

WorkMobile MCP server

by dragosh29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Search submitted form records

list_form_submissions
Read-onlyIdempotent

Search submitted records from a WorkMobile form by date, job, mobile user, group, or field values; returns record IDs and answers with personal data withheld by default.

Instructions

Search the records submitted on one form (POST /api/forms/{FormId}/completedrecords/search): by created or uploaded date, job, mobile user, user group, or searchable field values. Each record comes back with its Id, OriginalId and JobId, the system columns, and the answers. Unless include_contact_details is set, answers in fields whose names mark them as personal (names, contact details, addresses, postcodes, signatures, photos, locations, dates of birth, health, pay) and links to media are withheld; in other answers, emails, phone numbers, postcodes and coordinates are redacted, but names and street addresses typed into free text are not. This search is a POST request that only reads. Pages hold 500 records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage to start from (pages hold 500 rows, the smallest page size the API allows)
job_idNoRecords relating to this job (API `jobId`)
form_idYesForm ID (a positive whole number)
max_pagesNoPages of 500 to fetch in this call
created_toNoRecords created on or before this (API `createdDateTo`). A date alone means 23:59:59 UTC.
user_groupNoRecords from users in this user group (API `userGroup`)
max_resultsNoMost rows to return; rows beyond this on pages already fetched are counted, not returned
uploaded_toNoRecords uploaded on or before this (API `uploadedDateTo`)
created_fromNoRecords created on or after this (API `createdDateFrom`). A date alone means 00:00:00 UTC.
newest_firstNoOrder by record Id, newest first (the documented orderBy example) or oldest first
field_filtersNoUser-defined field filters (API `userDefinedFilter`). Different fields are ANDed; the same field given twice is ORed.
uploaded_fromNoRecords uploaded from the device on or after this (API `uploadedDateFrom`)
mobile_user_idNoRecords collected by this mobile user (API `mobileUserId`)
include_contact_detailsNoInclude personal answers and links to media (never downloaded), and stop redacting emails, phone numbers, postcodes and coordinates in other answers. Off by default. Bank, card and payment details are never returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: it details the default PII redaction rules (which field categories are withheld, which values are redacted, and the free-text gaps), states that media links are never downloaded even when include_contact_details is set, notes bank/card/payment details are never returned, and discloses that pages hold 500 records. That is exactly the kind of operational context annotations cannot carry.

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?

Four sentences, each carrying load: search scope, return shape, redaction behavior, and read/POST/paging semantics. It is front-loaded with the endpoint and purpose. The redaction sentence is long and parenthetical-heavy, slightly taxing to parse, which keeps it below a 5.

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 14-parameter search tool with no output schema, the description compensates well: it sketches the returned record (Id, OriginalId, JobId, system columns, answers), states page size and paging intent, and covers the privacy-affecting default. An agent has everything needed to call it correctly.

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 description coverage is 100%, so every parameter is already documented in structured data, which sets the baseline at 3. The description clarifies the practical consequence of include_contact_details (what is unredacted and what remains withheld), but otherwise adds little parameter-level detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 ('Search the records submitted on one form'), scopes it to a single form, and lists the searchable dimensions (dates, job, mobile user, user group, field values). It does not name the sibling get_form_submission or explain how it differs, so it stops short of full sibling differentiation.

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

Usage Guidelines3/5

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

Usage is implied clearly: call this to search/filter records across a form, and the enumerated filter dimensions tell the agent what queries are possible. However, there is no explicit when-not guidance and no routing to the obvious alternative (get_form_submission for a single record), leaving the agent to infer the boundary.

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

Deploy Server

Other Tools