{"version":1,"scope":"full","truncated":false,"id":"editorial-learn-agent-tool-error-triage","url":"https://wenbu.app/en/learn/agent-tool-error-triage/","locale":"en","revision":"1aac817a6e3d15d201c1cb465dde3904627737adadd9760149b9b05dc7aab700","updated":"2026-11-04T01:07:24.149Z","content":"# When an agent call fails, read the status and conventions before retrying\n\nA failed agent call tells you that something did not complete as agreed, not that the spread or chart is wrong. This guide uses a triage table to check the terminal status, then the input fields and stated conventions, before deciding whether to retry, fix the input or stop.\n\nUpdated: 2026-11-04 · Wenbu AI-assisted editorial\n\nRead the terminal status first, the error message second, and the content last. MCP declares an outputSchema for successful results and returns structuredContent, so the first check is isError. REST errors carry a stable code and a readable message: 422 usually means an invalid field or moment, while 429 means short-term rate limiting or insufficient AI quota. For the agent command, inspect the status on the done event: complete means the turn finished, waiting means the user must add something, and limited means the budget is used up. An error, or a stream with no terminal event, is not completion; content already received may be kept, and retrying is the user's decision. Order matters: did the call succeed, do the fields fit the conventions, and does this failure touch randomness or metering? Correct the input only when the input is wrong, back off only when it is rate limiting, and never auto-retry an AI request that may already have been counted.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n- Check the terminal status and isError before the message, and the message before judging content.\n\n- A 422-type error means check fields and moments; a 429-type error means back off. Do not merge them.\n\n- A broken stream and an error are both not completion; keep received content and let the user decide on retrying.\n\n- Random tarot and coin results should be preserved; a redraw is a new draw, not a repair.\n\n- An AI request that already started may be counted even if it fails, so do not build an automatic retry loop.\n\n## Triage flow for a failed call\n\n1. **Read the terminal status** — For MCP, check isError; for the agent command, check whether the done event status is complete, waiting, limited or error.\n\n2. **Read the error message** — REST errors carry a stable code and readable message; 422 points to a field or moment, 429 to rate limiting or insufficient quota.\n\n3. **Check input conventions** — Compare date range, timezone, day boundary, I Ching line values, tarot count and ziwei inputs against the published conventions.\n\n4. **Assess metering risk** — An AI request that already started may be counted even if it fails, so do not auto-retry; pure calculation tools can be resent after fixing input.\n\n5. **Decide and report honestly** — Fix input, back off, ask the user to add context, or keep received content and stop; do not promise when quota returns.\n\nStart from the terminal status, then check the protocol layer, the input layer and metering risk before deciding to retry, fix the input or stop. Each step uses only signals the documentation states, with no invented error codes or retry policies.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n## Separate three kinds of failure: protocol, input, and unideal content\n\nThe most common mistake when an agent call fails is to merge three situations: the protocol layer did not return success, the input did not fit the stated conventions, and the result came back but reads poorly. The first two are engineering problems; the third is an interpretation problem. MCP declares an outputSchema for successful results and returns structuredContent, so checking isError first isolates protocol-level trouble. REST endpoints return JSON on success, while errors carry a stable code and a readable message, which is enough to separate \"did not succeed\" from \"succeeded but I dislike it.\"\n\nUnideal content is not an error. Tarot and online coin casting are drawn randomly by the program, and the page preserves the original result. Calculations can be reproduced under stated conventions, but that does not mean interpretations have been scientifically validated. So when a spread or hexagram does not match expectations, the right move is to keep the result and reframe the question, not to treat it as a failed call to retry. Writing \"the result was not to my liking\" into error handling turns retrying into repeated demands on a random outcome.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · calculation conventions](https://wenbu.app/methodology/)\n\n## Input fields: four self-checks before you blame a 422\n\nA REST 422 usually means an invalid field or moment, so check the input against the conventions before changing code. Bazi needs a Gregorian date from 1901 to 2099, the local clock time at the birthplace, and either an IANA timezone name or an explicit UTC offset. Omitting the timezone falls back to Asia/Shanghai and returns a warning, which is \"runs but note it,\" not an error. The day boundary defaults to 00:00 and can optionally switch to the 23:00 Zi boundary; an unknown birth time omits the hour pillar and provisionally uses local noon for year and month, with an uncertainty note on solar-term days.\n\nThe second group to check is each tool's parameter shape. Each I Ching line takes 6, 7, 8 or 9, ordered bottom to top, with 6 and 9 as changing lines. Tarot accepts only 1 or 3 cards, drawn without replacement from a 78-card deck. Ziwei takes the Gregorian date and known clock time at the birthplace and does not convert timezones or correct solar time automatically. Read these fields as a contract: many \"failed calls\" could have been caught before the request went out, saving a request that might be metered.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · calculation conventions](https://wenbu.app/methodology/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n## Rate limits and metering: what a 429 does and does not tell you\n\nEach network has a per-minute request limit, and the documentation says to back off on a 429. A 429 means short-term rate limiting or insufficient AI quota, and the error message tells you which. The documentation gives no reset time, backoff curve or retry count, so do not invent \"wait 60 seconds and try three times,\" and do not promise readers when quota will return. What you can do is read the message, decide whether to wait or stop, and tell the user honestly what happened.\n\nMetering deserves more care. An AI request that has already started may be counted even if it fails, and the documentation explicitly says not to retry automatically. That flips the default direction of error handling: for pure calculation tools, resending after fixing the input is reasonable; for a request that already reached the AI stage, resending may consume quota again and should be the user's call. MCP calculations, the daily card and library reads do not invoke a model, so they should not be lumped in with the metering rules for AI requests.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n## Broken streams, waiting and limited: describe \"not finished\" precisely\n\nThe agent command emits line-by-line JSON events, and you check the status on the final done event: complete means the turn finished, waiting means the user must add something, and limited means the budget is used up. An error, or a stream with no terminal event, is not completion; content already received may be kept, and retrying is the user's decision. The key is to keep four states apart: waiting is not a failure but missing information; limited is not a fault but a budget boundary; a broken stream is not an empty result but an interrupted transfer.\n\nWording should therefore be precise. \"This turn did not finish; here is what arrived; you decide whether to continue\" is more honest than \"the service failed, please retry,\" and it matches the documentation. If the status is waiting, the right action is to supply the missing context, such as the part of the material the user agrees to share. If the status is limited, say the budget is used up rather than rephrasing and sending again. Keeping received content on a broken stream also prevents users from thinking nothing happened.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/)\n\n## Triage table for five agent outcomes\n\n| Outcome | Check first | What it supports | What not to conclude |\n| --- | --- | --- | --- |\n| Invalid field (422-type) | The field named in the error message; date range, timezone, day boundary, line values, tarot count | This request's input did not fit the published conventions | That the spread or chart is wrong, or the tool is unavailable |\n| Rate limited or out of quota (429-type) | Whether the message names short-term limiting or insufficient AI quota; whether the AI stage has begun | You need to back off or stop, with the message as the guide | When quota returns or how many retries to make; the docs give no such numbers |\n| Broken stream (no terminal event) | Whether a done event arrived; whether received content is complete | The turn did not finish, and received content may be kept | That the result is empty, or that you must resend immediately |\n| Budget limited (limited) | The done event status and whether the user wants to continue | The turn's budget is used up and continuing is the user's choice | That the service is broken, or that rephrasing will bypass it |\n| Successful but empty or unideal | isError and structuredContent; whether input was complete and the question clear | The call succeeded at the protocol level; the issue is interpretation or framing | That the random draw failed, or that you should redraw until satisfied |\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n## Hypothetical case: a tarot call that returned no reading\n\nThe following is a fictional situation for demonstrating triage order. It involves no real user data and is not an actual computed spread. Suppose a reader asks an agent for three tarot cards plus a reading, and the interface only shows \"something went wrong,\" with no cards.\n\n1. First, look at the terminal signal rather than the content: for an MCP call, check isError and whether structuredContent came back; for the agent command, check whether a done event exists and what its status is. No terminal event means treat it as a broken stream, not an empty result.\n\n2. Second, read the error message. If it points to a field, check whether the count was 1 or 3 and whether an extra parameter slipped in. If it points to rate limiting or quota, treat it as a 429 and back off, without inventing a retry count.\n\n3. Third, decide whether the AI stage had begun. If generation had started, the request may be counted even on failure, so do not resend automatically; report the status and whatever arrived, and let the reader decide whether to continue.\n\n4. Fourth, if the call actually succeeded and only the reading was empty or off-target, keep the returned cards and reframe the question or add context instead of redrawing. A redraw is a new random draw that may coincidentally repeat a card, but it cannot reproduce the previous result on demand.\n\nThe conclusion is not \"the service is broken\" but \"confirm which layer did not finish.\" A protocol failure means fix the request; an input failure means fix the fields; a metering risk means hand the decision to the user; unideal content means keep the result and change the question. Four actions map to four kinds of evidence and cannot substitute for each other.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json) · [Wenbu · calculation conventions](https://wenbu.app/methodology/)\n\n## FAQ\n\n### An MCP call returned content, but I am unsure whether it counts as success. What now?\n\nCheck isError first, then whether structuredContent came back with the declared outputSchema. MCP declares an outputSchema for successful results and returns structuredContent alongside text JSON, and the documentation puts the isError check first. If isError is true, the content is only an error message and should not be interpreted.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n### On a 429, can I just wait a bit and retry automatically?\n\nThe documentation only says each network has a per-minute request limit and to back off on a 429, noting that a 429 may be short-term limiting or insufficient AI quota and that the message should be read. It gives no reset time or retry count, so do not hard-code a wait. If the request already reached the AI stage, a failure may still be counted, which is another reason not to auto-retry.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/)\n\n### Is an agent saying \"not finished\" the same as an error?\n\nNot exactly. The done event status has three values: complete, waiting and limited. Only complete means the turn finished; waiting means the user must add something, limited means the budget is used up, and neither of those is completion. An error, or a stream with no terminal event, is also not completion. Calling waiting a fault misleads users into retrying when the right action is to supply context.\n\n[Wenbu · agent integrations](https://wenbu.app/agents/)\n\n### If I dislike the cards, can I redraw until I am satisfied?\n\nTarot draws 1 or 3 cards with equal probability from 78, without replacement within a single draw, and results should be kept for follow-up. A redraw is a new random procedure that may coincidentally repeat a card but cannot reproduce the previous result on demand. Treating a redraw as a repair hides the real issue, which is usually the question or the context.\n\n[Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json) · [Wenbu · calculation conventions](https://wenbu.app/methodology/)\n\n## Glossary\n\n- **isError**: The field in an MCP result marking whether the call failed. The documentation recommends checking it before reading structuredContent or the text JSON. [Wenbu · agent integrations](https://wenbu.app/agents/)\n\n- **structuredContent**: The structured content returned with successful MCP results alongside outputSchema, so the host can read fields instead of guessing from free text. [Wenbu · agent integrations](https://wenbu.app/agents/) · [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n- **done event**: The terminal event in the agent command's line-by-line JSON output; the turn has a definite ending only when its status is complete, waiting or limited. [Wenbu · agent integrations](https://wenbu.app/agents/)\n\n- **Backoff**: Waiting after a 429 before deciding whether to resend. The documentation requires backoff but states no specific wait duration or retry count. [Wenbu · agent integrations](https://wenbu.app/agents/)\n\n## Evidence notes\n\n- MCP successful results declare an outputSchema and return structuredContent, so isError should be checked before reading content. — “先检查 isError” (fact); [Wenbu · agent integrations](https://wenbu.app/agents/)\n\n- REST errors carry a stable code and a readable message, and 422 and 429 point to different investigations. — “错误包含稳定的 code 和用户可读消息” (fact); [Wenbu · agent integrations](https://wenbu.app/agents/)\n\n- Tarot draws are a documented random procedure, so results should be preserved rather than redrawn to reach a preferred answer. — “Keep the returned cards for follow-up” (editorial); [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json)\n\n## Sources\n\n- [Wenbu · agent integrations](https://wenbu.app/agents/) — Current first-party product documentation; fetched 2026-11-04T01:00:34.845Z; complete response\n\n- [Wenbu · versioned public capabilities](https://wenbu.app/capabilities.json) — First-party current tool, convention and privacy contract; not external endorsement or predictive validation; fetched 2026-11-04T01:00:34.853Z; complete response\n\n- [Wenbu · calculation conventions](https://wenbu.app/methodology/) — First-party implementation; not evidence of predictive accuracy; fetched 2026-11-04T01:00:34.850Z; complete response\n\n[Run CLI doctor to check connection and version](https://wenbu.app/en/agent/)","edition":{"title":"When an agent call fails, read the status and conventions before retrying","description":"A failed agent call tells you that something did not complete as agreed, not that the spread or chart is wrong. This guide uses a triage table to check the terminal status, then the input fields and stated conventions, before deciding whether to retry, fix the input or stop.","answer":"Read the terminal status first, the error message second, and the content last. MCP declares an outputSchema for successful results and returns structuredContent, so the first check is isError. REST errors carry a stable code and a readable message: 422 usually means an invalid field or moment, while 429 means short-term rate limiting or insufficient AI quota. For the agent command, inspect the status on the done event: complete means the turn finished, waiting means the user must add something, and limited means the budget is used up. An error, or a stream with no terminal event, is not completion; content already received may be kept, and retrying is the user's decision. Order matters: did the call succeed, do the fields fit the conventions, and does this failure touch randomness or metering? Correct the input only when the input is wrong, back off only when it is rate limiting, and never auto-retry an AI request that may already have been counted.","answerSourceIds":["agents","capabilities"],"evidence":[{"claim":"MCP successful results declare an outputSchema and return structuredContent, so isError should be checked before reading content.","sourceId":"agents","quote":"先检查 isError","kind":"fact"},{"claim":"REST errors carry a stable code and a readable message, and 422 and 429 point to different investigations.","sourceId":"agents","quote":"错误包含稳定的 code 和用户可读消息","kind":"fact"},{"claim":"Tarot draws are a documented random procedure, so results should be preserved rather than redrawn to reach a preferred answer.","sourceId":"capabilities","quote":"Keep the returned cards for follow-up","kind":"editorial"}],"takeaways":["Check the terminal status and isError before the message, and the message before judging content.","A 422-type error means check fields and moments; a 429-type error means back off. Do not merge them.","A broken stream and an error are both not completion; keep received content and let the user decide on retrying.","Random tarot and coin results should be preserved; a redraw is a new draw, not a repair.","An AI request that already started may be counted even if it fails, so do not build an automatic retry loop."],"sections":[{"heading":"Separate three kinds of failure: protocol, input, and unideal content","paragraphs":["The most common mistake when an agent call fails is to merge three situations: the protocol layer did not return success, the input did not fit the stated conventions, and the result came back but reads poorly. The first two are engineering problems; the third is an interpretation problem. MCP declares an outputSchema for successful results and returns structuredContent, so checking isError first isolates protocol-level trouble. REST endpoints return JSON on success, while errors carry a stable code and a readable message, which is enough to separate \"did not succeed\" from \"succeeded but I dislike it.\"","Unideal content is not an error. Tarot and online coin casting are drawn randomly by the program, and the page preserves the original result. Calculations can be reproduced under stated conventions, but that does not mean interpretations have been scientifically validated. So when a spread or hexagram does not match expectations, the right move is to keep the result and reframe the question, not to treat it as a failed call to retry. Writing \"the result was not to my liking\" into error handling turns retrying into repeated demands on a random outcome."],"sourceIds":["agents","methods"]},{"heading":"Input fields: four self-checks before you blame a 422","paragraphs":["A REST 422 usually means an invalid field or moment, so check the input against the conventions before changing code. Bazi needs a Gregorian date from 1901 to 2099, the local clock time at the birthplace, and either an IANA timezone name or an explicit UTC offset. Omitting the timezone falls back to Asia/Shanghai and returns a warning, which is \"runs but note it,\" not an error. The day boundary defaults to 00:00 and can optionally switch to the 23:00 Zi boundary; an unknown birth time omits the hour pillar and provisionally uses local noon for year and month, with an uncertainty note on solar-term days.","The second group to check is each tool's parameter shape. Each I Ching line takes 6, 7, 8 or 9, ordered bottom to top, with 6 and 9 as changing lines. Tarot accepts only 1 or 3 cards, drawn without replacement from a 78-card deck. Ziwei takes the Gregorian date and known clock time at the birthplace and does not convert timezones or correct solar time automatically. Read these fields as a contract: many \"failed calls\" could have been caught before the request went out, saving a request that might be metered."],"sourceIds":["agents","methods","capabilities"]},{"heading":"Rate limits and metering: what a 429 does and does not tell you","paragraphs":["Each network has a per-minute request limit, and the documentation says to back off on a 429. A 429 means short-term rate limiting or insufficient AI quota, and the error message tells you which. The documentation gives no reset time, backoff curve or retry count, so do not invent \"wait 60 seconds and try three times,\" and do not promise readers when quota will return. What you can do is read the message, decide whether to wait or stop, and tell the user honestly what happened.","Metering deserves more care. An AI request that has already started may be counted even if it fails, and the documentation explicitly says not to retry automatically. That flips the default direction of error handling: for pure calculation tools, resending after fixing the input is reasonable; for a request that already reached the AI stage, resending may consume quota again and should be the user's call. MCP calculations, the daily card and library reads do not invoke a model, so they should not be lumped in with the metering rules for AI requests."],"sourceIds":["agents","capabilities"]},{"heading":"Broken streams, waiting and limited: describe \"not finished\" precisely","paragraphs":["The agent command emits line-by-line JSON events, and you check the status on the final done event: complete means the turn finished, waiting means the user must add something, and limited means the budget is used up. An error, or a stream with no terminal event, is not completion; content already received may be kept, and retrying is the user's decision. The key is to keep four states apart: waiting is not a failure but missing information; limited is not a fault but a budget boundary; a broken stream is not an empty result but an interrupted transfer.","Wording should therefore be precise. \"This turn did not finish; here is what arrived; you decide whether to continue\" is more honest than \"the service failed, please retry,\" and it matches the documentation. If the status is waiting, the right action is to supply the missing context, such as the part of the material the user agrees to share. If the status is limited, say the budget is used up rather than rephrasing and sending again. Keeping received content on a broken stream also prevents users from thinking nothing happened."],"sourceIds":["agents"]}],"figure":{"title":"Triage flow for a failed call","caption":"Start from the terminal status, then check the protocol layer, the input layer and metering risk before deciding to retry, fix the input or stop. Each step uses only signals the documentation states, with no invented error codes or retry policies.","sourceIds":["agents","capabilities"],"steps":[{"label":"Read the terminal status","detail":"For MCP, check isError; for the agent command, check whether the done event status is complete, waiting, limited or error."},{"label":"Read the error message","detail":"REST errors carry a stable code and readable message; 422 points to a field or moment, 429 to rate limiting or insufficient quota."},{"label":"Check input conventions","detail":"Compare date range, timezone, day boundary, I Ching line values, tarot count and ziwei inputs against the published conventions."},{"label":"Assess metering risk","detail":"An AI request that already started may be counted even if it fails, so do not auto-retry; pure calculation tools can be resent after fixing input."},{"label":"Decide and report honestly","detail":"Fix input, back off, ask the user to add context, or keep received content and stop; do not promise when quota returns."}]},"table":{"title":"Triage table for five agent outcomes","columns":["Outcome","Check first","What it supports","What not to conclude"],"rows":[["Invalid field (422-type)","The field named in the error message; date range, timezone, day boundary, line values, tarot count","This request's input did not fit the published conventions","That the spread or chart is wrong, or the tool is unavailable"],["Rate limited or out of quota (429-type)","Whether the message names short-term limiting or insufficient AI quota; whether the AI stage has begun","You need to back off or stop, with the message as the guide","When quota returns or how many retries to make; the docs give no such numbers"],["Broken stream (no terminal event)","Whether a done event arrived; whether received content is complete","The turn did not finish, and received content may be kept","That the result is empty, or that you must resend immediately"],["Budget limited (limited)","The done event status and whether the user wants to continue","The turn's budget is used up and continuing is the user's choice","That the service is broken, or that rephrasing will bypass it"],["Successful but empty or unideal","isError and structuredContent; whether input was complete and the question clear","The call succeeded at the protocol level; the issue is interpretation or framing","That the random draw failed, or that you should redraw until satisfied"]],"sourceIds":["agents","capabilities"]},"example":{"title":"Hypothetical case: a tarot call that returned no reading","intro":"The following is a fictional situation for demonstrating triage order. It involves no real user data and is not an actual computed spread. Suppose a reader asks an agent for three tarot cards plus a reading, and the interface only shows \"something went wrong,\" with no cards.","steps":["First, look at the terminal signal rather than the content: for an MCP call, check isError and whether structuredContent came back; for the agent command, check whether a done event exists and what its status is. No terminal event means treat it as a broken stream, not an empty result.","Second, read the error message. If it points to a field, check whether the count was 1 or 3 and whether an extra parameter slipped in. If it points to rate limiting or quota, treat it as a 429 and back off, without inventing a retry count.","Third, decide whether the AI stage had begun. If generation had started, the request may be counted even on failure, so do not resend automatically; report the status and whatever arrived, and let the reader decide whether to continue.","Fourth, if the call actually succeeded and only the reading was empty or off-target, keep the returned cards and reframe the question or add context instead of redrawing. A redraw is a new random draw that may coincidentally repeat a card, but it cannot reproduce the previous result on demand."],"conclusion":"The conclusion is not \"the service is broken\" but \"confirm which layer did not finish.\" A protocol failure means fix the request; an input failure means fix the fields; a metering risk means hand the decision to the user; unideal content means keep the result and change the question. Four actions map to four kinds of evidence and cannot substitute for each other.","sourceIds":["agents","capabilities","methods"]},"faq":[{"question":"An MCP call returned content, but I am unsure whether it counts as success. What now?","answer":"Check isError first, then whether structuredContent came back with the declared outputSchema. MCP declares an outputSchema for successful results and returns structuredContent alongside text JSON, and the documentation puts the isError check first. If isError is true, the content is only an error message and should not be interpreted.","sourceIds":["agents","capabilities"]},{"question":"On a 429, can I just wait a bit and retry automatically?","answer":"The documentation only says each network has a per-minute request limit and to back off on a 429, noting that a 429 may be short-term limiting or insufficient AI quota and that the message should be read. It gives no reset time or retry count, so do not hard-code a wait. If the request already reached the AI stage, a failure may still be counted, which is another reason not to auto-retry.","sourceIds":["agents"]},{"question":"Is an agent saying \"not finished\" the same as an error?","answer":"Not exactly. The done event status has three values: complete, waiting and limited. Only complete means the turn finished; waiting means the user must add something, limited means the budget is used up, and neither of those is completion. An error, or a stream with no terminal event, is also not completion. Calling waiting a fault misleads users into retrying when the right action is to supply context.","sourceIds":["agents"]},{"question":"If I dislike the cards, can I redraw until I am satisfied?","answer":"Tarot draws 1 or 3 cards with equal probability from 78, without replacement within a single draw, and results should be kept for follow-up. A redraw is a new random procedure that may coincidentally repeat a card but cannot reproduce the previous result on demand. Treating a redraw as a repair hides the real issue, which is usually the question or the context.","sourceIds":["capabilities","methods"]}],"glossary":[{"term":"isError","definition":"The field in an MCP result marking whether the call failed. The documentation recommends checking it before reading structuredContent or the text JSON.","sourceIds":["agents"]},{"term":"structuredContent","definition":"The structured content returned with successful MCP results alongside outputSchema, so the host can read fields instead of guessing from free text.","sourceIds":["agents","capabilities"]},{"term":"done event","definition":"The terminal event in the agent command's line-by-line JSON output; the turn has a definite ending only when its status is complete, waiting or limited.","sourceIds":["agents"]},{"term":"Backoff","definition":"Waiting after a 429 before deciding whether to resend. The documentation requires backoff but states no specific wait duration or retry count.","sourceIds":["agents"]}],"cta":{"label":"Run CLI doctor to check connection and version","reason":"Before chasing a specific error, use the documented CLI doctor to confirm connection and version, which separates an environment problem from a request problem and avoids mistaking a configuration error for a tool fault."}},"editionScope":"full","sources":[{"id":"agents","title":"Wenbu · agent integrations","url":"https://wenbu.app/agents/","role":"Current first-party product documentation","fetchedAt":"2026-11-04T01:00:34.845Z","hash":"93a965358202f2256f2d430a517a7cc192c950b3e6f6157a242a234d3c24a7d8","truncated":false},{"id":"capabilities","title":"Wenbu · versioned public capabilities","url":"https://wenbu.app/capabilities.json","role":"First-party current tool, convention and privacy contract; not external endorsement or predictive validation","fetchedAt":"2026-11-04T01:00:34.853Z","hash":"557485b2f5513f237e8258ecf9d0a1fbbf5aa19a30c726f9199bf3817e021546","truncated":false},{"id":"methods","title":"Wenbu · calculation conventions","url":"https://wenbu.app/methodology/","role":"First-party implementation; not evidence of predictive accuracy","fetchedAt":"2026-11-04T01:00:34.850Z","hash":"5452dbc076e1c31aa334fa49949d682ad7851e75a5cf9396b6682530b30f0f0c","truncated":false}],"previousAdditions":[]}