Skip to content

docs(workflows): say what to check when MCP tools don't load - #23

Open
hercemer42 wants to merge 2 commits into
mainfrom
feature/prd-876-document-mcp-tool-load-failures
Open

docs(workflows): say what to check when MCP tools don't load#23
hercemer42 wants to merge 2 commits into
mainfrom
feature/prd-876-document-mcp-tool-load-failures

Conversation

@hercemer42

@hercemer42 hercemer42 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

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 Error line as it appears at the default log level, and what each failure kind implies for the fix — auth reconnect the credential, connection unreachable or past the 15s per-server timeout, unknown read 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_LEVEL row in Tuning now says what Debug buys you (per-server tool count and load time), since "Debug, Info, Warn, or Error" 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

  • Adds a new subsection in forest-runtime.mdx explaining what to check when an MCP step can't load its tools, including a JSON log example and a breakdown of kind values (auth, connection, unknown).
  • Clarifies that a server returning no tools is not a connection failure — it results in an empty tool list and is a server configuration issue.
  • Notes in mcp-servers.mdx that an empty tools list in step 4 means the server responded but published no tools.
  • Documents that setting LOG_LEVEL to Debug adds one line per MCP server with its tool count and load time.

Macroscope summarized d4a9ab2.

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>
@linear-code

linear-code Bot commented Aug 7, 2026

Copy link
Copy Markdown

PRD-876

@mintlify

mintlify Bot commented Aug 7, 2026

Copy link
Copy Markdown

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
forest 🟢 Ready View Preview Aug 7, 2026, 7:27 AM

💡 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
{

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant