docs(workflows): say what to check when MCP tools don't load - #23
Open
hercemer42 wants to merge 2 commits into
Open
docs(workflows): say what to check when MCP tools don't load#23hercemer42 wants to merge 2 commits into
hercemer42 wants to merge 2 commits into
Conversation
An empty tool list, a rejected credential and an unreachable server are the three ways a connector fails, and they need three different fixes. Forest Runtime now names which one it was in its logs, so point readers at that rather than leaving "check that all the expected tools are exposed" as the only guidance. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
| Forest Runtime logs the reason at `Error`, so it is in your logs without changing `LOG_LEVEL`: | ||
|
|
||
| ```json | ||
| { |
There was a problem hiding this comment.
🟡 Medium workflows/forest-runtime.mdx:247
The documented JSON example shows a failures array with server, kind, and error fields, but the actual production log emits requestedMcpServerId, mcpServerName, and failedConfigNames — not failures. The kind field does not exist in the log, so operators following the guidance to use kind to distinguish auth, connection, and unknown failures cannot find it. Update the example to match the real payload, or change the logging to include the kind field.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @product/process/workflows/forest-runtime.mdx around line 247:
The documented JSON example shows a `failures` array with `server`, `kind`, and `error` fields, but the actual production log emits `requestedMcpServerId`, `mcpServerName`, and `failedConfigNames` — not `failures`. The `kind` field does not exist in the log, so operators following the guidance to use `kind` to distinguish `auth`, `connection`, and `unknown` failures cannot find it. Update the example to match the real payload, or change the logging to include the `kind` field.
A symptom-titled troubleshooting section restated the runtime page's failure taxonomy in product language, so the same knowledge lived on two pages and would drift. Only the empty-list meaning was new, and it belongs where the reader meets it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Follow-up to PRD-876. The executor half (agent-nodejs#1806) makes Forest Runtime name why an MCP connector failed to load its tools; this documents what a reader does with that.
Forest Runtime → Observability
New subsection, "When an MCP step can't load its tools": the
Errorline as it appears at the default log level, and what each failurekindimplies for the fix —authreconnect the credential,connectionunreachable or past the 15s per-server timeout,unknownread the error text. Also states that a server answering with no tools is an empty list rather than an error, which is the behaviour the PR changes.The
LOG_LEVELrow in Tuning now says whatDebugbuys you (per-server tool count and load time), since "Debug,Info,Warn, orError" gave no reason to ever lower it.MCP Connectors
New "A connector's tools don't load" section. The page previously ended at "Check that all the expected tools are exposed" with no guidance when they aren't. It now names the three failure modes in the order worth checking — nothing published, credential rejected, server unreachable — and points self-hosters at the runtime logs that distinguish them.
Nothing removed; no existing statement was inaccurate.
Note
Document MCP tool loading failures and empty tool list behavior in workflow docs
kindvalues (auth,connection,unknown).LOG_LEVELtoDebugadds one line per MCP server with its tool count and load time.Macroscope summarized d4a9ab2.