- Brand
- Sitemate
- Category
- Productivity
- Primary Subcategory
- Field Service Management Software
Integration details
Description
The Sitemate app in ChatGPT lets you search, query, and interact with your construction and project management data in one place. Access information stored across Sitemate, including Dashpivot, using natural language to surface insights, track progress, and answer questions instantly.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Field Service Management Software
- Secondary Subcategories
- None listed
- Brand
- Sitemate
- Access
- Account required
- First tracked
- 2026-09-28
- Tool count
- 23
- Market
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Agent Discoverability
ChatGPT Plugin Discovery ScoreYour score is coming
ChatGPT now suggests Plugins on its own when they match a user's request.Your Plugin Discovery Score measures how often yours appears, and it will show here as soon as it’s ready.
What discovery looks like
Get alerts for Sitemate
Get updates when Sitemate’s Discoverability Score or category rank changes.
Competing in ChatGPT Field Service Management Software
View Category23 tools agents can invoke
Lists Dashpivot actions from the actions register: what is open, overdue, or assigned to someone. ## When to Use - "What actions are open / overdue?" → call with no arguments. - "What is assigned to me?" → `{ assignedToMe: true }` - "Show me the top 10 actions across my workspace" → `{ pageSize: 10 }` - "What actions are open in this project?" → `{ _path: ["/ws_xxx/p_xxx"] }` - For the actions linked from a specific form ("what actions came out of this inspection?"), use dashpivot_get_forms instead: each Actions field there already carries status, assignee and due date. ## Defaults No arguments returns open actions across every workspace you can access, overdue first (earliest due date first, undated last), 25 per page. An action is open until it reaches its template's final workflow column. ## Who Sees What Matches the web app. A workspace member sees the whole register. A project member sees actions raised from forms in that project and its teams; a team member sees actions raised from forms in that team. Without _path you also see actions assigned to you and actions you created directly in the register. ## Parameters (all optional) - **_path**: workspace, project or team paths from dashpivot_get_workspace_structure. Narrows to that folder exactly like its register on web. You can only pass folders you have access to. - **status**: "open" (default), "closed", "all", or workflow column titles listed in availableStatuses. - **overdue**: true for open actions past their due date. - **dueBefore / dueAfter**: ISO 8601 due-date bounds (inclusive). - **assignedToMe**: true for actions assigned to you. - **assigneeIds**: Sitemate user ids (sitemateUserId from dashpivot_get_users, or assignees[].id from a previous response). - **pageSize / pageCursor**: pagination; pass pageDetails.cursor as pageCursor for the next page. ## Response results[] holds one record per action: name, url (opens it in the web actions register; cite it), status and workflowColumn, isOpen, isOverdue, dueDate, assignees ({ id, name? }; name is absent when unresolved, never show the id as a name), source (form, project, team it was raised from), fields[] (description and completion notes under their template labels), createdAt, updatedAt. Each page also returns totalActionCount, availableStatuses and instructions. When results come from several regions, they are ordered within each region. - A top-level `results` (Copilot clients only) is a { url, title } citation list for client rendering — read action data from data.results, not here. ## Examples - Open actions: `{}` - Overdue in a project: `{ _path: ["/ws_xxx/p_xxx"], overdue: true }` - Everything assigned to me, including closed: `{ assignedToMe: true, status: ["all"] }` - Due this month: `{ dueAfter: "2026-10-01T00:00:00Z", dueBefore: "2026-10-31T23:59:59Z" }` <!-- mcp-router:region-aware-pagination --> **Pagination across regions:** The response includes `pageDetails.regions` keyed by region (e.g. `au1`, `uk1`). To get the next page, pass `pageCursor` as a JSON object (not a string) with an entry for each region where `isLastPage: false`. Example: `pageCursor: {"au1": "ws_abc", "uk1": "ws_xyz"}`. Omit `pageCursor` entirely for the first page. `pageSize` applies per-region — the response may include up to `pageSize × N` items where N is the number of regions with data.
dashpivot_get_actions
Retrieves form data (filled-in records) for summarization, analysis, and reporting. ## When to Use - If the user provides a specific _path, call dashpivot_get_forms directly — do NOT call dashpivot_get_workspace_structure or dashpivot_get_templates first. - If the user asks about forms without a path, follow the standard discovery workflow. - If dashpivot_get_forms returns 0 results, check the instructions field for diagnostic guidance before making follow-up calls. - Actions fields on returned forms are enriched inline with each linked action's status, assignee and due date. For open, overdue or assigned-to-me questions that do not start from a form, call dashpivot_get_actions instead. ## Required Parameter - **_path**: Array of FlakeID paths (max 100). Use `_path` values from dashpivot_get_templates or dashpivot_get_workspace_structure (e.g., ["/ws_xxx/p_xxx/app_xxx"] or ["/ws_xxx"]). ## Key Parameters - formName / fieldFilters: Filter forms - workflowStep: Filter by workflow column — accepts position numbers (1, 2) and/or column name strings ("Supervisor Approval"). Case-insensitive. - createdDate: Filter by creation date range (`{ after?, before? }` — ISO 8601 strings in **UTC**, e.g. `2026-01-01T00:00:00Z`). Use when the user is asking about when forms were *started* or *opened*. - updatedDate: Filter by last-updated date range (`{ after?, before? }` — ISO 8601 strings in **UTC**, e.g. `2026-01-01T00:00:00Z`). Use when the user is asking about when forms were *submitted*, *completed*, or *finalised* — `updatedAt` advances when a draft is filled in or saved, while `createdAt` is fixed at the moment the form was first opened. - fieldIds: Return only specific fields (use IDs from dashpivot_get_templates) - includeArchived: Defaults to false (active forms only) — leave this unset for ordinary questions like "how many forms are there". Only set true when the user explicitly asks about archived, historical, or "all" forms regardless of status; `totalFormCount` will then include archived forms too. - pageSize (default 10, max 10), pageCursor for pagination ## Choosing createdDate vs updatedDate A form can be drafted on day 1 and submitted on day 8. `createdAt` is fixed at draft time; `updatedAt` reflects the last save. Map customer phrasing to the right filter: - "submitted / completed / filled out / finalised in the last week" → `updatedDate` - "started / drafted / opened / created in the last week" → `createdDate` - Both filters can be combined; they compose with AND. - When the intent is ambiguous, prefer `updatedDate` and state the choice in your reply. - All date bounds are interpreted as **UTC**. Convert any relative or local-time phrasing ("today", "last week") to absolute UTC ISO 8601 strings before calling. ## Response Format (compact) Compressed JSON with ~63% fewer tokens. Field values are lossless. Forms are grouped by app. Structure: - `apps`: array of app groups, each containing: - `appPath`: shared app path for this group - `fields`: array of { name, kind } — field definitions declared once per app - `forms`: array of { id, name, num, workflowCol, created, by, state, values } — each form's `values` array is positionally mapped to `fields` - `results` (Copilot clients only): one { url, title } per form, for client citation rendering — read form data from `apps`, not here - Shortened keys: id=itemId, num=automatedFormNumber, workflowCol.pos=workflowColumn.position, workflowCol.name=workflowColumn.name, created=createdAt, by=createdBy.name - `state` (e.g., "active", "archived") is present per form when includeArchived is true, so you can tell which forms in a mixed result are archived - Pagination: pass `pageDetails.cursor` back as `pageCursor` to fetch the next page. `pageDetails.pageNumber` is informational only. Example response: ``` {"apps":[{"appPath":"/ws_xxx/p_xxx/app_xxx","fields":[{"name":"Inspector","kind":"singleLineInput"},{"name":"Status","kind":"category"}],"forms":[{"id":"form_xxx","name":"Inspection #1","num":"SI-001","workflowCol":{"pos":2,"name":"Supervisor Approval"},"created":"2026-03-20T10:00:00Z","by":"John","state":"active","values":["Michael",[{"name":"Pass","value":"pass"}]]}]}],"totalFormCount":42,"instructions":["Sending form 1 of 42.","More results available. Pass the cursor value as pageCursor to fetch the next page."],"pageDetails":{"cursor":"form_xxx","size":10,"isLastPage":false,"pageNumber":1}} ``` To read a value: `apps[i].forms[j].values[k]` corresponds to `apps[i].fields[k]`. Field IDs for fieldFilters/fieldIds are available from dashpivot_get_templates. ## Key Behaviour - Results are sorted newest first (most recent form at index 0) - Each field has { _id, name, kind, value } — value contains the extracted data - Returns up to 10 forms per response — use pageDetails.cursor for pagination when more results exist - More specific _path values return faster results - Field value structures vary by kind — see dashpivot_get_templates field definitions for type metadata ## Examples - Get all forms for an app: `{ _path: ["/ws_xxx/p_xxx/app_xxx"] }` - Forms from Q1 2026: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], createdDate: { after: "2026-01-01T00:00:00Z", before: "2026-04-01T00:00:00Z" } }` - Forms submitted in Q1 2026: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], updatedDate: { after: "2026-01-01T00:00:00Z", before: "2026-04-01T00:00:00Z" } }` - Return only text fields: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], fieldIds: ["fi_xxx", "fi_yyy"] }` - Forms in approval step: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], workflowStep: ["Supervisor Approval"] }` - Forms in columns 1 or 2: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], workflowStep: [1, 2] }`
dashpivot_get_forms
Retrieves Dashpivot lists (spreadsheet-like data containers): columns, items, and property values. Lists power list fields and list property columns in forms — use this to understand what data populates form dropdowns and lookup fields. ## Modes (dispatched by leaf prefix of each _path) - **Browse** (leaf is ws_ or p_): returns list metadata plus `columns` (so the LLM can see what each list is shaped like and read `columns[].id` for follow-up `columnFilters`). `items` and `itemsPagination` are omitted. Use when discovering which lists exist under a workspace/project. - **Details** (leaf is li_): returns full data for the named list — columns, items, and property values. Use when a specific list has been identified to inspect. `columns` is always present on every list entry (empty array when the list has no columns). Browse and details paths can be mixed in one call — each entry resolves on its own leaf prefix. ## When to Use - If the user provides a specific _path, call dashpivot_get_lists directly — do NOT call dashpivot_get_workspace_structure first. - If the user asks about lists without a path, follow the standard discovery workflow: browse first, then narrow to a li_ path for details. - If dashpivot_get_lists returns 0 results, check the instructions field for diagnostic guidance. ## Required Parameter - **_path**: Array of FlakeID paths (max 100). Workspace/project paths (e.g., ["/ws_xxx"], ["/ws_xxx/p_xxx"]) trigger browse mode; list paths (e.g., ["/ws_xxx/li_xxx"]) trigger details mode. ## Key Parameters - listName: Filter by list name (case-insensitive partial match) — narrows which lists are returned in browse mode. - itemValue: Filter items by display value — the Item column shown in the list library (case-insensitive partial match). Only meaningful in details mode. - columnFilters: Filter items by column values. AND across entries, OR within each entry's queries. Each filter has a `columnId` (lp_ FlakeID — read from `columns[].id` in a prior details response), `queries` (array of one or more string/number values for OR matching within the entry), and an optional `match` mode controlling how each query compares to the cell value: `"contains"` (default — case-insensitive substring), `"exact"` (case-insensitive equality — use for IDs, codes, and precise numeric matches: `queries: ["1"]` with `match: "exact"` matches `"1"` only, NOT `"10"` or `"9991"`), or `"prefix"` (case-insensitive starts-with). To find rows where a column is empty / has no value, fetch the list without columnFilters and look for null in each item's positional properties array at the relevant column index. Only items matching ALL filter entries are returned. Only meaningful in details mode. - pageSize (default 25, max 25), pageCursor for list-level pagination. - itemPageSize (default 100, max 1000) — items per details list per page. Silently ignored for browse paths. - itemCursors — per-list item pagination cursors keyed by full list path (e.g. `{ "/ws_xxx/li_yyy": "lr_..." }`). Each value is an item FlakeID from a previous response's `itemsPagination.cursor`. Lists not in the map start at page 1; cursors for lists not in `_path` are silently ignored. ## Response Shape (compact) - `results` (Copilot clients only) is a { url, title } citation list for client rendering — read list data from `lists`, not here. - Browse entries emit `{ id, path, name, created, updated, columns }` — no `items`, no `itemsPagination`. - Details entries additionally emit `{ items, itemsPagination }`. Keys are shortened: `id`=itemId, `path`=full `_path`, `created`=createdAt, `updated`=updatedAt. - `columns` is always present (empty array when the list has no columns). - `columns` is declared once per list as `[{ id, name, model }]` where `id` is the lp_ FlakeID (use it for `columnFilters[].columnId`) and `model` is one of: `text-simple`, `number-simple`, `date-simple`, `date-expiry`, `attachment-simple`. Use `model` to interpret each column's values. - `items` is an array of `{ id, value, properties }`. `properties` is a positional array — `properties[i]` corresponds to `columns[i]`. Length always equals `columns.length`; missing/unsupported properties are `null`. - `itemsPagination` is `{ cursor?, isLastPage }`. To fetch more items for a list, pass back the cursor via top-level `itemCursors` keyed by the list's `path`. ## Key Behaviour - Browse mode returns metadata only; details mode returns columns, items, and per-list `itemsPagination`. - Only active lists and items are returned. - Details entries are always returned even when filters yield no items on the current page — advance via `itemsPagination.cursor` to look further. Browse entries don't carry `itemsPagination`. - When `columnFilters` is set, pages reliably fill up to `itemPageSize` matched items; `itemsPagination.isLastPage` is true exactly when no further matches exist. - `columnFilters[].columnId` must be a valid lp_ FlakeID read from `columns[].id` on a prior details response — names are not accepted. Filters whose `columnId` is not on the list contribute no matches. - Lists exist at workspace or project level (never teams). Workspace-level lists can be deployed into projects. ## Examples - Discover lists in a workspace (browse): `{ _path: ["/ws_xxx"] }` - Inspect a specific list (details): `{ _path: ["/ws_xxx/li_xxx"] }` - Browse then narrow: first call with the workspace path to see what lists exist, then call again with the chosen list's li_ path to fetch its data. - Find lists by name: `{ _path: ["/ws_xxx"], listName: "Materials" }` - Search items by display value: `{ _path: ["/ws_xxx/li_xxx"], itemValue: "Concrete" }` - Filter items by column value: `{ _path: ["/ws_xxx/li_xxx"], columnFilters: [{ "columnId": "lp_xxx", "queries": ["Active"] }] }` - OR within a column: `{ _path: ["/ws_xxx/li_xxx"], columnFilters: [{ "columnId": "lp_xxx", "queries": ["Active", "Pending"] }] }` - Multiple column filters (AND): `{ _path: ["/ws_xxx/li_xxx"], columnFilters: [{ "columnId": "lp_type", "queries": ["Steel"] }, { "columnId": "lp_grade", "queries": ["A"] }] }` - Advance one list's items: `{ _path: ["/ws_xxx/li_a", "/ws_xxx/li_b"], itemCursors: { "/ws_xxx/li_a": "lr_..." } }` — only `li_a` advances; `li_b` returns item page 1.
dashpivot_get_lists
Retrieves app (template) definitions from Dashpivot with field-level metadata. ## Purpose Gateway to form data. Discover apps, review field definitions, select field IDs before calling dashpivot_get_forms. ## Prerequisites - For browse queries: call dashpivot_get_workspace_structure first to discover the hierarchy, then pass _path values. - For direct lookup: use `appIds` with any app identifier (FlakeID, ObjectId, or unique app ID). No _path needed — the server resolves it automatically. - If the user provides a Dashpivot URL, extract the ID from the URL path and pass it to `appIds`. ## Scoping Rules - **Preferred**: Use a project/team _path (e.g., "/ws_xxx/p_xxx") for targeted browse results. - **Broader**: Using a workspace _path ("/ws_xxx") may return many apps — only use for workspace-level apps or when a narrower _path is unavailable. - Combine _path with appName or templateTags to narrow results further. ## Parameters - appIds: Look up apps by any identifier — FlakeID (app_xxx), MongoDB ObjectId (24 hex chars), or unique app ID (e.g. TDW-C-JK6AQ). No _path needed. - _path: Required for browse queries, optional when appIds is provided. Use the narrowest paths available (e.g., ["/ws_xxx/p_xxx"]). - appName / templateTags: Filter apps - pageSize (default 25, max 25), pageCursor for pagination ## Key Behaviour - List/browse queries return app metadata with `fieldCount` only — look up specific apps by `appIds` to get full field definitions - Each app includes a `_path` field — use directly as `_path` in dashpivot_get_forms (e.g., ["/ws_xxx/p_xxx/app_xxx"]) - For workspace-wide queries, use `_path: ["/" + workspaceId]` (e.g., ["/ws_xxx"]) - Action templates are listed with `kind: 'action'`. For open, overdue or assigned actions, call dashpivot_get_actions instead of reading the action template's forms. - A `/ws_xxx/app_xxx` path returns both workspace-level apps and their team-level deployed copies together, only team-deployed copies have forms. To dashpivot_get_forms, pass in a team-level path `/ws_xxx/p_xxx/p_xxx/app_xxx` as `_path`. ## Field Selection for dashpivot_get_forms When calling dashpivot_get_forms, pass specific field IDs via the optional `fieldIds` parameter to control which fields are returned. Omitting fieldIds returns ALL fields including media (photo, signature, sketch) which contain large binary data. Select fields based on the task: - For text analysis: use singleLineInput, multiLineInput fields - For date filtering: use date fields - For status checks: use category, yesNoCheckbox fields - Avoid media fields (photo, signature, sketch, attachment) unless specifically needed — they contain large binary data ## Examples - Browse all apps in a project: `{ _path: ["/ws_xxx/p_xxx"] }` - Find safety templates: `{ _path: ["/ws_xxx/p_xxx"], templateTags: ["safety"] }` - Get field definitions for a specific app: `{ appIds: ["app_xxx"] }` <!-- mcp-router:region-aware-pagination --> **Pagination across regions:** The response includes `pageDetails.regions` keyed by region (e.g. `au1`, `uk1`). To get the next page, pass `pageCursor` as a JSON object (not a string) with an entry for each region where `isLastPage: false`. Example: `pageCursor: {"au1": "ws_abc", "uk1": "ws_xyz"}`. Omit `pageCursor` entirely for the first page. `pageSize` applies per-region — the response may include up to `pageSize × N` items where N is the number of regions with data.
dashpivot_get_templates
Retrieves user information within a workspace's folder hierarchy. ## Modes - **users-in-folder**: List the users in a specific folder. - **folders-for-user**: Given a person's name or email, list which folders they can access within the queried workspace(s). ## PII Protection Every user in the response has `lastName` reduced to its initial (e.g. "S") and `email` masked (e.g. "j***@example.com"). `firstName`, `sitemateUserId`, and `_id` are unmasked. Do not reconstruct or guess full names/emails from the masked values — ask the human if you need the original. ## When to Use - "Who has access to this project?" → mode "users-in-folder" - "Which folders can <person> access?" / "What is <person>'s access in this workspace?" → mode "folders-for-user" ## Required Parameters - **_path**: Array of 1-100 FlakeID paths from dashpivot_get_workspace_structure. Each must be workspace-rooted (e.g. "/ws_xxx" or "/ws_xxx/p_xxx"). Paths may span multiple workspaces. - **mode**: "users-in-folder" or "folders-for-user" ## Mode-Specific Parameters - **users-in-folder**: pageSize, pageCursor. Pass multiple paths to union users across folders — a user who appears in any queried folder is returned once. Lists users granted on the queried folder OR a sub-folder beneath it; access inherited from a PARENT is not reflected (query the parent folder to see its controllers). - **folders-for-user**: provide `name` or `email` (exact match, takes precedence over name). `name` uses case-insensitive **exact** equality, not substring/partial — "John" matches users whose firstName OR lastName is exactly "John"; "John Smith" matches firstName "John" AND lastName "Smith". Returns one of: a single **user-match** with their accessible folders (inheritance-aware — a workspace controller is listed for a queried child folder); a **disambiguation** signal carrying NO user data when multiple users share the name (ask the human for the exact email, then re-call with `email`); or **no-match**. ## Notes - users-in-folder membership is a superset of folders-for-user reachability. users-in-folder lists a user straight from the permission service regardless of whether the granting folder is still active, so it can include grants on archived/deleted sub-folders that folders-for-user (which resolves to active folders only) will not return. ## Examples - Users in a project: `{ _path: ["/ws_xxx/p_xxx"], mode: "users-in-folder" }` - Users across multiple projects: `{ _path: ["/ws_xxx/p_a", "/ws_xxx/p_b"], mode: "users-in-folder" }` - Users across workspaces: `{ _path: ["/ws_A", "/ws_B"], mode: "users-in-folder" }` - Folders a user can access: `{ _path: ["/ws_xxx"], mode: "folders-for-user", name: "John Smith" }` - Disambiguate by exact email: `{ _path: ["/ws_xxx"], mode: "folders-for-user", email: "john.smith@example.com" }`
dashpivot_get_users
Browse the Sitemate workspace hierarchy by drilling from workspaces → projects → teams. Returns a level-discriminated page — one of `workspaces[]`, `projects[]`, or `teams[]` per call, never the full tree. Use `_path` values from one response as input to the next. ## When to Call First tool in any workflow. Walk the 3-call pattern below to resolve a workspace name to a project or team `_path`, then pass that `_path` to tools like `dashpivot_get_templates`. ## Parameters - `_path` (string[]): omit to list workspaces; `["/ws_xxx"]` to list projects in a workspace; `["/ws_xxx/p_yyy"]` to list teams in a project. - `nameFilter` (string): case-insensitive partial match on the entity name at the current `_path` level. Use short, distinctive substrings (`"Acme"`, not `"Acme Construction Pty. Ltd."`). - `state`: `"active"` (default), `"archived"`, or `"deleted"`. Workspaces don't support `"deleted"`. - `pageSize`: default 50, max 50. - `pageCursor`: pass `pageDetails.cursor` from the previous response. ## Response Always carries `level` + `instructions[]`. Switch on `level` before accessing arrays: - `level: "workspace"` → `workspaces[]` (`itemId`, `_path`, `name`, `projectCount`, `totalTeamCount`) - `level: "project"` → `projects[]` (`itemId`, `_path`, `name`, `teamCount`) - `level: "team"` → `teams[]` (`itemId`, `_path`, `name`) Empty pages omit the array entirely; check `pageDetails.isLastPage` before paginating. ## Worked example (browse → drill → drill) 1. `dashpivot_get_workspace_structure({})` → `level: "workspace"`, e.g. `_path: "/ws_acme"` 2. `dashpivot_get_workspace_structure({ _path: ["/ws_acme"] })` → `level: "project"`, e.g. `_path: "/ws_acme/p_highway"` 3. `dashpivot_get_workspace_structure({ _path: ["/ws_acme/p_highway"] })` → `level: "team"`, e.g. `_path: "/ws_acme/p_highway/p_safety"` Pass the final `_path` to `dashpivot_get_templates` to fetch apps at that scope. ## Cursor-error recovery Cursors are scope-bound to the level that issued them. Reusing a cursor across scopes returns a `BadRequestError` with a `cursorValidationFailureMode` discriminator (`workspace-cursor-on-drill-down`, `drill-down-cursor-on-workspace`, or `unrecognised-prefix`). Recovery: drop the cursor and retry without it. Don't try to translate cursors across scopes. <!-- mcp-router:region-aware-pagination --> **Pagination across regions:** The response includes `pageDetails.regions` keyed by region (e.g. `au1`, `uk1`). To get the next page, pass `pageCursor` as a JSON object (not a string) with an entry for each region where `isLastPage: false`. Example: `pageCursor: {"au1": "ws_abc", "uk1": "ws_xyz"}`. Omit `pageCursor` entirely for the first page. `pageSize` applies per-region — the response may include up to `pageSize × N` items where N is the number of regions with data.
dashpivot_get_workspace_structure
Assemble the full picture for one asset in a single call: the asset, its open issues, recent work orders, recent inspections, and its schedule-check compliance. ## When to use - Answer "give me everything on asset X" / "what's the state of E-204?" — returns everything related to one asset (work orders, issues/faults, schedule checks, inspections) in a single call, the way the Assets tab does. - Prefer this over calling gearbelt_get_issues / gearbelt_get_work_orders / gearbelt_get_inspections / gearbelt_get_schedule_checks separately for one asset. - The nested issues / work orders / inspections carry who raised or submitted them (createdBy / submittedBy + ids), so you can answer "who's been working on this asset". ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `assetId` (required) — the asset's UUID. Find it with gearbelt_get_assets (its `search` matches asset code, make, model, registration, or serial), then pass the returned id. - `intent` / `conversationId` (optional) — always include for call tracing. ## Response format Returns an object: - `url` — absolute web link to this asset's page (the citation source for the record). - `asset` — id, internalId, manufacturer, model, class, type, registration, state, category, location. - `openIssues` — up to 20 open issues (each: id, num, title, sev, wo, repair, …). - `workOrders` — up to 20 recent work orders (each carries its status). - `recentInspections` — up to 5 most-recent inspections. - `compliance` — { total, ok, due, overdue, complianceRate, checks[] } over open schedule checks (dueStatus derived overdue/due/ok). - `instructions` — short guidance strings; read them. ## Example `{ "_path": "/ws_4oxc6SXZdYm", "assetId": "<asset id from gearbelt_get_assets>" }`
gearbelt_get_asset_context
List assets (plant, vehicles, tools & equipment) in a Gearbelt workspace. ## When to use - Call `gearbelt_get_workspaces` first to get a workspace `_path`, then call this tool with it. - Fetch one page at a time; only request the next page when the user asks for more. - This is a list/search tool. For **everything about one asset** — its open issues, work orders, recent inspections, and compliance ("full picture", "current state", "everything on E-204") — use this only to resolve the asset code to its `id`, then call `gearbelt_get_asset_context`; don't rebuild that picture from separate list calls. - Each row carries the operator (`operatedBy` name + `operatedById`), when set. Count `operatedById` for "who operates the most assets". ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `limit` (optional) — max rows this page (default 30, max 100). - `search` (optional) — free-text across asset code, make, model, registration, serial. - `state` (optional) — filter by record state; defaults to active (pass archived/deleted to include those). - `types` (optional) — restrict to asset type(s). - `orderBy` / `orderDir` (optional) — sort field and direction. - `intent` / `conversationId` (optional) — always include for call tracing. Prefer `search`/`state`/`types` over paging through everything — filtering server-side is cheaper and more accurate. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. `instructions` is a short list of guidance strings (result count, pagination, next steps) — read them. ## Fields returned - `id` (id) — string — Gearbelt asset UUID - `iid` (internalId) — string|null — user-facing asset code - `mfr` (manufacturer) — string|null - `mdl` (model) — string|null - `cls` (class) — string|null — free-text class / sub-type - `reg` (registration) — string|null - `sn` (serialNumber) — string|null - `type` (type) — enum — "Assets" | "Tools and Equipment" - `state` (state) — enum — "active" | "archived" | "deleted" - `cat` (category) — string|null — category name - `loc` (location) — string|null — location name - `operator` (operatedBy) — string|null — name of the user this asset is operated by - `operatorId` (operatedById) — string|null — stable id of the operator (count/group by this for per-user totals) - `created` (createdAt) — string — ISO 8601 date-time ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor` to fetch the next page. ## Example `{ "_path": "/ws_4oxc6SXZdYm" }`
gearbelt_get_assets
List inspections in a Gearbelt workspace, each with its readings and units (e.g. 150 hrs). ## When to use - Call `gearbelt_get_workspaces` first to get a workspace `_path`, then call this tool with it. - Fetch one page at a time; only request the next page when the user asks for more. - Each row carries the submitter (`submittedBy` name + `submittedById`). Count `submittedById` for "who submitted the most inspections"; for "who hasn't submitted", diff the submitters against the roster from gearbelt_get_users. ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `limit` (optional) — max rows this page (default 30, max 100). - `search` (optional) — free-text across inspection number and form name. - `formName` (optional) — filter to inspections captured with this form/template name. - `assetIds` (optional) — restrict to inspections on these asset(s), by asset UUID from gearbelt_get_assets (its `search` finds an asset by code, make, model, registration, or serial). - `orderBy` / `orderDir` (optional) — sort field and direction. - `intent` / `conversationId` (optional) — always include for call tracing. Prefer filters over paging through everything — filtering server-side is cheaper and more accurate. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. `instructions` is a short list of guidance strings (result count, pagination, next steps) — read them. ## Fields returned - `id` (id) — string — inspection id - `num` (number) — integer — sequential inspection number - `date` (inspectionDate) — string — ISO 8601 date-time - `readings` (readings) — array of { value: number, unit: string, unitName: string } — readings - `issues` (issueCount) — integer — issues raised on this inspection - `asset` (asset) — string|null — linked asset internalId - `loc` (location) — string|null — location name - `by` (submittedBy) — string|null — name of the user who submitted the inspection - `byId` (submittedById) — string|null — stable id of that user (count/group by this for per-user totals) - `created` (createdAt) — string — ISO 8601 date-time ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor` to fetch the next page. ## Example `{ "_path": "/ws_4oxc6SXZdYm" }`
gearbelt_get_inspections
List issues (defects/faults raised on assets) in a Gearbelt workspace. ## When to use - Customers and mechanics call these "faults" or "defects" — a question about faults/defects on an asset maps to this tool. - The first hop of the defect-to-fix loop: an inspection raises an issue (a fault), which becomes a work order, which is resolved by a repair. - Call `gearbelt_get_workspaces` first to get a workspace `_path`, then call this tool with it. - To find the work order or repair for an issue, read the row's `wo` (work-order number) and `repair` (repair id) columns. - An issue whose `wo` is empty has **no work order raised yet** — answer "open issues with no work order raised" from this tool alone (filter `statuses: ["open"]`, then keep rows whose `wo` is null); no gearbelt_get_work_orders call is needed for that. - Each row carries the raiser (`createdBy` name + `createdById`). For "who raised the most issues" count `createdById` over the rows (add `createdAt` for "this week"). ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `limit` (optional) — max rows this page (default 30, max 100). - `search` (optional) — free-text across title, description, number, asset, linked work-order/repair numbers. - `state` (optional) — record state; defaults to active. - `severities` (optional) — restrict to severity level(s). - `statuses` (optional) — restrict to issue status(es) (open, closed). - `assetIds` (optional) — restrict to issues on these asset(s), by asset UUID from gearbelt_get_assets (its `search` finds an asset by code, make, model, registration, or serial). - `createdDate` (optional) — ISO 8601 [from, to] range on issue creation. - `orderBy` / `orderDir` (optional) — sort field and direction. - `intent` / `conversationId` (optional) — always include for call tracing. Prefer filters over paging through everything — filtering server-side is cheaper and more accurate. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. `instructions` is a short list of guidance strings — read them. ## Fields returned - `id` (id) — string — issue id - `num` (number) — integer — sequential issue number - `title` (title) — string|null - `status` (status) — enum|null — "open" | "closed" - `sev` (severity) — enum|null — "critical" | "high" | "medium" | "low" - `source` (source) — string|null — inspection, service, manual - `asset` (asset) — string|null — linked asset internalId - `loc` (location) — string|null — location name - `days` (daysOpen) — integer — days open (frozen at close when closed) - `wo` (workOrder) — integer|null — linked work-order number - `repair` (repairId) — string|null — linked repair id - `closed` (closedAt) — string|null — ISO 8601 date-time - `by` (createdBy) — string|null — name of the user who raised the issue - `byId` (createdById) — string|null — stable id of that user (count/group by this for "who raised the most") - `created` (createdAt) — string — ISO 8601 date-time - `state` (state) — enum — "active" | "archived" | "deleted" ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor`. ## Example `{ "_path": "/ws_4oxc6SXZdYm", "statuses": ["open"], "severities": ["critical"] }`
gearbelt_get_issues
List repairs (work done to resolve issues) in a Gearbelt workspace. ## When to use - The final hop of the defect-to-fix loop: a repair records the work that closed one or more issues. This is the maintenance-completion record — distinct from gearbelt_get_work_orders, which is the job/request record. - Call `gearbelt_get_workspaces` first to get a workspace `_path`, then call this tool with it. - To find which issue a repair closed, call `gearbelt_get_issues` and filter by the repair — issues carry the repair id. - Aggregate questions over repair activity (repairs per asset, throughput, repair counts) are answerable from this tool alone — repair rows carry the asset internalId, technician, and repair date, so you don't need gearbelt_get_work_orders to compute them. Break these down by asset category via a gearbelt_get_assets join (internalId → category); repair rows carry no category. Mean-time-to-repair is a fault-to-fix duration, so it needs the issue's raised date from gearbelt_get_issues (or read that tool's daysOpen column directly), not just the repair date here. - Each row carries the technician (`repairedBy` name + `repairedById`). For "most productive mechanic / who logged the most repairs" count `repairedById` over the rows. ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `limit` (optional) — max rows this page (default 30, max 100). - `search` (optional) — free-text across repair number, asset, technician, form name, and form answers. - `assetIds` (optional) — restrict to repairs on these asset(s), by asset UUID from gearbelt_get_assets (its `search` finds an asset by code, make, model, registration, or serial). - `formName` (optional) — filter to repairs captured with this form/template name. - `repairDate` (optional) — ISO 8601 [from, to] range on the repair date. - `orderBy` / `orderDir` (optional) — sort field and direction. - `intent` / `conversationId` (optional) — always include for call tracing. Only active repairs are returned. Prefer filters over paging through everything. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. ## Fields returned - `id` (id) — string — repair id - `num` (number) — integer — sequential repair number - `date` (repairDate) — string — ISO 8601 date-time repair carried out - `asset` (asset) — string|null — linked asset internalId - `form` (form) — string|null — repair form/template name - `by` (repairedBy) — string|null — name of the user who logged the repair - `byId` (repairedById) — string|null — stable id of that user (count/group by this for per-user totals) - `created` (createdAt) — string — ISO 8601 date-time ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor`. ## Example `{ "_path": "/ws_4oxc6SXZdYm" }`
gearbelt_get_repairs
List schedule checks (recurring maintenance/compliance obligations per asset) in a Gearbelt workspace. ## When to use - The servicing / compliance loop: a schedule produces a check per asset (a "service due" obligation, e.g. a 500-hour service), whose derived status is overdue / due / ok. - Answer "what's due or overdue?" / "what servicing is coming up?" / "which assets are due (or overdue) for service?" / "when is the next service?" — read the `dueStatus` column (overdue/due/ok; `ok` = "on track" in the product's green/red wording) and sort by `dueProgress` desc to surface the most overdue first. - "Due for service" / "overdue for service" / "next service due" all map to this tool. Assets themselves carry **no** service-due date field, so don't look for one on gearbelt_get_assets — the `dueStatus` / `dueDate` on a schedule check is the source of truth for servicing. - For a workspace/grouped rollup (PM compliance rate, audit view), use `gearbelt_get_schedule_compliance` instead. - Each row carries the completer (`completedBy`/`completedById`) when the check is done. Count `completedById` for "who completed the most checks". ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `limit` (optional) — max rows this page (default 30, max 100). - `search` (optional) — free-text across check number, asset, and schedule name. - `assetIds` (optional) — restrict to checks on these asset(s), by asset UUID from gearbelt_get_assets (its `search` finds an asset by code, make, model, registration, or serial). - `checkStatus` (optional) — lifecycle status (open, closed). NOTE: this is NOT the derived overdue/due/ok status — that is the output-only `dueStatus` column. - `dueDate` (optional) — ISO 8601 [from, to] range on the due date. - `orderBy` / `orderDir` (optional) — sort field and direction (default dueProgress desc). - `intent` / `conversationId` (optional) — always include for call tracing. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. The `dueStatus` column is derived server-side (overdue/due/ok). ## Fields returned - `id` (id) — string — schedule check id - `num` (number) — integer|null — sequential check number - `status` (status) — enum — "open" | "closed" | "void" - `dueStatus` (dueStatus) — enum — "overdue" | "due" | "ok" (derived; ok = "on track") - `progress` (dueProgress) — number|null — percent toward due (>100 = overdue) - `due` (dueDate) — string|null — ISO 8601 date-time next due - `daysLeft` (daysRemaining) — integer|null — days until due (negative = overdue) - `asset` (asset) — string|null — linked asset internalId - `schedule` (schedule) — string|null — schedule name - `completed` (completedAt) — string|null — ISO 8601 date-time completed - `by` (completedBy) — string|null — name of the user who completed the check - `byId` (completedById) — string|null — stable id of that user (count/group by this for per-user totals) - `wo` (workOrder) — integer|null — linked work-order number ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor`. ## Example `{ "_path": "/ws_4oxc6SXZdYm", "checkStatus": ["open"], "orderBy": "dueProgress", "orderDir": "desc" }`
gearbelt_get_schedule_checks
Summarise schedule-check compliance across a Gearbelt workspace — counts by status and a compliance rate. ## When to use - Answer "how compliant are we?" / "what's our PM compliance?" / "what's our compliance rate?" / "how much servicing is overdue?" without paging through individual checks. - Backs the audit / reporting view of servicing compliance (service-due vs overdue across the fleet). - For the individual checks behind the numbers, use `gearbelt_get_schedule_checks`. ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `assetIds` (optional) — scope the rollup to specific asset(s), by asset UUID from gearbelt_get_assets (use its `search` to find an asset by code, make, model, registration, or serial). - `dueDate` (optional) — ISO 8601 [from, to] range on the due date. - `groupBy` (optional) — `none` (default, workspace total), `asset`, `schedule`, or `location`. - `intent` / `conversationId` (optional) — always include for call tracing. ## Response format Returns an object: `{ url, title, subtitle, total, ok, due, overdue, complianceRate, groupBy, groups, instructions }`. - `url` / `title` / `subtitle` — a citation for this rollup, linking to the workspace's schedule checks; used only for client citation rendering. - `total` — open checks in scope. `ok` / `due` / `overdue` — counts by derived status. - `complianceRate` — `ok / total` × 100 (one decimal); 0 when there are no open checks. - `groups` — per-`groupBy` breakdown (empty when `groupBy` is `none`); each has `groupKey`, `groupLabel`, and the same counts. - `instructions` — short guidance strings; read them. ## Example `{ "_path": "/ws_4oxc6SXZdYm", "groupBy": "location" }`
gearbelt_get_schedule_compliance
List the members (users) of a Gearbelt workspace — the workspace roster. ## When to use - Call `gearbelt_get_workspaces` first to get a workspace `_path`, then call this tool with it. - Resolve a person id to a name: a row's `id` matches the `...ById` columns on records (createdById, submittedById, repairedById, completedById). - For "who hasn't submitted / done X", get this roster and diff it against the users who did — e.g. the `submittedById` values from gearbelt_get_inspections. ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `search` (optional) — free-text across name, email, and username. - `userType` (optional) — "contributors" (default) | "sitemate-users" | "all". - `limit` (optional) — max rows this page (default 30, max 100). - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `intent` / `conversationId` (optional) — always include for call tracing. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. ## Fields returned - `id` (id) — string — user id (matches the ...ById columns on records) - `name` (name) — string|null — full name - `roles` (roles) — array of string — the user's workspace role(s) - `status` (status) — string — active | pending ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor`. ## Example `{ "_path": "/ws_4oxc6SXZdYm" }`
gearbelt_get_users
List work orders (maintenance and repair jobs) in a Gearbelt workspace. ## When to use - Call `gearbelt_get_workspaces` first to get a workspace `_path`, then call this tool with it. - Fetch one page at a time; only request the next page when the user asks for more. - The authoritative source for work-order detail on an issue: read an issue's `wo` column (via gearbelt_get_issues), then use this tool for the full work order. - Work-order **status is an output column, not a server-side filter** — there is no `status` param; fetch and read/group open vs closed on the returned rows. The available server-side filters are `priorities`, `assignedToCurrentUser`, and `assetIds`. - To scope to one asset, resolve its human code (e.g. `E-204`) to a UUID with gearbelt_get_assets `search`, then pass it as `assetIds` — there is no lookup by human-readable asset code. - Each row carries the raiser (`createdBy`/`createdById`) and its assignees (`assignees` names + `assigneeIds` stable ids, aligned). Count `createdById` or `assigneeIds` for "who raised / is assigned the most work orders". ## Parameters - `_path` (required) — workspace path, e.g. "/ws_4oxc6SXZdYm". - `pageCursor` (optional) — opaque cursor from a previous response's `nextPageCursor`. - `limit` (optional) — max rows this page (default 30, max 100). - `search` (optional) — free-text across title, number, PO. - `state` (optional) — filter by record state; defaults to active (pass archived/deleted to include those). - `priorities` (optional) — restrict to priority level(s). - `assignedToCurrentUser` (optional) — only work orders assigned to the caller. - `assetIds` (optional) — restrict to work orders on these asset(s), by asset UUID from gearbelt_get_assets (its `search` finds an asset by code, make, model, registration, or serial). - `orderBy` / `orderDir` (optional) — sort field and direction. - `intent` / `conversationId` (optional) — always include for call tracing. Prefer filters over paging through everything — filtering server-side is cheaper and more accurate. ## Response format (columnar, compact) Returns `{ fields, rows, nextPageCursor, instructions, results }`. `results` is a parallel array (one `{ url, title, subtitle }` per row) used only for client citation rendering — ignore it for data and read `rows`. `fields` lists the column short-names once; each entry in `rows` is a positional array aligned to `fields` — read `rows[i][k]` against `fields[k]`. Absent values are `null`. `instructions` is a short list of guidance strings (result count, pagination, next steps) — read them. ## Fields returned - `id` (id) — string — work order UUID - `num` (number) — integer — sequential work-order number - `title` (title) — string|null - `status` (status) — enum — "Open" | "Closed" - `prio` (priority) — enum|null — "critical" | "high" | "medium" | "low" - `due` (dueDate) — string|null — ISO 8601 date-time - `closed` (closedAt) — string|null — ISO 8601 date-time - `state` (state) — enum — "active" | "archived" | "deleted" - `asset` (asset) — string|null — linked asset internalId - `loc` (location) — string|null — location name - `by` (createdBy) — string|null — name of the user who raised the work order - `byId` (createdById) — string|null — stable id of that user (count/group by this for per-user totals) - `assignees` (assignees) — array of string — names of the users this work order is assigned to - `assigneeIds` (assigneeIds) — array of string — stable ids of the assignees, aligned to assignees - `created` (createdAt) — string — ISO 8601 date-time ## Pagination `nextPageCursor` is `null` on the last page; otherwise pass it back as `pageCursor` to fetch the next page. ## Example `{ "_path": "/ws_4oxc6SXZdYm" }`
gearbelt_get_work_orders
List the Gearbelt workspaces the caller can access. This is the entry point — call it first to obtain a workspace `_path` for the other Gearbelt tools. ## When to use - Call this before gearbelt_get_assets / gearbelt_get_work_orders / gearbelt_get_inspections, which all require a `_path`. - An empty result means the caller has no Gearbelt workspace access. ## Parameters - `intent` / `conversationId` (optional) — always include for call tracing; see the parameter hints. ## Fields returned Returns `{ workspaces, results, instructions }`. `results` is a parallel array (one `{ url, title, subtitle }` per workspace) used only for client citation rendering — ignore it for data and read `workspaces`. Each `workspaces` entry: - `_path` — string, pass verbatim as `_path` to the other Gearbelt tools. - `name` — string, workspace display name. - `workspaceId` — string, workspace flake id (ws_…). - `role` — the caller's role on this workspace.
gearbelt_get_workspaces
## Deprecated This tool still works and is fully supported. It has been renamed to `dashpivot_get_templates`. Prefer `dashpivot_get_templates` when it is available to you. Behaviour, parameters and responses are identical, so calls made here still return the same results. Retrieves app (template) definitions from Dashpivot with field-level metadata. ## Purpose Gateway to form data. Discover apps, review field definitions, select field IDs before calling dashpivot_get_forms. ## Prerequisites - For browse queries: call dashpivot_get_workspace_structure first to discover the hierarchy, then pass _path values. - For direct lookup: use `appIds` with any app identifier (FlakeID, ObjectId, or unique app ID). No _path needed — the server resolves it automatically. - If the user provides a Dashpivot URL, extract the ID from the URL path and pass it to `appIds`. ## Scoping Rules - **Preferred**: Use a project/team _path (e.g., "/ws_xxx/p_xxx") for targeted browse results. - **Broader**: Using a workspace _path ("/ws_xxx") may return many apps — only use for workspace-level apps or when a narrower _path is unavailable. - Combine _path with appName or templateTags to narrow results further. ## Parameters - appIds: Look up apps by any identifier — FlakeID (app_xxx), MongoDB ObjectId (24 hex chars), or unique app ID (e.g. TDW-C-JK6AQ). No _path needed. - _path: Required for browse queries, optional when appIds is provided. Use the narrowest paths available (e.g., ["/ws_xxx/p_xxx"]). - appName / templateTags: Filter apps - pageSize (default 25, max 25), pageCursor for pagination ## Key Behaviour - List/browse queries return app metadata with `fieldCount` only — look up specific apps by `appIds` to get full field definitions - Each app includes a `_path` field — use directly as `_path` in dashpivot_get_forms (e.g., ["/ws_xxx/p_xxx/app_xxx"]) - For workspace-wide queries, use `_path: ["/" + workspaceId]` (e.g., ["/ws_xxx"]) - Action templates are listed with `kind: 'action'`. For open, overdue or assigned actions, call dashpivot_get_actions instead of reading the action template's forms. - A `/ws_xxx/app_xxx` path returns both workspace-level apps and their team-level deployed copies together, only team-deployed copies have forms. To dashpivot_get_forms, pass in a team-level path `/ws_xxx/p_xxx/p_xxx/app_xxx` as `_path`. ## Field Selection for dashpivot_get_forms When calling dashpivot_get_forms, pass specific field IDs via the optional `fieldIds` parameter to control which fields are returned. Omitting fieldIds returns ALL fields including media (photo, signature, sketch) which contain large binary data. Select fields based on the task: - For text analysis: use singleLineInput, multiLineInput fields - For date filtering: use date fields - For status checks: use category, yesNoCheckbox fields - Avoid media fields (photo, signature, sketch, attachment) unless specifically needed — they contain large binary data ## Examples - Browse all apps in a project: `{ _path: ["/ws_xxx/p_xxx"] }` - Find safety templates: `{ _path: ["/ws_xxx/p_xxx"], templateTags: ["safety"] }` - Get field definitions for a specific app: `{ appIds: ["app_xxx"] }` <!-- mcp-router:region-aware-pagination --> **Pagination across regions:** The response includes `pageDetails.regions` keyed by region (e.g. `au1`, `uk1`). To get the next page, pass `pageCursor` as a JSON object (not a string) with an entry for each region where `isLastPage: false`. Example: `pageCursor: {"au1": "ws_abc", "uk1": "ws_xyz"}`. Omit `pageCursor` entirely for the first page. `pageSize` applies per-region — the response may include up to `pageSize × N` items where N is the number of regions with data.
get-apps
## Deprecated This tool still works and is fully supported. It has been renamed to `dashpivot_get_forms`. Prefer `dashpivot_get_forms` when it is available to you. Behaviour, parameters and responses are identical, so calls made here still return the same results. Retrieves form data (filled-in records) for summarization, analysis, and reporting. ## When to Use - If the user provides a specific _path, call dashpivot_get_forms directly — do NOT call dashpivot_get_workspace_structure or dashpivot_get_templates first. - If the user asks about forms without a path, follow the standard discovery workflow. - If dashpivot_get_forms returns 0 results, check the instructions field for diagnostic guidance before making follow-up calls. - Actions fields on returned forms are enriched inline with each linked action's status, assignee and due date. For open, overdue or assigned-to-me questions that do not start from a form, call dashpivot_get_actions instead. ## Required Parameter - **_path**: Array of FlakeID paths (max 100). Use `_path` values from dashpivot_get_templates or dashpivot_get_workspace_structure (e.g., ["/ws_xxx/p_xxx/app_xxx"] or ["/ws_xxx"]). ## Key Parameters - formName / fieldFilters: Filter forms - workflowStep: Filter by workflow column — accepts position numbers (1, 2) and/or column name strings ("Supervisor Approval"). Case-insensitive. - createdDate: Filter by creation date range (`{ after?, before? }` — ISO 8601 strings in **UTC**, e.g. `2026-01-01T00:00:00Z`). Use when the user is asking about when forms were *started* or *opened*. - updatedDate: Filter by last-updated date range (`{ after?, before? }` — ISO 8601 strings in **UTC**, e.g. `2026-01-01T00:00:00Z`). Use when the user is asking about when forms were *submitted*, *completed*, or *finalised* — `updatedAt` advances when a draft is filled in or saved, while `createdAt` is fixed at the moment the form was first opened. - fieldIds: Return only specific fields (use IDs from dashpivot_get_templates) - includeArchived: Defaults to false (active forms only) — leave this unset for ordinary questions like "how many forms are there". Only set true when the user explicitly asks about archived, historical, or "all" forms regardless of status; `totalFormCount` will then include archived forms too. - pageSize (default 10, max 10), pageCursor for pagination ## Choosing createdDate vs updatedDate A form can be drafted on day 1 and submitted on day 8. `createdAt` is fixed at draft time; `updatedAt` reflects the last save. Map customer phrasing to the right filter: - "submitted / completed / filled out / finalised in the last week" → `updatedDate` - "started / drafted / opened / created in the last week" → `createdDate` - Both filters can be combined; they compose with AND. - When the intent is ambiguous, prefer `updatedDate` and state the choice in your reply. - All date bounds are interpreted as **UTC**. Convert any relative or local-time phrasing ("today", "last week") to absolute UTC ISO 8601 strings before calling. ## Response Format (compact) Compressed JSON with ~63% fewer tokens. Field values are lossless. Forms are grouped by app. Structure: - `apps`: array of app groups, each containing: - `appPath`: shared app path for this group - `fields`: array of { name, kind } — field definitions declared once per app - `forms`: array of { id, name, num, workflowCol, created, by, state, values } — each form's `values` array is positionally mapped to `fields` - `results` (Copilot clients only): one { url, title } per form, for client citation rendering — read form data from `apps`, not here - Shortened keys: id=itemId, num=automatedFormNumber, workflowCol.pos=workflowColumn.position, workflowCol.name=workflowColumn.name, created=createdAt, by=createdBy.name - `state` (e.g., "active", "archived") is present per form when includeArchived is true, so you can tell which forms in a mixed result are archived - Pagination: pass `pageDetails.cursor` back as `pageCursor` to fetch the next page. `pageDetails.pageNumber` is informational only. Example response: ``` {"apps":[{"appPath":"/ws_xxx/p_xxx/app_xxx","fields":[{"name":"Inspector","kind":"singleLineInput"},{"name":"Status","kind":"category"}],"forms":[{"id":"form_xxx","name":"Inspection #1","num":"SI-001","workflowCol":{"pos":2,"name":"Supervisor Approval"},"created":"2026-03-20T10:00:00Z","by":"John","state":"active","values":["Michael",[{"name":"Pass","value":"pass"}]]}]}],"totalFormCount":42,"instructions":["Sending form 1 of 42.","More results available. Pass the cursor value as pageCursor to fetch the next page."],"pageDetails":{"cursor":"form_xxx","size":10,"isLastPage":false,"pageNumber":1}} ``` To read a value: `apps[i].forms[j].values[k]` corresponds to `apps[i].fields[k]`. Field IDs for fieldFilters/fieldIds are available from dashpivot_get_templates. ## Key Behaviour - Results are sorted newest first (most recent form at index 0) - Each field has { _id, name, kind, value } — value contains the extracted data - Returns up to 10 forms per response — use pageDetails.cursor for pagination when more results exist - More specific _path values return faster results - Field value structures vary by kind — see dashpivot_get_templates field definitions for type metadata ## Examples - Get all forms for an app: `{ _path: ["/ws_xxx/p_xxx/app_xxx"] }` - Forms from Q1 2026: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], createdDate: { after: "2026-01-01T00:00:00Z", before: "2026-04-01T00:00:00Z" } }` - Forms submitted in Q1 2026: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], updatedDate: { after: "2026-01-01T00:00:00Z", before: "2026-04-01T00:00:00Z" } }` - Return only text fields: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], fieldIds: ["fi_xxx", "fi_yyy"] }` - Forms in approval step: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], workflowStep: ["Supervisor Approval"] }` - Forms in columns 1 or 2: `{ _path: ["/ws_xxx/p_xxx/app_xxx"], workflowStep: [1, 2] }`
get-forms
## Deprecated This tool still works and is fully supported. It has been renamed to `dashpivot_get_lists`. Prefer `dashpivot_get_lists` when it is available to you. Behaviour, parameters and responses are identical, so calls made here still return the same results. Retrieves Dashpivot lists (spreadsheet-like data containers): columns, items, and property values. Lists power list fields and list property columns in forms — use this to understand what data populates form dropdowns and lookup fields. ## Modes (dispatched by leaf prefix of each _path) - **Browse** (leaf is ws_ or p_): returns list metadata plus `columns` (so the LLM can see what each list is shaped like and read `columns[].id` for follow-up `columnFilters`). `items` and `itemsPagination` are omitted. Use when discovering which lists exist under a workspace/project. - **Details** (leaf is li_): returns full data for the named list — columns, items, and property values. Use when a specific list has been identified to inspect. `columns` is always present on every list entry (empty array when the list has no columns). Browse and details paths can be mixed in one call — each entry resolves on its own leaf prefix. ## When to Use - If the user provides a specific _path, call dashpivot_get_lists directly — do NOT call dashpivot_get_workspace_structure first. - If the user asks about lists without a path, follow the standard discovery workflow: browse first, then narrow to a li_ path for details. - If dashpivot_get_lists returns 0 results, check the instructions field for diagnostic guidance. ## Required Parameter - **_path**: Array of FlakeID paths (max 100). Workspace/project paths (e.g., ["/ws_xxx"], ["/ws_xxx/p_xxx"]) trigger browse mode; list paths (e.g., ["/ws_xxx/li_xxx"]) trigger details mode. ## Key Parameters - listName: Filter by list name (case-insensitive partial match) — narrows which lists are returned in browse mode. - itemValue: Filter items by display value — the Item column shown in the list library (case-insensitive partial match). Only meaningful in details mode. - columnFilters: Filter items by column values. AND across entries, OR within each entry's queries. Each filter has a `columnId` (lp_ FlakeID — read from `columns[].id` in a prior details response), `queries` (array of one or more string/number values for OR matching within the entry), and an optional `match` mode controlling how each query compares to the cell value: `"contains"` (default — case-insensitive substring), `"exact"` (case-insensitive equality — use for IDs, codes, and precise numeric matches: `queries: ["1"]` with `match: "exact"` matches `"1"` only, NOT `"10"` or `"9991"`), or `"prefix"` (case-insensitive starts-with). To find rows where a column is empty / has no value, fetch the list without columnFilters and look for null in each item's positional properties array at the relevant column index. Only items matching ALL filter entries are returned. Only meaningful in details mode. - pageSize (default 25, max 25), pageCursor for list-level pagination. - itemPageSize (default 100, max 1000) — items per details list per page. Silently ignored for browse paths. - itemCursors — per-list item pagination cursors keyed by full list path (e.g. `{ "/ws_xxx/li_yyy": "lr_..." }`). Each value is an item FlakeID from a previous response's `itemsPagination.cursor`. Lists not in the map start at page 1; cursors for lists not in `_path` are silently ignored. ## Response Shape (compact) - `results` (Copilot clients only) is a { url, title } citation list for client rendering — read list data from `lists`, not here. - Browse entries emit `{ id, path, name, created, updated, columns }` — no `items`, no `itemsPagination`. - Details entries additionally emit `{ items, itemsPagination }`. Keys are shortened: `id`=itemId, `path`=full `_path`, `created`=createdAt, `updated`=updatedAt. - `columns` is always present (empty array when the list has no columns). - `columns` is declared once per list as `[{ id, name, model }]` where `id` is the lp_ FlakeID (use it for `columnFilters[].columnId`) and `model` is one of: `text-simple`, `number-simple`, `date-simple`, `date-expiry`, `attachment-simple`. Use `model` to interpret each column's values. - `items` is an array of `{ id, value, properties }`. `properties` is a positional array — `properties[i]` corresponds to `columns[i]`. Length always equals `columns.length`; missing/unsupported properties are `null`. - `itemsPagination` is `{ cursor?, isLastPage }`. To fetch more items for a list, pass back the cursor via top-level `itemCursors` keyed by the list's `path`. ## Key Behaviour - Browse mode returns metadata only; details mode returns columns, items, and per-list `itemsPagination`. - Only active lists and items are returned. - Details entries are always returned even when filters yield no items on the current page — advance via `itemsPagination.cursor` to look further. Browse entries don't carry `itemsPagination`. - When `columnFilters` is set, pages reliably fill up to `itemPageSize` matched items; `itemsPagination.isLastPage` is true exactly when no further matches exist. - `columnFilters[].columnId` must be a valid lp_ FlakeID read from `columns[].id` on a prior details response — names are not accepted. Filters whose `columnId` is not on the list contribute no matches. - Lists exist at workspace or project level (never teams). Workspace-level lists can be deployed into projects. ## Examples - Discover lists in a workspace (browse): `{ _path: ["/ws_xxx"] }` - Inspect a specific list (details): `{ _path: ["/ws_xxx/li_xxx"] }` - Browse then narrow: first call with the workspace path to see what lists exist, then call again with the chosen list's li_ path to fetch its data. - Find lists by name: `{ _path: ["/ws_xxx"], listName: "Materials" }` - Search items by display value: `{ _path: ["/ws_xxx/li_xxx"], itemValue: "Concrete" }` - Filter items by column value: `{ _path: ["/ws_xxx/li_xxx"], columnFilters: [{ "columnId": "lp_xxx", "queries": ["Active"] }] }` - OR within a column: `{ _path: ["/ws_xxx/li_xxx"], columnFilters: [{ "columnId": "lp_xxx", "queries": ["Active", "Pending"] }] }` - Multiple column filters (AND): `{ _path: ["/ws_xxx/li_xxx"], columnFilters: [{ "columnId": "lp_type", "queries": ["Steel"] }, { "columnId": "lp_grade", "queries": ["A"] }] }` - Advance one list's items: `{ _path: ["/ws_xxx/li_a", "/ws_xxx/li_b"], itemCursors: { "/ws_xxx/li_a": "lr_..." } }` — only `li_a` advances; `li_b` returns item page 1.
get-lists
## Deprecated This tool still works and is fully supported. It has been renamed to `dashpivot_get_users`. Prefer `dashpivot_get_users` when it is available to you. Behaviour, parameters and responses are identical, so calls made here still return the same results. Retrieves user information within a workspace's folder hierarchy. ## Modes - **users-in-folder**: List the users in a specific folder. - **folders-for-user**: Given a person's name or email, list which folders they can access within the queried workspace(s). ## PII Protection Every user in the response has `lastName` reduced to its initial (e.g. "S") and `email` masked (e.g. "j***@example.com"). `firstName`, `sitemateUserId`, and `_id` are unmasked. Do not reconstruct or guess full names/emails from the masked values — ask the human if you need the original. ## When to Use - "Who has access to this project?" → mode "users-in-folder" - "Which folders can <person> access?" / "What is <person>'s access in this workspace?" → mode "folders-for-user" ## Required Parameters - **_path**: Array of 1-100 FlakeID paths from dashpivot_get_workspace_structure. Each must be workspace-rooted (e.g. "/ws_xxx" or "/ws_xxx/p_xxx"). Paths may span multiple workspaces. - **mode**: "users-in-folder" or "folders-for-user" ## Mode-Specific Parameters - **users-in-folder**: pageSize, pageCursor. Pass multiple paths to union users across folders — a user who appears in any queried folder is returned once. Lists users granted on the queried folder OR a sub-folder beneath it; access inherited from a PARENT is not reflected (query the parent folder to see its controllers). - **folders-for-user**: provide `name` or `email` (exact match, takes precedence over name). `name` uses case-insensitive **exact** equality, not substring/partial — "John" matches users whose firstName OR lastName is exactly "John"; "John Smith" matches firstName "John" AND lastName "Smith". Returns one of: a single **user-match** with their accessible folders (inheritance-aware — a workspace controller is listed for a queried child folder); a **disambiguation** signal carrying NO user data when multiple users share the name (ask the human for the exact email, then re-call with `email`); or **no-match**. ## Notes - users-in-folder membership is a superset of folders-for-user reachability. users-in-folder lists a user straight from the permission service regardless of whether the granting folder is still active, so it can include grants on archived/deleted sub-folders that folders-for-user (which resolves to active folders only) will not return. ## Examples - Users in a project: `{ _path: ["/ws_xxx/p_xxx"], mode: "users-in-folder" }` - Users across multiple projects: `{ _path: ["/ws_xxx/p_a", "/ws_xxx/p_b"], mode: "users-in-folder" }` - Users across workspaces: `{ _path: ["/ws_A", "/ws_B"], mode: "users-in-folder" }` - Folders a user can access: `{ _path: ["/ws_xxx"], mode: "folders-for-user", name: "John Smith" }` - Disambiguate by exact email: `{ _path: ["/ws_xxx"], mode: "folders-for-user", email: "john.smith@example.com" }`
get-users
## Deprecated This tool still works and is fully supported. It has been renamed to `dashpivot_get_workspace_structure`. Prefer `dashpivot_get_workspace_structure` when it is available to you. Behaviour, parameters and responses are identical, so calls made here still return the same results. Browse the Sitemate workspace hierarchy by drilling from workspaces → projects → teams. Returns a level-discriminated page — one of `workspaces[]`, `projects[]`, or `teams[]` per call, never the full tree. Use `_path` values from one response as input to the next. ## When to Call First tool in any workflow. Walk the 3-call pattern below to resolve a workspace name to a project or team `_path`, then pass that `_path` to tools like `dashpivot_get_templates`. ## Parameters - `_path` (string[]): omit to list workspaces; `["/ws_xxx"]` to list projects in a workspace; `["/ws_xxx/p_yyy"]` to list teams in a project. - `nameFilter` (string): case-insensitive partial match on the entity name at the current `_path` level. Use short, distinctive substrings (`"Acme"`, not `"Acme Construction Pty. Ltd."`). - `state`: `"active"` (default), `"archived"`, or `"deleted"`. Workspaces don't support `"deleted"`. - `pageSize`: default 50, max 50. - `pageCursor`: pass `pageDetails.cursor` from the previous response. ## Response Always carries `level` + `instructions[]`. Switch on `level` before accessing arrays: - `level: "workspace"` → `workspaces[]` (`itemId`, `_path`, `name`, `projectCount`, `totalTeamCount`) - `level: "project"` → `projects[]` (`itemId`, `_path`, `name`, `teamCount`) - `level: "team"` → `teams[]` (`itemId`, `_path`, `name`) Empty pages omit the array entirely; check `pageDetails.isLastPage` before paginating. ## Worked example (browse → drill → drill) 1. `dashpivot_get_workspace_structure({})` → `level: "workspace"`, e.g. `_path: "/ws_acme"` 2. `dashpivot_get_workspace_structure({ _path: ["/ws_acme"] })` → `level: "project"`, e.g. `_path: "/ws_acme/p_highway"` 3. `dashpivot_get_workspace_structure({ _path: ["/ws_acme/p_highway"] })` → `level: "team"`, e.g. `_path: "/ws_acme/p_highway/p_safety"` Pass the final `_path` to `dashpivot_get_templates` to fetch apps at that scope. ## Cursor-error recovery Cursors are scope-bound to the level that issued them. Reusing a cursor across scopes returns a `BadRequestError` with a `cursorValidationFailureMode` discriminator (`workspace-cursor-on-drill-down`, `drill-down-cursor-on-workspace`, or `unrecognised-prefix`). Recovery: drop the cursor and retry without it. Don't try to translate cursors across scopes. <!-- mcp-router:region-aware-pagination --> **Pagination across regions:** The response includes `pageDetails.regions` keyed by region (e.g. `au1`, `uk1`). To get the next page, pass `pageCursor` as a JSON object (not a string) with an entry for each region where `isLastPage: false`. Example: `pageCursor: {"au1": "ws_abc", "uk1": "ws_xyz"}`. Omit `pageCursor` entirely for the first page. `pageSize` applies per-region — the response may include up to `pageSize × N` items where N is the number of regions with data.
get-workspace-structure
Signals a missing or unclear capability in the Sitemate toolset. ## Behavior Read-only. This tool creates, updates, and deletes nothing in Sitemate and reads no user data. It returns a fixed acknowledgement, never blocks, and never counts as a failure. ## When To Call - You cannot answer the user's Sitemate-related requests with the listed tools at all. - You can answer it, but only by chaining multiple Sitemate discovery tools together. That friction is the signal. - The user uses a Sitemate domain noun that isn't a parameter or tool name in the schema (e.g., "incidents", "RFIs", "defects"). - Do NOT call for non-Sitemate requests (web search, weather, Slack messages). ## How To Call - Call early and often in parallel with your other tool calls. - It is free to call, does not block, and does NOT count as a failure. - Once per stuck moment is enough — don't repeat the same suggestion in a conversation. - Do not treat it as an alternative to answering; it only signals the gap. ## Parameters - **intent** (recommended): Plain-language description of what the user actually asked for. Be concrete — "show forms past their due date" beats "find late stuff". - **suggestedToolName** (required): Your guess at what the tool would be called, in snake_case (e.g. "dashpivot_get_forms"). - **attemptedTools** (optional): Array of tool names you already tried / used as a workaround (e.g., ["dashpivot_get_workspace_structure", "dashpivot_get_templates", "dashpivot_get_forms"]). Non-empty = friction report; empty = no workaround attempted. - **conversationId** (recommended): Same UUID across all tool calls answering the user's question, so calls can be correlated. ## Response Format Returns a fixed acknowledgement — there is no payload to act on: ``` { "logged": true, "message": "Feedback logged." } ``` The response is informational only; it confirms the signal was received and exposes no Sitemate data. ## Examples - Domain noun + chained Sitemate discovery: `{ "intent": "show me the top 10 RFIs across my workspace", "suggestedToolName": "dashpivot_get_rfis", "attemptedTools": ["dashpivot_get_workspace_structure", "dashpivot_get_templates", "dashpivot_get_forms"], "conversationId": "abc-123" }` - Sitemate filter not exposed: `{ "intent": "find all overdue forms in the middle of a safety audit", "suggestedToolName": "dashpivot_get_overdue_forms", "attemptedTools": ["dashpivot_get_forms"], "conversationId": "abc-123" }` - True gap in Sitemate toolset: `{ "intent": "create a new Sitemate template from scratch", "suggestedToolName": "dashpivot_create_template", "conversationId": "abc-123" }`
sitemate_suggest
## Deprecated This tool still works and is fully supported. It has been renamed to `sitemate_suggest`. Prefer `sitemate_suggest` when it is available to you. Behaviour, parameters and responses are identical, so calls made here still return the same results. Signals a missing or unclear capability in the Sitemate toolset. ## Behavior Read-only. This tool creates, updates, and deletes nothing in Sitemate and reads no user data. It returns a fixed acknowledgement, never blocks, and never counts as a failure. ## When To Call - You cannot answer the user's Sitemate-related requests with the listed tools at all. - You can answer it, but only by chaining multiple Sitemate discovery tools together. That friction is the signal. - The user uses a Sitemate domain noun that isn't a parameter or tool name in the schema (e.g., "incidents", "RFIs", "defects"). - Do NOT call for non-Sitemate requests (web search, weather, Slack messages). ## How To Call - Call early and often in parallel with your other tool calls. - It is free to call, does not block, and does NOT count as a failure. - Once per stuck moment is enough — don't repeat the same suggestion in a conversation. - Do not treat it as an alternative to answering; it only signals the gap. ## Parameters - **intent** (recommended): Plain-language description of what the user actually asked for. Be concrete — "show forms past their due date" beats "find late stuff". - **suggestedToolName** (required): Your guess at what the tool would be called, in snake_case (e.g. "dashpivot_get_forms"). - **attemptedTools** (optional): Array of tool names you already tried / used as a workaround (e.g., ["dashpivot_get_workspace_structure", "dashpivot_get_templates", "dashpivot_get_forms"]). Non-empty = friction report; empty = no workaround attempted. - **conversationId** (recommended): Same UUID across all tool calls answering the user's question, so calls can be correlated. ## Response Format Returns a fixed acknowledgement — there is no payload to act on: ``` { "logged": true, "message": "Feedback logged." } ``` The response is informational only; it confirms the signal was received and exposes no Sitemate data. ## Examples - Domain noun + chained Sitemate discovery: `{ "intent": "show me the top 10 RFIs across my workspace", "suggestedToolName": "dashpivot_get_rfis", "attemptedTools": ["dashpivot_get_workspace_structure", "dashpivot_get_templates", "dashpivot_get_forms"], "conversationId": "abc-123" }` - Sitemate filter not exposed: `{ "intent": "find all overdue forms in the middle of a safety audit", "suggestedToolName": "dashpivot_get_overdue_forms", "attemptedTools": ["dashpivot_get_forms"], "conversationId": "abc-123" }` - True gap in Sitemate toolset: `{ "intent": "create a new Sitemate template from scratch", "suggestedToolName": "dashpivot_create_template", "conversationId": "abc-123" }`
suggest
Recommended guideHow to get your ChatGPT Plugin suggestedFollow the practical steps agents use to find, shortlist, and choose your Plugin.Read guideSitemate ChatGPT Plugin FAQ
How the directory, categories and Discoverability Score work.
Read the methodologyHow do I improve Sitemate's ChatGPT Plugin discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Sitemate alternatives on ChatGPT?
As of 2026-11-02, Sitemate competes with 3montovano CRM, A4B CMMS, AI Dispatcher by FieldCamp, BlueSuite, Bobibo, BoltWright, Cabinet Project, CheckpointGuard and 40 more in ChatGPT Field Service Management Software, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.