Skip to main content
Glama
dragosh29

WorkMobile MCP server

by dragosh29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Search jobs

list_jobs
Read-onlyIdempotent

Search WorkMobile jobs by status, dates, users, types, priority, backlog and duration filters; returns job details with location withheld unless contact details are included.

Instructions

Search jobs with the filters POST /api/jobs/search documents: status IDs, estimated start date range, the mobile users they are allocated to, job types, a description, priority, backlog and whether a duration is set. Returns job ID, description, status ID, type, priority, dates and allocation; the job's location is withheld unless include_contact_details is set. In descriptions, emails, phone numbers, postcodes and coordinates are redacted, but names and street addresses typed into them are not. This search is a POST request that only reads. Pages hold 500 jobs; a page with fewer than 500 is the last.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage to start from (pages hold 500 rows, the smallest page size the API allows)
backlogNoOnly backlog jobs (true) or only non-backlog jobs (false) (API `backlog`)
priorityNoOnly jobs with this priority (API `priority`)
max_pagesNoPages of 500 to fetch in this call
status_idsNoOnly jobs with these status IDs (API field `jobStatusId`); decode them with list_job_statuses. WorkMobile's own example uses [1,2,3,5] for jobs that are not closed.
descriptionNoJobs matching this description (API `description`)
max_resultsNoMost rows to return; rows beyond this on pages already fetched are counted, not returned
has_durationNoOnly jobs with a duration set (API `hasDuration`)
job_type_idsNoOnly jobs of these types (API `jobTypeIds`)
mobile_user_idsNoOnly jobs allocated to these mobile users (API `allocatedToUserId`)
estimated_start_toNoJobs estimated to start on or before this (API `estimatedStartDateTimeTo`). A date alone means 23:59:59 UTC that day.
estimated_start_fromNoJobs estimated to start on or after this (API `estimatedStartDateTimeFrom`). A date alone means 00:00:00 UTC that day.
include_contact_detailsNoInclude the job location (address), and stop redacting emails, phone numbers, postcodes and coordinates in descriptions and names. Off by default. Bank, card and payment details are never returned.
order_by_estimated_startNoSort by estimated start (API orderBy on `estimatedStartDateTimeFrom`, as in WorkMobile's example)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark it readOnly/idempotent/non-destructive, and the description still adds substantial context: it explains the POST-but-reads-only quirk, the 500-row page size and last-page detection rule, and the precise redaction policy (emails/phones/postcodes/coordinates redacted, names/street addresses not). It also notes the location is withheld unless include_contact_details is set.

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?

A dense, front-loaded paragraph that leads with the search filters, then return shape, then pagination. Most sentences earn their place, though the filter list is somewhat redundant with the schema and could be trimmed.

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?

With no output schema, the description carries the return-value burden and does so ('job ID, description, status ID, type, priority, dates and allocation'), and adds pagination and privacy semantics. An agent has everything needed to call and interpret results.

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 each parameter is already fully documented with API field mappings. The description's filter enumeration largely mirrors the schema rather than adding syntax or edge-case detail beyond it, so the baseline of 3 applies.

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?

States a specific verb and resource ('Search jobs'), names the underlying endpoint, and enumerates exactly what can be filtered on. It is trivially distinguishable from siblings like get_job (single fetch) or list_job_statuses (lookup).

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?

Gives clear operational context and routes the agent to list_job_statuses for decoding status IDs, which is a genuinely useful dependency hint. It does not, however, state when NOT to use this tool versus get_job for single-record retrieval, so it falls short of the explicit when/when-not bar.

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