LogMCP is a read-only MCP server that gives AI assistants secure, audited access to log files on a remote Linux server without requiring SSH or shell access. Access is token-authenticated over HTTPS, limited to whitelisted paths, and every access is audited via syslog.
Core Log Access
list_logs — Discover all configured log files, including size, last modified time, line count, and readability status
read_log — Read lines from a log file with head/tail, offset pagination, and time-based filtering (RFC3339 timestamps or relative durations like 1h, 30m)
search_log — Search using Go regular expressions, with optional context lines and time window filtering (up to 200 matches by default)
log_info — Retrieve metadata (size, line count, last modified) for a specific log file
Server Diagnostics
check_environment — Health checks covering configuration validity, TLS setup, log whitelist, syslog, and database connectivity
check_config — View current server settings and optional parameters still at their defaults
server_status — Check if the MCP layer is responding, how many tools are registered, and whether extensions are accessible
Extensions & Security
Expose external CLI tools or Redis RPC workers as additional MCP tools
Multi-token authentication with revocation, whitelist/blacklist control, and fail2ban integration
Supports direct TLS, Caddy reverse proxy, or SSH tunnels for deployment
MCP server — read-only log access for AI assistants. Debug your Linux server with AI, without giving the AI shell access.
No SSH. No write permissions. The AI reads your logs over HTTPS and helps you diagnose problems, while your server stays fully under your control.
LogMCP is an open-source MCP server that exposes log files on a remote Linux server to AI assistants (Claude Code, VS Code, Claude Desktop). Access is read-only, token-authenticated, and fully audited via syslog.
Try LogMCP in under a minute — no config file, no root, no systemd:
logmcp quickstartThe command checks your group memberships (adm, systemd-journal), generates a bearer token and a self-signed TLS certificate, starts the server, and prints a ready-to-paste claude mcp add command.
Running as root? Pass --user <name> and LogMCP will add the user to the required groups and re-launch as that user — root is not needed for future starts.
Note: Token and certificate are ephemeral. The token changes on every start. For a permanent setup use Option B.
logmcp quickstart --port 7789 --token mytoken # optional flagsAfter testing, remove the server from Claude Code:
claude mcp remove logmcp-quickstart1. Install
go install github.com/kascada/logmcp@latestOr install the pre-built .deb (replace x.y.z with the latest version):
curl -LO https://github.com/kascada/logmcp/releases/download/vx.y.z/logmcp_x.y.z_amd64.deb
sudo dpkg -i logmcp_x.y.z_amd64.deb2. Run the setup wizard
sudo logmcp setupGuides you through TLS mode, bearer token, and systemd service — then prints a ready-to-paste client config snippet.
3. Add to your AI client
logmcp client-config claude-code # or: vscode | claude-desktopPaste the output into your MCP client config. Done — your AI can now read the server's logs.
Related MCP server: log-mcp
You give the AI a read-only window into your logs. That's it.
No SSH access required — the AI connects like any HTTPS client
No write permissions — the AI cannot change, delete, or execute anything
No shell access — not even read access beyond the whitelisted log paths
Works from anywhere — your laptop, Claude Desktop, a remote CI agent
Every access is audited via syslog on the server
This makes LogMCP ideal for situations where you need AI-assisted debugging but cannot or do not want to grant shell access: production servers, customer machines, hardened environments, or any setup where least-privilege matters.
SSH is also supported. If your AI client is Claude Code running locally with an SSH key, you can use LogMCP over an SSH tunnel instead of a public HTTPS endpoint. See SSH Tunnel Setup below.
Read-only access to log files — the AI cannot modify anything
Whitelist/blacklist glob patterns for fine-grained access control
systemd journal (journald://) as a virtual log source
Multi-token auth — per-client bearer tokens with revocation
External authenticator support — delegate token verification to any CLI program
TLS support: self-signed, custom cert, or behind Caddy reverse proxy
Audit trail via syslog (access only, no log content)
Guided interactive setup wizard
Systemd service integration
Extensions — expose external CLI tools or Redis-RPC workers as additional MCP tools
Macros — define composite MCP tools as YAML files, no code required
fail2ban integration and in-process rate limiting
The wizard (sudo logmcp setup) covers:
Deployment mode (direct TLS or behind Caddy)
Port and bearer token configuration
Systemd service installation
Client configuration snippets for Claude Code, VS Code, and Claude Desktop
Whitelist/blacklist and journald are configured directly in /etc/logmcp/config.yaml after setup.
Any value in config.yaml can reference environment variables using ${VAR} or $VAR syntax. The substitution happens before the file is parsed, so it works everywhere — tokens, paths, DSNs, etc.
auth:
tokens:
- name: claude
token: ${LOGMCP_TOKEN}
scopes: [read]
extensions:
clitool:
- name: switchboard
command: /usr/local/bin/switchboard
timeout_seconds: 10Unset variables expand to an empty string. To keep a literal $ in a value, use $$.
After setup, start the server:
sudo systemctl start logmcpCommand | Description |
| Start the MCP server (default) |
| Start instantly without config file (no root required) |
| Interactive setup wizard |
| Verify configuration and environment |
| List configured bearer tokens |
| Add a new bearer token |
| Remove a bearer token |
| Generate a new value for an existing token |
| List accessible log files |
| Read a log file or |
| Search a log file or |
| Show log file metadata |
| Install systemd service |
| Remove systemd service |
| Show service status |
| Print Caddyfile configuration |
| Print Claude Code MCP config |
| Print VS Code MCP config |
| Print Claude Desktop MCP config |
| Install fail2ban filter and jail for logmcp |
These are the tools LogMCP exposes to AI assistants:
Tool | Description |
| List all log files the server has been configured to expose |
| Read lines from a log file — head, tail, offset, or time window |
| Search a log file by regexp with optional context lines and time filter |
| File metadata: size, line count, last modified |
| Server-side health checks (config, TLS, whitelist, syslog, databases) |
| Show current server configuration and optional parameters at their defaults |
| Runtime status of the MCP layer and registered extensions |
Extensions may add further tools — their names are prefixed with the extension name (e.g. myapp_status for an extension named myapp).
LogMCP can expose any external program or service as additional MCP tools — no custom MCP server required. The AI sees them alongside the built-in log tools.
Any program that implements the clitool interface (list / call subcommands) can be registered. LogMCP calls <command> list at startup to discover tools, and forwards each tool call to <command> call <tool> --token-stdin.
extensions:
clitool:
- name: myapp
command: /usr/local/bin/myapp-ctl
timeout_seconds: 10This spawns a subprocess per call — suitable for any program on the same or a remote host.
For programs running on the same host, the RPC variant avoids the per-call process-startup overhead (relevant for Python programs where interpreter startup and imports add noticeable latency). Instead of spawning a subprocess, LogMCP pushes a request onto a Redis list and waits for the worker's reply.
extensions:
clitool:
- name: myapp
command: /usr/local/bin/myapp-ctl # still used for `list` at startup
mode: rpc
redis_addr: "127.0.0.1:6379"
timeout_seconds: 5The worker reads requests from a Redis list and pushes its reply to a per-request reply key. See docs/RPC.md for the full protocol.
The bearer token from each incoming MCP request is forwarded to the extension — either via stdin (CLI mode) or as caller metadata in the RPC envelope. The extension can verify it or trust the pre-resolved identity.
Real-world scenarios where LogMCP makes the difference — see docs/case-studies.md:
If you are using Claude Code locally and already have SSH access to the server, you can run LogMCP without a public HTTPS endpoint:
# Forward remote port 7788 to localhost
ssh -L 7788:127.0.0.1:7788 user@yourserver
# Then point your MCP client at https://localhost:7788LogMCP still requires a bearer token over the tunnel — the SSH layer adds transport security, the token controls which client can connect.
MIT License — see LICENSE.
Show the current LogMCP server configuration and highlight optional parameters that are at their default value.
Use to understand how this server is configured — which logs are accessible, whether proxy mode or fail2ban are active, which tools are enabled, and which optional features are not yet configured. See logmcp://docs/config for the full configuration reference.
Object with two fields:
current — key configuration values currently active on this server
defaults — optional parameters that are at their default value, each with a short explanation of what they do
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only operation ('Show', 'highlight'), but annotations set destructiveHint=true. No disclosure of any destructive behavior contradicts the description, leading to a score of 1. Annotation contradiction flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (main purpose, when to use, response format). Every sentence adds value; no wasted words. Front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and simple output, the description is complete in explaining purpose and response. Provides reference to config docs. However, the contradiction with annotations slightly degrades completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds meaning by explaining the response structure (current and defaults fields). Baseline 4 for zero parameters is appropriate with the addition of response semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states specific verb 'Show' and resource 'current LogMCP server configuration', with additional detail about highlighting default parameters. It distinguishes from sibling tools like 'server_status' and 'check_environment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly describes scenarios (understanding accessible logs, proxy mode, etc.) and references configuration documentation. Does not mention when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a set of server-side environment checks and return their pass/fail status. Covers configuration validity, TLS setup, log file whitelist, syslog connectivity, and database connectivity.
Use to verify that the LogMCP server is configured correctly and that all configured backends are reachable. Useful when diagnosing why a tool is not working as expected, or after a configuration change.
Array of check result objects, each with:
name — check identifier (e.g. config, tls, whitelist, syslog)
ok — true if the check passed, false if it failed
detail — human-readable description of the result or error (omitted when empty)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: true, implying potential side effects, but the description describes only checks that return status (no modifications). This contradiction misleads the agent about the tool's behavior. The description does not clarify the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and organized into clear sections ('When to use', 'Response'). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains the checks performed and the structure of the response array, making the tool's behavior complete and understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is trivially 100%. The description adds no parameter information beyond the schema, but this is acceptable per the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a set of server-side environment checks and returns pass/fail status, listing specific covered areas (config, TLS, etc.). This distinguishes it from sibling tools like check_config (likely more specific) and server_status (probably server-level info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section provides explicit scenarios: verifying configuration, diagnosing tool issues, or after configuration changes. It lacks explicit exclusions or alternatives but gives clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all log files the server has been configured to expose. Returns an array of file entries ordered by path.
Call this first to discover which log files are available before calling read_log, search_log, or log_info. If you do not know the exact path of a log file, always call list_logs first.
Array of objects, each with:
path — absolute path on the server
size_bytes — file size in bytes
last_modified — last-modified timestamp (RFC3339)
line_count — total number of lines
readable — whether the file is accessible by the server process
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but description does not elaborate on why it's destructive or any side effects. Response format is useful but not behavioral. Some value added, but no hidden traits disclosed beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections. Every sentence adds value, no fluff. Concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter list tool, description covers purpose, usage guidance, and response format thoroughly. No missing aspects given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is irrelevant. Baseline 4 applies; description does not need to add param info and doesn't miss anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all log files the server has been configured to expose' with verb and resource. Distinguishes from sibling tools like read_log and search_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this first before using read_log, search_log, or log_info, and to use it when path is unknown. Provides clear 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.
Return metadata for a single log file: size, line count, and last-modified timestamp.
Use to check whether a log file has changed recently, or to determine its total size and line count before deciding how many lines to read with read_log.
Absolute path to the log file. Obtain valid paths from list_logs.
path — file path
size_bytes — file size in bytes
line_count — total number of lines in the file
last_modified — last-modified timestamp (RFC3339)
readable — whether the file is accessible by the server process
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the log file. Obtain valid paths from `list_logs`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating it returns metadata. However, annotations have destructiveHint=true, which contradicts this. The description does not address this inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for when to use, parameters, and response. It is concise with no wasted words, and every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully details the response fields and provides enough context for an agent to use the tool correctly. For a simple tool with one parameter, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats exactly what the schema already provides ('Absolute path to the log file. Obtain valid paths from list_logs.'). No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns metadata (size, line count, last-modified) for a single log file. It distinguishes from siblings like list_logs (which lists files) and read_log (which reads content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly says to check if a log file has changed or determine size/line count before reading. It references read_log as an alternative, but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read lines from a log file. Supports reading from the beginning or end, with optional time-based filtering.
Use to inspect a specific portion of a log file. Use tail: true for the most recent entries. Use since/until to narrow to a specific time window. For targeted pattern matching, prefer search_log instead.
Absolute path to the log file. Obtain valid paths from list_logs.
Number of lines to return. Defaults to 100.
If true, return the last N lines instead of the first N. Useful for checking recent log activity. Default: false.
Skip this many lines from the start (or from the end if tail=true). Use for pagination through large files.
Return only lines after this point in time. Accepts RFC3339 timestamps (2024-01-15T10:00:00Z) or relative durations (1h, 30m, 2h30m). Relative durations are resolved against the current server time.
Return only lines before this point in time. Same format as since.
path — file path that was read
lines — array of log lines (strings)
count — number of lines returned
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the log file. Obtain valid paths from `list_logs`. | |
| tail | No | If true, return the last N lines instead of the first N. Useful for checking recent log activity. Default: false. | |
| lines | No | Number of lines to return. Defaults to 100. | |
| since | No | Return only lines after this point in time. Accepts RFC3339 timestamps (`2024-01-15T10:00:00Z`) or relative durations (`1h`, `30m`, `2h30m`). Relative durations are resolved against the current server time. | |
| until | No | Return only lines before this point in time. Same format as `since`. | |
| offset | No | Skip this many lines from the start (or from the end if `tail=true`). Use for pagination through large files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully explains the tool's behavior: reading from start or end, time-based filtering, pagination, default line count, and response structure. Despite `destructiveHint=true` in annotations, the description accurately reflects a read-only operation, adding transparent details beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and front-loaded purpose. Every sentence adds value—no fluff. It is appropriately sized for 6 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description includes a 'Response' section detailing output fields (path, lines, count), making it complete. It covers time filtering, pagination, and file source, addressing all aspects for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description adds significant meaning: explains when to use `tail`, describes time formats with examples, clarifies offset for pagination, and lists defaults. This goes well beyond the schema by providing usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read lines from a log file' and specifies reading from beginning or end with time filtering. It distinguishes from sibling 'search_log' by noting that tool is for pattern matching, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section explicitly states when to use the tool (inspect log portions), when to use `tail` (recent entries), and when not to (use `search_log` for pattern matching). It also advises obtaining paths from `list_logs`, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a log file for lines matching a regular expression. Returns matching lines with optional surrounding context.
Use when you need to find specific events, errors, or patterns in a log file without reading the whole file. More efficient than read_log for targeted searches. Combine with since/until to scope the search to a time window.
Absolute path to the log file. Obtain valid paths from list_logs.
Regular expression to search for. Uses Go regexp syntax. The pattern is not echoed back in the response.
Restrict the search to lines after this point in time. Accepts RFC3339 timestamps or relative durations (1h, 30m).
Restrict the search to lines before this point in time. Same format as since.
Maximum number of matching lines to return. Default: 200.
Number of surrounding lines to include before and after each match. Default: 0 (match lines only).
path — file path that was searched
pattern_redacted — always "<redacted>" (the search pattern is not echoed back for security reasons)
matches — array of match objects, each with:
line — the matching log line
line_number — 1-based line number in the file
context_before / context_after — surrounding lines (only present if context_lines > 0)
count — total number of matches returned
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the log file. Obtain valid paths from `list_logs`. | |
| since | No | Restrict the search to lines after this point in time. Accepts RFC3339 timestamps or relative durations (`1h`, `30m`). | |
| until | No | Restrict the search to lines before this point in time. Same format as `since`. | |
| pattern | Yes | Regular expression to search for. Uses Go regexp syntax. The pattern is not echoed back in the response. | |
| max_results | No | Maximum number of matching lines to return. Default: 200. | |
| context_lines | No | Number of surrounding lines to include before and after each match. Default: 0 (match lines only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond annotations: pattern redaction, response structure with context lines, and default values. However, annotations indicate destructiveHint=true while description implies read-only operation, creating a subtle contradiction not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (overview, when to use, parameters, response). Each sentence is informative, no fluff, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description details the response structure. It covers parameters and usage well but fails to explain the destructiveHint=true annotation anomaly, leaving a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value with context like 'Obtain valid paths from list_logs' for path and 'Uses Go regexp syntax' for pattern. This surpasses the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches log files for regex patterns, specifying verb, resource, and result. It distinguishes from sibling 'read_log' by targeting specific patterns versus full file reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'When to use' section explains the tool is for targeted searches without reading the whole file, explicitly comparing it to 'read_log'. It suggests combining with temporal parameters but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the runtime status of this LogMCP server: whether the MCP layer is responding, how many tools are registered, and whether each configured extension is accessible.
Use as a first step when diagnosing MCP connectivity issues — before the deeper check_environment checks (file system, systemd, TLS). Returns quickly and confirms that the MCP tool layer itself is functional.
ok — true if all checks passed.
checks — array of check result objects, each with:
name — check identifier
ok — true if the check passed, false if it failed
detail — human-readable description of the result or error (omitted when empty)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description describes a read-only status report, but annotations set readOnlyHint=false and destructiveHint=true, contradicting the implied behavior. This is a serious inconsistency that undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with 'When to use' and 'Response' sections. Every sentence adds value, no redundancy. Efficiently conveys all necessary information about usage and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers the tool's purpose, usage context, and response format. It is self-contained and leaves no ambiguity about what the tool does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds no parameter-level detail but provides useful context about the response and return structure, which aligns with standard practice for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reports runtime status of LogMCP server, including MCP layer responsiveness, tool count, and extension accessibility. It uses specific verb 'report' and distinguishes from siblings like check_environment by positioning as a first connectivity check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use as first step for MCP connectivity issues and to use before deeper checks. Provides clear context for when to apply the tool and how it fits into a diagnostic workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.7.5check_configcheck_environmentlist_logslog_inforead_logsearch_logserver_statusv0.7.4check_configcheck_environmentlist_logslog_inforead_logsearch_logserver_statusv1.0.0check_configcheck_environmentlist_logslog_inforead_logsearch_logserver_statusEach tool has a clearly distinct purpose: configuration inspection, environment validation, log discovery, metadata retrieval, reading, searching, and server status. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., check_config, list_logs, read_log). No mixing of conventions.
With 7 tools, the set covers all core operations for a log management server without being excessive or sparse. Each tool earns its place.
The surface covers log discovery, reading, searching, metadata, and diagnostic checks. A minor gap is the lack of real-time tailing or streaming, but the set is otherwise complete for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kascada/logmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
