Weekly field notes: recover a bot without guessing
Two changes call for the same habit: identify who owns the action, preserve evidence, and make the next step explicit. This issue links the week’s MCP and retry guides and offers a short review exercise.
AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. Editorial policy.
Key takeaways
- MCP Sampling and Roots are deprecated, but the specification keeps each for at least twelve months before removal eligibility.
- A rate limit may arrive as HTTP 429 or as an MCP tool execution error; inspect the actual signal before retrying.
- For an uncertain write, check for an idempotency guarantee or read back the result before trying again.
Know which side owns the next model call
Our guide to MCP Sampling explains the 2026-07-28 deprecation and what it means when a server has been asking a client to run model generations. The specification says new implementations should avoid Sampling and existing integrations should plan direct provider access. It also deprecates Roots, the client’s list of relevant filesystem locations. These changes are not a signal to remove approval or permission checks: Roots was always guidance, not an access-control boundary.
Try a five-minute inventory for one connected server. Does your client advertise Sampling or Roots? Does the server actually request either feature? If the server will call a model directly, who will own its provider account, data handling, and review path? If it will receive file paths another way, where are filesystem permissions enforced? The answers turn a protocol announcement into a concrete migration plan.
Sources: Sampling - Model Context Protocol, Roots - Model Context Protocol.
Retry at the right layer, with a stopping point
Our rate-limit guide separates HTTP 429 from an MCP tool result marked isError. The MCP Tools specification also distinguishes a tool execution error from a JSON-RPC protocol error. A bot that collapses all three into “the connection broke” may retry malformed arguments or lose the provider’s wait instruction. An HTTP 429 may include Retry-After, but that header is optional, so the bot needs both provider-specific guidance and a bounded fallback.
Here is a small exercise for the next routine you automate. Write down the tool call, whether it reads or writes, the exact rate-limit signal, the allowed wait, and the retry cap. Then add one line for the uncertain case: if the call timed out after a write, how will you tell whether it already succeeded? A safe answer may be an idempotency key or a readback query. Without one, report uncertainty rather than silently repeating the write.
Sources: Tools - Model Context Protocol, 429 Too Many Requests - HTTP | MDN.
The public guides this week
You can read the full articles on the BotBento blog: “MCP Sampling Is Deprecated. What Should Bot Builders Do Now?”, “How Should an AI Bot Handle a Tool’s Rate Limit Error?”, and “Agent Tool Retries Need Idempotency Keys.” Each gives a different angle on the same operational question: what evidence makes the next action safe?
BotBento remains in development. The articles and this archive are educational material, not a claim that a finished bot runtime, automated run record, or provider integration is available. Newsletter email is a separate confirmed-subscription channel; publishing this archive alone does not mean an email was delivered.
Primary sources
Sources checked 2026-09-25. Standards and product documentation can change; follow the linked version when implementing.
- Sampling - Model Context Protocol — Model Context Protocol
- Roots - Model Context Protocol — Model Context Protocol
- Tools - Model Context Protocol — Model Context Protocol
- 429 Too Many Requests - HTTP | MDN — MDN Web Docs
BotBento is in development. Suggest a correction.