Skip to main content
Glama
Harsh-Mer623

Mitti MCP Server

by Harsh-Mer623

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MITTI_API_TOKENNoYour Mitti API token (primary authentication method). Generate from Mitti → Account Settings → API Tokens.
SAFETYCULTURE_BASE_URLNoOptional legacy SafetyCulture base URL. Defaults to the Mitti API endpoint unless provided.
SAFETYCULTURE_API_TOKENNoLegacy SafetyCulture API token, accepted as a fallback for MITTI_API_TOKEN.
MITTI_MCP_RATE_LIMIT_RPSNoOptional 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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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:

"Deploy v3.2 to production" — I selected: Approve

or:

"Deploy v3.2 to production" — I selected: Reject

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
Prefab Renderer (list_inspections_view)
Prefab Renderer (request_approval)
Prefab Renderer (list_inspections_view)

TDQS

A3.8/5.0

Scored across 17 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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).

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues