Local MCP

Report Problem

report_problem

Destructive

Sends a problem report, feature request, or integration request to the LMCP team — for when a user wants to report a bug, ask for a new capability, or request support for an app LMCP doesn't cover yet. Without confirm=true it returns a preview of the anonymous payload that would be sent (version, OS, permission status, and recent tool names / error-type codes — never arguments, messages or personal data); with confirm=true it submits and returns a case_id. type='problem' (default) reports a bug, type='feature' requests a new capability, type='integration' requests an unsupported app.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "report_problem"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	Must be true to submit the report. Without it, shows a preview.
`symptom`	No	Required for type=problem: what is broken, in your own words.
`expected`	No	What you or the user expected to happen.
`remember`	No	With confirm: true, also stop asking for this kind of action from now on. Only when the person said so ("don't ask again"). The person can revoke it in LMCP or with set_always_allowed.
`description`	No	Required for type=feature or integration: what the user wants.
`report_type`	No	'problem' (default) \| 'feature' \| 'integration'
`user_request`	No	What the user originally asked the AI to do.
`error_message`	No	For type=problem: verbatim error string from the failed tool.
`tool_attempted`	No	For type=problem: name of the LMCP tool that failed.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

removedInput schema / properties / email

Removed value: -{
-  "description": "Optional: an email the team can reply to. If you add your email, we link it to this installation's diagnostic data (version, setup progress, errors and tool usage) so we can follow up on this report and tell you when it's fixed. See local-mcp.com/privacy.",
-  "type": "string"
-}

Changed2 schema fields changedOct 24, 2026

addedInput schema / properties / email

Added value: +{
+  "description": "Optional: an email the team can reply to. If you add your email, we link it to this installation's diagnostic data (version, setup progress, errors and tool usage) so we can follow up on this report and tell you when it's fixed. See local-mcp.com/privacy.",
+  "type": "string"
+}

addedInput schema / properties / remember

Added value: +{
+  "description": "With confirm: true, also stop asking for this kind of action from now on. Only when the person said so (\"don't ask again\"). The person can revoke it in LMCP or with set_always_allowed.",
+  "type": "boolean"
+}

First observedJun 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare a mutating, open-world operation but say nothing about what is transmitted; the description fills that gap by promising an anonymous preview (version, OS, permission status, tool names, error codes) and explicitly excluding arguments, messages and personal data, and by stating that confirm=true returns a case_id. It does not mention that submission is irreversible or how the 'remember' persistence interacts with the send, which keeps it short of a 5.

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-loaded with the purpose, then the confirm-effect distinction, then the mode enum — a sensible order with density and little padding. The final sentence largely restates the report_type enum already present in the schema, which is the only redundant portion.

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

Completeness4/5

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

For a 9-parameter, multi-mode tool with an output schema and full schema descriptions, the description covers the one thing structured fields could not: exactly what data leaves the machine and what the preview versus submit states look like. The remaining gap is sibling disambiguation against request_feature/report_friction and any note that submission cannot be undone.

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%, so the baseline is 3, and the description does add real meaning: confirm=true submits versus a preview, report_type has a documented default, and symptom/description requirements per mode are implied. However, it repeatedly refers to the parameter as 'type', while the schema calls it 'report_type' — a naming mismatch that could cause an agent to send the wrong key.

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

Purpose4/5

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

The description names a specific verb (sends) and three concrete payload kinds (bug report, feature request, integration request), so the tool's function is unmistakable. It loses a point only because it never distinguishes itself from close siblings like request_feature or report_friction, which appear to overlap with the 'feature' mode described here.

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

Usage Guidelines4/5

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

It gives clear triggering conditions — the user wants to report a bug, ask for a new capability, or get support for an uncovered app — and explains the two-step confirm flow. What is missing is any exclusion: nothing tells the agent when to pick this over request_feature or report_friction instead.

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.