Skip to main content
Glama
alokemajumder

wpxmcp

by alokemajumder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Read the PHP error log

tail_error_log
Read-only

Diagnose white screens, 500 errors, and critical errors by reading PHP error log. Groups duplicate entries, identifies responsible plugin/theme/core file, and reports debug settings and last fatal.

Instructions

Read the end of the site's PHP error log (wp-content/debug.log or php.ini error_log) without downloading it, with duplicate errors grouped and each one attributed to the plugin, theme or core file that raised it. Also reports whether WP_DEBUG / WP_DEBUG_LOG / WP_DEBUG_DISPLAY are on and the last fatal error the companion plugin recorded — which is captured even when logging is off. Start here for white screens, 500 errors and "there has been a critical error". Needs the companion plugin.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
grepNoOnly entries whose message or stack trace contains this text (case-insensitive), e.g. a plugin slug.
levelNoMinimum severity to include: "warning" returns fatals, errors and warnings; "all" also includes unrecognised lines.all
linesNoHow many lines to read from the end of the log (1–2000). Stack-trace lines count toward this.
sinceNoOnly entries at or after this time, as an ISO 8601 date/time, e.g. "2026-09-15T08:00:00Z".
site_idNoWhich configured WordPress site to act on. Optional — with a single site configured it is used automatically; with several, the default site is used unless you name one. Run list_sites for valid ids.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark it read-only and non-destructive, and the description adds substantial behavioral detail: it reads from the end without downloading, groups duplicates, attributes errors, reports debug constants, and records fatal errors even when logging is off. The 'Needs the companion plugin' caveat is important operational context. 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?

Dense but efficient: purpose, distinctive behavior, use cases, and a prerequisite are all present with no filler. The most important scoping statement is front-loaded, and supporting detail follows logically.

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 tool with no output schema, the description explains the main return content (grouped, attributed errors; debug-flag report; last recorded fatal) and the operational prerequisite. It covers enough for an agent to select and call it correctly; only a formal result structure is left unspecified.

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%: grep, level, lines, since, and site_id each have meaningful descriptions. The tool description doesn't add parameter-level semantics, but with full schema coverage the baseline of 3 is appropriate.

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?

Opens with a specific verb and resource ('Read the end of the site's PHP error log'), names concrete log paths, and describes distinctive outputs (deduplicated/attributed entries, WP_DEBUG state, last fatal). This clearly distinguishes it from sibling audit/log tools even without naming one.

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?

Explicitly frames when to reach for it: 'Start here for white screens, 500 errors and "there has been a critical error"'. It also states the companion-plugin prerequisite. It doesn't name alternatives or when-not-to-use, so not a 5.

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

Deploy Server

Other Tools