Local MCP

Run Diagnostics

run_diagnostics

Read-only

Runs a fast health check of LMCP on this machine: the Apple apps, macOS permissions and local integrations listed under focus, and the AI apps connected to LMCP (configured, never used, broken command, blocked config). Shows what works, what doesn't, and how to fix it. It does not check WhatsApp, Teams, Slack, Telegram or a connected Microsoft 365 account. For those: whatsapp_diagnose (WhatsApp), list_m365_accounts (Microsoft 365 and Teams sign-in), slack_list_workspaces (Slack), telegram_list_accounts (Telegram); lmcp_state reports all of them at once. It only reads; nothing is sent. To share the result with the LMCP team, use submit_diagnostics.

Input Schema

Name	Required	Description	Default
`focus`	No	Integration to focus on: calendar, mail, contacts, reminders, omnifocus, outlook, notes, finder, onedrive, screen_recording, accessibility — or `clients` for the AI apps connected to LMCP (or one app id, e.g. cursor). Leave empty to check all.

Output Schema

Name	Required	Description
`report`	No	Full formatted text report
`summary`	Yes	Plain-language summary of overall health
`ok_count`	Yes	Number of integrations working
`submitted`	No	Always false here: this tool sends nothing. submit_diagnostics is the one that sends
`warn_count`	Yes	Number of integrations with warnings (an app that is not open is not_running_count)
`web_agents`	No	Web (cloud-relay) clients, counts only: count (absent when unknown), relayed_calls_since_launch, last_remote_call
`integrations`	Yes
`problem_count`	Yes	Number of integrations with errors or missing permissions

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 22, 2026

removedInput schema / properties / submit

Removed value: -{
-  "description": "Send the diagnostic report to the LMCP team for analysis (default: false)",
-  "type": "boolean"
-}

changedOutput schema / properties / submitted / description

Previous value: -"True when the report was sent to the LMCP team"New value: +"Always false here: this tool sends nothing. submit_diagnostics is the one that sends"

changedOutput schema / properties / warn_count / description

Previous value: -"Number of integrations with warnings / not running"New value: +"Number of integrations with warnings (an app that is not open is not_running_count)"

Changed1 schema field changedSep 30, 2026

addedOutput schema / properties / web_agents

Added value: +{
+  "description": "Web (cloud-relay) clients, counts only: count (absent when unknown), relayed_calls_since_launch, last_remote_call",
+  "type": "object"
+}

Changed1 schema field changedSep 29, 2026

removedOutput schema / properties / web_agents

Removed value: -{
-  "description": "Web (cloud-relay) clients, counts only: count (absent when unknown), relayed_calls_since_launch, last_remote_call",
-  "type": "object"
-}

Changed1 schema field changedSep 26, 2026

addedOutput schema / properties / web_agents

Added value: +{
+  "description": "Web (cloud-relay) clients, counts only: count (absent when unknown), relayed_calls_since_launch, last_remote_call",
+  "type": "object"
+}

Changed1 schema field changedSep 11, 2026

changedInput schema / properties / focus / description

Previous value: -"Integration to focus on: calendar, mail, contacts, reminders, omnifocus, outlook, notes, finder, onedrive, screen_recording, accessibility. Leave empty to check all."New value: +"Integration to focus on: calendar, mail, contacts, reminders, omnifocus, outlook, notes, finder, onedrive, screen_recording, accessibility — or `clients` for the AI apps connected to LMCP (or one app id, e.g. cursor). Leave empty to check all."

Changed1 schema field changedAug 17, 2026

changedInput schema / properties / focus / description

Previous value: -"Integration to focus on: calendar, mail, contacts, reminders, omnifocus, outlook, notes, finder, onedrive. Leave empty to check all."New value: +"Integration to focus on: calendar, mail, contacts, reminders, omnifocus, outlook, notes, finder, onedrive, screen_recording, accessibility. Leave empty to check all."

First observedJun 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'It only reads; nothing is sent,' which matters for a diagnostic that inspects permissions and configs. It also discloses what the output reports ('what works, what doesn't, and how to fix it') and the `focus` scoping behavior, though it says nothing about runtime or limits for an openWorldHint tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then the exclusion/routing list, then the read-only guarantee and the submit_diagnostics handoff. The dense service-routing sentence earns its length by preventing wrong-tool calls, though it is one heavy clause-stacked run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, coverage boundaries, alternatives, side-effect safety, and how to escalate results. An output schema exists so return values need not be spelled out, and the description still summarizes the shape of the response. Nothing an agent needs to select and invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the `focus` enum is fully enumerated in the schema, so the description need not restate it. It does add a little framing by tying `focus` to the integrations 'listed under focus' and noting the `clients` option, but no syntax or default behavior beyond 'Leave empty to check all' that the schema already implies. Baseline 3 applies.

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

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Runs a fast health check of LMCP on this machine') and enumerates exactly what is covered: Apple apps, macOS permissions, local integrations, and connected AI clients. It distinguishes itself from nearby tools by naming the services it excludes and the siblings that handle them.

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

Usage Guidelines5/5

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

Explicit routing: it names the services it does NOT check and pairs each with the correct alternative (whatsapp_diagnose, list_m365_accounts, slack_list_workspaces, telegram_list_accounts), plus lmcp_state for an all-in-one view. It also reserves submit_diagnostics for the separate act of sharing results, leaving no ambiguity about when to call this tool.

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

All Local MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.