Repository navigation
feat: show config source and recent tool calls through tool output - #266
Merged
Merged
Conversation
Claude Desktop does not capture an installed extension's stderr (every extension log under ~/Library/Logs/Claude has zero server output, while hand-configured servers have thousands of lines), so log lines cannot tell a user which config file is live or which tool call failed. Expose both through tools instead: - wp_test_auth reports the configuration in use: the multi-site file that was loaded, where it came from (with a warning for the install folder, which an extension update replaces) and the site IDs, or the single-site fallback and the paths that were searched. ServerConfiguration records this in getLoadInfo(). - wp_performance_stats (category=tools) lists the last 50 tool calls, newest first: tool, site, status, duration and, for a failure, the HTTP status, error code and a truncated message. Call parameters are never stored. The registry now passes the thrown error and the resolved site to the tracker. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Reviewer's GuideAdds tool-output diagnostics for installed extensions that lack host stderr capture: Sequence diagram for tool-output diagnosticssequenceDiagram
participant User
participant ToolRegistry
participant MetricsCollector
participant PerformanceMonitor
participant PerformanceTools
User->>ToolRegistry: execute tool
ToolRegistry->>MetricsCollector: startToolExecution(toolName, parameters, siteId)
ToolRegistry->>ToolRegistry: resolve site and run tool
alt tool succeeds or fails
ToolRegistry->>MetricsCollector: endToolExecution(executionId, success, failure, siteId)
MetricsCollector->>PerformanceMonitor: recordToolCall(toolName, responseTime, success, details)
PerformanceMonitor->>PerformanceMonitor: retain latest 50 calls without parameters
end
User->>PerformanceTools: wp_performance_stats(category=tools)
PerformanceTools->>MetricsCollector: getRecentToolCalls(limit)
MetricsCollector->>PerformanceMonitor: getRecentToolCalls(limit)
PerformanceMonitor-->>PerformanceTools: newest-first call records
PerformanceTools-->>User: recentCalls with status and failure metadata
Sequence diagram for configuration provenance in wp_test_authsequenceDiagram
participant User
participant AuthTools
participant ServerConfiguration
User->>AuthTools: wp_test_auth
AuthTools->>ServerConfiguration: getLoadInfo()
ServerConfiguration-->>AuthTools: mode, configPath, source, siteIds, searched
AuthTools-->>User: authentication result with Configuration and Configured sites
alt single-site configuration
AuthTools-->>User: environment-variable mode and searched paths
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ce7ed055a2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Failure paths omit configuration diagnostics, and retained error messages can indirectly expose call parameters.
2 open findings
What changed in this PR
Exposes configuration-source and recent tool-call diagnostics through MCP output.
Changes:
- Tracks configuration load details and reports them via
wp_test_auth. - Retains and exposes the 50 most recent tool calls.
- Adds tests and regenerates API documentation.
| File | Description |
|---|---|
src/config/ServerConfiguration.ts |
Records configuration load information. |
src/config/AGENTS.md |
Documents configuration diagnostics. |
src/performance/PerformanceMonitor.ts |
Retains recent tool-call records. |
src/performance/MetricsCollector.ts |
Forwards failure and site metadata. |
src/performance/AGENTS.md |
Documents recent-call tracking. |
src/server/ToolRegistry.ts |
Passes resolved sites and errors to tracking. |
src/tools/auth.ts |
Adds configuration details to successful auth output. |
src/tools/performance/PerformanceTools.ts |
Exposes recent calls in performance statistics. |
tests/config/ServerConfiguration.test.js |
Tests load diagnostics. |
tests/performance/MetricsCollector.test.js |
Tests metadata forwarding. |
tests/performance/PerformanceMonitor.test.js |
Tests retention, ordering, and truncation. |
tests/server/ToolRegistry.test.js |
Tests registry tracking integration. |
tests/tools/auth.test.js |
Tests successful configuration reporting. |
docs/api/tools/wp_test_auth.md |
Documents configuration reporting. |
docs/api/tools/wp_performance_stats.md |
Documents recent-call diagnostics. |
docs/api/openapi.json |
Regenerates OpenAPI descriptions. |
docs/api/README.md |
Refreshes generated tool documentation. |
docs/api/summary.json |
Updates generation metadata. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Resolves the MetricsCollector conflict with #267 (keeps getRecentToolCalls and getActiveAlerts and both type imports) and the generated docs timestamp. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- wp_test_auth only reported the configuration on success, but a failed test (bad credentials, unreachable site, timeout) is exactly when a user needs to know which configuration is live. The failure message now carries it; the typed error (status, code) is preserved. - Client-supplied configuration (an MCP client's mcpConfig, which takes precedence over the environment per field) was reported as "environment variables". getLoadInfo() now records singleSiteSource. - Recent calls no longer retain any error text: validation and upload errors quote the offending argument or path, so truncation did not honour "call parameters are never recorded". Only the HTTP status, error code and error type (class name) are kept. - Failures that do not throw (a result with success:false / status "unavailable", a missing or unknown site) now record a fixed reason code (tool_reported_failure, site_required, site_not_found) instead of nothing, again without echoing the arguments. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
docdyhr
pushed a commit
that referenced
this pull request
Oct 9, 2026
## [4.1.0](v4.0.11...v4.1.0) (2026-10-09) ### 🚀 Features * show config source and recent tool calls through tool output ([#266](#266)) ([bd744ba](bd744ba))
Owner
Author
|
🎉 This PR is included in version 4.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Description
Claude Desktop does not capture an installed extension's stderr. Checked across
~/Library/Logs/Claude/mcp-server-*.log: servers configured by hand inclaude_desktop_config.jsonhave thousands of raw stderr lines, while every installed extension (Bear Notes, Filesystem, Control Chrome, Word, PDF Tools, this one) has none. So extralogger.*output can never tell a user which config file is live or which tool call failed. This exposes both through tool output instead (open items from the v4.0.3 debug test results: "log has no tool names", "which config loaded").Type of Change
Changes Made
ServerConfiguration.getLoadInfo()records how the last load configured the server: mode, loaded file and its source, site IDs, and (single-site) the paths that were searchedwp_test_authreports it on success and in the failure message (bad credentials, unreachable site, timeout keep their typed error):**Configuration:** multi-site, loaded from <path> (<source>)+**Configured sites:** …, orsingle-site (environment variables | client-supplied configuration); no multi-site config file found in: …. The install-folder source carries a warning that an extension update replaces that folder. Omitted if nothing was recorded.PerformanceMonitorkeeps the last 50 tool calls in memory (getRecentToolCalls()): tool, site, status, duration and, for a failure, HTTP status, error code and the error's type (class name). Call parameters and error text are never stored — messages can quote the arguments (validation errors, upload paths). Failures that don't throw carry a fixed code:tool_reported_failure,site_required,site_not_found.wp_performance_stats(category=tools) returns them asrecentCalls, newest first (10 in summary format, 50 in detailed)ToolRegistrypasses the thrown error and the resolved site to the tracker;MetricsCollector.endToolExecution(id, ok, error?, siteId?)forwards themdocs/apiregenerated;src/config/AGENTS.mdandsrc/performance/AGENTS.mdupdatedToolRegistry/MetricsCollectortests changed to the new argument lists; ~25 new testsTesting
npm test): 87 files / 2711 tests (after merging main and addressing review); the new tests were red firstformat:check, markdownlint (the first commit attempt failed on an MD013 line length insrc/performance/AGENTS.md; rewrapped, hook not bypassed)HOMEand a local WordPress stub.wp_test_authprinted the config path, source andsite1, site2; after a 403 onwp_get_site_settings,wp_performance_statslisted it withstatusCode: 403,errorCode: "rest_forbidden".Notes for reviewers
feat:so semantic-release will cut a minor release (4.1.0).Documentation
Security
🤖 Generated with Claude Code
Summary by Sourcery
Expose configuration provenance and recent tool-call outcomes through tool responses so installed extensions can provide actionable diagnostics without relying on host-captured logs.
New Features:
wp_test_auth, including single-site fallback diagnostics.wp_performance_stats, including tool, site, status, duration, and safe failure metadata.Enhancements:
Documentation:
wp_test_authand recent-call reporting inwp_performance_stats.Tests: