elmah.io MCP

messages_bot_by_query

DestructiveIdempotent

Mark all messages matching a query as bot-generated (use instead of messages_bot for large groups, e.g. one client IP). Changes data. Unless the user asked for exactly this change, say which messages you will change and get their confirmation first. First run messages_count with the same logId/severity/query/from and show the user the number (it also counts messages already marked as bot, which are skipped). Returns matchedCount, updatedCount, capped and a few sample messages.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "logId": "<logId>",
      "query": "<query>",
      "severity": "<severity>"
    },
    "name": "messages_bot_by_query"
  }
}

Input Schema

Name	Required	Description
`to`	No	Search to this date.
`from`	No	Search from this date.
`logId`	Yes	The ID (Guid) of the log.
`query`	Yes	Required. Full-text or Lucene query, e.g. statusCode:500 && url:\/api\/. Searchable fields are listed in the server instructions.
`hidden`	No	Include hidden messages (default false).
`severity`	Yes	Required. Severity to match: Verbose\|Debug\|Information\|Warning\|Error\|Fatal.
`maxMessages`	No	Max messages to update per call (default 10000, max 50000). If capped is true, call again.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 9, 2026
- removedInput schema / properties / logId / type
```
Removed value: -"string"
```
- removedInput schema / properties / query / type
```
Removed value: -"string"
```
- removedInput schema / properties / severity / type
```
Removed value: -"string"
```

Changed4 schema fields changedNov 6, 2026

changedInput schema / properties / hidden / description

Previous value: -"Whether to include hidden log messages. Defaults to false."New value: +"Include hidden messages (default false)."

changedInput schema / properties / maxMessages / description

Previous value: -"Maximum number of messages to update in this call (default 10000, max 50000). If more match, capped is true and the call can be repeated."New value: +"Max messages to update per call (default 10000, max 50000). If capped is true, call again."

changedInput schema / properties / query / description

Previous value: -"Required Lucene query selecting the messages to mark. Full-text or Lucene query. Available fields: applicationName, browser, category, country, detail, hidden, hostName, isBot, isBotSuggestion, isBurst, isFixed, isNew, message, messageTemplate, method, os, remoteAddr, severity, source, statusCode, time, type, url, user, userAgent, version. Example: browser:chrome || statusCode:500 || url:*\\/api\\/* && message:\"NullReferenceException\""New value: +"Required. Full-text or Lucene query, e.g. statusCode:500 && url:*\\/api\\/*. Searchable fields are listed in the server instructions."

changedInput schema / properties / severity / description

Previous value: -"Severity to match: Verbose|Debug|Information|Warning|Error|Fatal. Required; use the same value as the messages_count you showed the user."New value: +"Required. Severity to match: Verbose|Debug|Information|Warning|Error|Fatal."

AddedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds context the annotations cannot: it warns 'Changes data', prescribes a confirmation-and-preview flow, and discloses a subtle behavior – the count includes messages already marked as bot, which are then skipped. It also names the return fields, so the agent knows what a successful call yields.

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?

One tight paragraph, front-loaded with the action and the sibling routing, followed by the safety protocol and the pre-check step. No sentence is redundant and the ordering matches the order an agent needs the information.

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?

For a destructive bulk-mutation tool with no output schema, the description covers the action, the alternative, the confirmation requirement, the prerequisite count call, and the shape of the response. Nothing an agent needs to call this safely 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%, so every parameter is already documented, and the description adds only the indirect signal that logId/severity/query/from define the matching set used by the pre-count. It does not add syntax, format, or defaulting details beyond the schema, so this stays at the baseline 3.

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 with explicit scope: 'Mark all messages matching a query as bot-generated'. It also differentiates itself from the sibling messages_bot by naming the large-group case where this tool should be used 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?

Gives explicit routing ('use instead of messages_bot for large groups, e.g. one client IP'), a mandatory pre-step (run messages_count with the same logId/severity/query/from and show the user the number), and a confirmation protocol for when the user did not request the change exactly. This is close to ideal when-to-use guidance.

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

All elmah.io MCP tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?