Mitti MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MITTI_API_TOKEN | No | Your Mitti API token (primary authentication method). Generate from Mitti → Account Settings → API Tokens. | |
| SAFETYCULTURE_BASE_URL | No | Optional legacy SafetyCulture base URL. Defaults to the Mitti API endpoint unless provided. | |
| SAFETYCULTURE_API_TOKEN | No | Legacy SafetyCulture API token, accepted as a fallback for MITTI_API_TOKEN. | |
| MITTI_MCP_RATE_LIMIT_RPS | No | Optional rate limit override in requests per second. Default is 10 req/s. | 10 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| request_approvalA | Request human approval before proceeding with an action. Call this tool proactively whenever you are about to take a significant or irreversible action and want the user to confirm first. Do NOT wait for the user to ask you to seek approval — use your judgment about when confirmation is appropriate. The user will see an approval card with the summary, optional details, and Approve/Reject buttons. When they click a button, their decision appears as a message in the conversation (as if the user typed it), like: or: IMPORTANT: After calling this tool, you MUST stop and wait for the user's response. Do not continue, do not take any other actions, do not generate further output until you see the "I selected:" message. If approved, continue with the action. If rejected, acknowledge and ask how to proceed. |
| inspections_list_inspectionsA | List inspections from the Mitti (formerly SafetyCulture) account. Supports filtering by modification date and limiting the number of results. Returns only audit_id, template_id, and modification date per inspection — the search API does not return name, owner, score, or status. Call get_inspection with a specific audit_id for full details. |
| inspections_list_inspections_viewA | Show inspections from the Mitti account as an interactive, sortable, searchable table rendered directly in the conversation. Use this instead of list_inspections when the user wants to browse inspections visually. Only shows audit_id, template_id, and modification date — the same limitation as list_inspections. |
| inspections_get_inspectionA | Get full details of a single Mitti inspection by its audit ID. Returns name, template, owner, dates, score, and status. |
| inspections_complete_inspectionA | Mark a Mitti inspection as complete. This is a write operation — the inspection must be in 'in_progress' status. Call request_approval first and wait for the user's decision before calling this tool. Returns success or an error message. |
| inspections_get_inspection_web_report_linkA | Get a shareable web report link for a Mitti inspection. Returns a permanent URL that can be shared with others to view the inspection report. |
| templates_list_templatesA | List templates available in the Mitti (formerly SafetyCulture) account. Returns template ID, name, and dates only — description, owner, and archived status require get_template. Use the returned template_id to get the full template definition. |
| templates_get_templateA | Get summary metadata for a specific Mitti template by its ID. Returns name, description, owner, archived status, and dates. |
| templates_get_template_definitionC | Get the full definition of a Mitti template including all questions, sections, and scoring rules. Returns a structured summary of the template definition. |
| actions_list_actionsA | List actions from the Mitti (formerly SafetyCulture) account. Supports server-side filtering by status (open, in_progress, completed, cant_do) and by an org-specific priority_id (UUID). Returns action ID, title, description, status, priority_id, due date, and assignees. |
| actions_get_actionA | Get full details of a specific Mitti action by its ID. Returns title, description, status, priority_id, due date, assignees, and site. |
| actions_create_actionA | Create a new action in Mitti. Requires at minimum a title. Optionally set description, due date (ISO 8601), assignee user IDs, and site ID. priority_id is an org-specific UUID — omit it for the system default priority. Call request_approval first and wait for the user's decision before calling this tool. Returns the created action's ID. |
| actions_update_action_statusA | Update the status of a Mitti action. Valid statuses are: 'open', 'in_progress', 'completed', 'cant_do'. Call request_approval first and wait for the user's decision before calling this tool. Returns success or an error message. |
| actions_update_action_titleA | Update the title of a Mitti action. Call request_approval first and wait for the user's decision before calling this tool. Returns success or an error message. |
| users_list_usersA | List users in the Mitti (formerly SafetyCulture) organization. Returns user ID, first name, last name, email, status ('active' or 'inactive' — there is no 'pending' status), and a best-effort role indicator. Useful for finding user IDs to assign to actions. |
| users_get_current_userA | Get the profile of the currently authenticated Mitti user. NOTE: Mitti's current API has no dedicated 'current user' endpoint — this always returns failure with guidance to use search_users with a known email instead. |
| users_search_usersA | Search for Mitti users by name or email substring. NOTE: the underlying API only supports exact-match filters, so this fetches all users and filters client-side — it is not efficient for very large organizations. Returns matching users with their IDs, names, emails, and statuses. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Prefab Renderer (list_inspections_view) | |
| Prefab Renderer (request_approval) | |
| Prefab Renderer (list_inspections_view) |
TDQS
Scored across 17 tools
Most tools are clearly separated by resource (templates, inspections, actions, users) and action (list, get, create, update). The main ambiguity is between inspections_list_inspections and inspections_list_inspections_view, which return the same data but differ only in presentation format, and templates_get_template_definition vs templates_get_template could confuse agents looking for template details.
Tool names follow a consistent resource_action pattern (e.g., inspections_list_inspections, actions_get_action, users_search_users). Minor deviations include request_approval lacking a resource prefix and templates_get_template_definition being more verbose than the pattern, but overall the convention is predictable.
17 tools is slightly above the ideal range but reasonable for a server covering four distinct resource domains (templates, inspections, actions, users) plus an approval utility. Each tool serves a clear purpose, though a few could be consolidated (e.g., list_inspections vs list_inspections_view).
The server covers the main workflows: listing and retrieving templates, inspections, actions, and users, plus creating actions and updating action status/title. Gaps include no create/update for templates or inspections, no delete operations, and no way to update inspection details, but the core read and action-management workflows are covered.