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.
Wenbu · agent integrations ↗Wenbu · versioned public capabilities ↗
- 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.
Triage flow for a failed call
- 01Read the terminal status
For MCP, check isError; for the agent command, check whether the done event status is complete, waiting, limited or error.
- 02Read 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.
- 03Check input conventions
Compare date range, timezone, day boundary, I Ching line values, tarot count and ziwei inputs against the published conventions.
- 04Assess 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.
- 05Decide 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.
Wenbu · agent integrations ↗Wenbu · versioned public capabilities ↗
Separate three kinds of failure: protocol, input, and unideal content
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.
Wenbu · agent integrations ↗Wenbu · calculation conventions ↗
Input fields: four self-checks before you blame a 422
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.
Wenbu · agent integrations ↗Wenbu · calculation conventions ↗Wenbu · versioned public capabilities ↗
Rate limits and metering: what a 429 does and does not tell you
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.
Wenbu · agent integrations ↗Wenbu · versioned public capabilities ↗
Broken streams, waiting and limited: describe "not finished" precisely
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.
| Outcome | Check first | What it supports | What not to conclude |
|---|---|---|---|
| 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 |
Wenbu · agent integrations ↗Wenbu · versioned public capabilities ↗
Hypothetical case: a tarot call that returned no reading
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.
- 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.
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.
Wenbu · agent integrations ↗Wenbu · versioned public capabilities ↗Wenbu · calculation conventions ↗
Questions you may have
An MCP call returned content, but I am unsure whether it counts as success. What now?
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.
Wenbu · agent integrations ↗Wenbu · versioned public capabilities ↗
On a 429, can I just wait a bit and retry automatically?
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.
Is an agent saying "not finished" the same as an error?
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.
If I dislike the cards, can I redraw until I am satisfied?
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.
Wenbu · versioned public capabilities ↗Wenbu · calculation conventions ↗
Terms in this guide
- isError
- The field in an MCP result marking whether the call failed. The documentation recommends checking it before reading structuredContent or the text JSON.
- 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 ↗Wenbu · versioned public capabilities ↗
- 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.
- Backoff
- Waiting after a 429 before deciding whether to resend. The documentation requires backoff but states no specific wait duration or retry count.
See the claim and source notes
MCP successful results declare an outputSchema and return structuredContent, so isError should be checked before reading content.
先检查 isError
REST errors carry a stable code and a readable message, and 422 and 429 point to different investigations.
错误包含稳定的 code 和用户可读消息
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
Sources and review scope
This AI-assisted Wenbu article passed automated structure checks and a separate editorial model pass. It is not independent expert review or a paid-account product test.
- Wenbu · agent integrations ↗Current first-party product documentation · 2026-11-04 · Fetched text
- Wenbu · versioned public capabilities ↗First-party current tool, convention and privacy contract; not external endorsement or predictive validation · 2026-11-04 · Fetched text
- Wenbu · calculation conventions ↗First-party implementation; not evidence of predictive accuracy · 2026-11-04 · Fetched text
Run CLI doctor to check connection and version
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.
Run CLI doctor to check connection and version ↗