Skip to main content
Glama

LMCP State

lmcp_state
Read-only

Returns a structured snapshot of the LMCP environment: server/tray/teams-proxy versions, detected AI client, cloud relay state, TCC permission states (Calendar/Reminders/Contacts), and a compact summary of which services (Mail/Calendar/Contacts/Teams/OneDrive/Reminders/Notes) are reachable. Fast (<500ms), passive — never prompts the user, never opens app windows, never touches the network. Call this when you need to verify the environment is healthy before attempting a tool, or to understand what's installed and accessible. If services.scan_pending is true, the background service scan hasn't finished yet (just after startup) and the per-service running/accounts values are placeholders — do NOT treat them as a real outage; just call the tool you need. Otherwise services.scanned_seconds_ago tells you how many seconds ago that scan ran (cadence ~60s): the per-service values are a snapshot, NOT a live probe. A false/0/not available for a service is advisory only — it can be stale (e.g. the user connected WhatsApp or opened Mail seconds ago) — so never use this tool as a preflight gate to skip or cancel a task; the actual tool call is the source of truth, just attempt it. For reporting failures, use report_problem instead — it captures this same snapshot plus logs and submits to the team.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tccNoTCC permission states, e.g. granted | denied | authorized.
archNo
updateNo
versionNoServing (running) server version.
built_atNoUTC build timestamp (F-041). 'unknown' if unstamped.
servicesNoPer-domain reachability summary (mail, calendar, contacts, teams, onedrive, slack, …); shape varies by domain. May include `scan_pending: true` right after startup, meaning the per-service running/accounts values are placeholders and not yet authoritative. Once scanned, `scanned_seconds_ago` gives the age (seconds) of that background snapshot and `freshness` restates that a false/0/not-available is advisory, not a live check — never gate a task on it.
ai_clientNo
build_shaNoGit short SHA of the build (F-041). 'unknown' if unstamped.
machine_idNo
os_versionNo
tray_versionNo
last_activityNo
skill_captureNoDark-launch counters for repeated-workflow detection (user-generated skills, PR-1). would_fire_signatures = how many times a save-this-workflow nudge WOULD have fired; ring_size = entries in the recent-calls ring. PRIVACY: the ring is IN-MEMORY ONLY — never written to disk, never transmitted, cleared on restart — and argument values are PII-scrubbed on entry, so it holds the SHAPE of a workflow, not its content. No UI acts on it yet; it exists to tune thresholds. Opt out with the skill_capture_enabled config flag.
license_statusNotrial | active | expired
cloud_token_setNo
tunnel_connectedNo
cloud_data_enabledNo

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark readOnlyHint=true, destructiveHint=false, openWorldHint=false. The description adds crucial behavioral details: 'Fast (<500ms), passive — never prompts the user, never opens app windows, never touches the network.' It also explains the scan_pending placeholder logic and the staleness/advisory nature of service values, which goes far beyond annotation hints. No contradiction.

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

Conciseness5/5

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

The description is longer than typical, but every sentence adds operational significance. It is front-loaded with the main purpose and behavioral guarantees, then progressively covers caveats and alternatives. The length is justified to prevent misuse (e.g., treating snapshot as live, relying on stale values).

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?

The description fully covers a zero-input environment probe. It explains the semantics of the response fields (`scan_pending`, `scanned_seconds_ago`), warns about staleness, and provides a sibling pointer to `report_problem`. Given an output schema exists and no inputs are required, this is complete.

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

Parameters4/5

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

The tool has zero parameters, so schema coverage is 100% by definition. The description appropriately omits parameter details and instead clarifies the meaning of output fields like `services.scan_pending`, which is more valuable here. The baseline for 0 params is 4.

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?

The description opens with a specific verb and resource: 'Returns a structured snapshot of the LMCP environment' and enumerates the exact contents (versions, AI client, cloud relay state, TCC permissions, service reachability). It clearly distinguishes itself from diagnostic/reporting siblings by noting 'For reporting failures, use report_problem instead.'

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?

Explicitly states when to use: 'Call this when you need to verify the environment is healthy before attempting a tool, or to understand what's installed and accessible.' It also gives clear exclusions: 'never use this tool as a preflight gate to skip or cancel a task' and points to report_problem for failures.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

Many tools are clearly distinct per app (e.g., chrome_*, safari_*, m365_*), but there is notable overlap between generic file tools like `file_list` and `finder_list`, both listing files; `search_contacts` and `list_contacts` serve similar purposes; `report_friction` and `report_problem` both send feedback to the team. The large number of tools with similar purposes in different domains creates moderate ambiguity for an agent.

Naming Consistency4/5

The naming convention is very consistent overall: most tools follow a `{app}_action` or `verb_noun` pattern (e.g., `chrome_click`, `create_calendar_event`, `list_reminders`). There are minor deviations like `lmcp_install_upgrade` (two verbs) and `complete_omnifocus_task` vs. `complete_reminder` (inconsistent verb placement). Still, the pattern is predictable and readable across the full set.

Tool Count2/5

With 225 tools, the surface is extremely large and heavy. While it covers many distinct domains (browsers, mail, calendar, files, notes, reminders, video editing, web automation, etc.), the sheer number makes it hard to navigate and likely includes many rarely-used tools. This is far beyond the well-scoped range of 3-15 tools and feels excessive even for a 'local everything' MCP server.

Completeness3/5

For many app integrations, the tool set provides solid CRUD coverage (e.g., Calendar has create, read, update, delete; Apple Notes has create, read, update, list, search; OmniFocus has create, list, search, complete). However, some areas are incomplete: for example, there is no tool to create a new Mail folder or delete notes. The 'web' tools lack a clear update/delete for saved sessions. The suite is broad but has notable gaps within individual domains.