Canonical: https://botbento.com/newsletters/weekly-field-notes-2026-10-09/ Format: Markdown representation of the public HTML page. [Home](/) / [Newsletter](/newsletters/) FIELD NOTES / 2 MIN READ # Weekly field notes: trace the run, then verify the boundary This week connects three live BotBento guides. OpenTelemetry traces help reconstruct a failed bot run, MCP Client ID Metadata Documents change how HTTP clients identify themselves, and Agent Skills metadata is not an enforcement boundary. Each topic has a different proof: trace events, negotiated registration behavior, and host-level tool permissions. By BotBento Editorial · Published 2026-10-09 · Updated 2026-10-09 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](/editorial/). ## In this article - [First, reconstruct the failed run](#follow-the-run) - [Next, identify the MCP client deliberately](#check-registration) - [Then, inspect the skill boundary](#permission-boundary) - [The public BotBento update](#botbento-update)[Read as Markdown ](/text/newsletters/weekly-field-notes-2026-10-09/index.md) ## Key takeaways - Record a stable run identifier across agent, model, and tool spans, then verify the intended outcome separately. - For MCP HTTP OAuth, inspect the server metadata and follow the released client-registration preference order; a client ID metadata URL is an identifier, not a secret. - Review third-party skill instructions and scripts, and enforce tool permissions in the host rather than treating experimental allowed-tools metadata as a sandbox. ## First, reconstruct the failed run Our tool-call tracing guide shows why a bot run needs a stable identifier across its agent, model, and tool operations. OpenTelemetry GenAI conventions describe spans and attributes for this work, but those conventions are still under development. Instrument the actual call boundaries your system owns and retain the error and timing evidence for each step. For a small exercise, make one test tool fail after an agent calls it. Confirm that the parent run and tool span can be correlated, then read back the destination the bot was meant to change. A complete trace can explain where execution stopped; it cannot by itself prove that a report was saved or a message reached a user. Sources: [OpenTelemetry GenAI spans](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/). ## Next, identify the MCP client deliberately Our MCP client-registration guide covers the 2026-07-28 HTTP OAuth revision. Dynamic Client Registration is deprecated. The released specification prefers existing pre-registered client information, then Client ID Metadata Documents when supported, then Dynamic Client Registration when supported, and finally asking the user for client information. Inspect the authorization server metadata and the client implementation you actually deploy. In a test environment, register the same bot through the mechanism your server advertises and record the client identifier it presents. A Client ID Metadata Document URL identifies the client and can be fetched for metadata; it is not a portable access token or a shared secret. Keep authorization and token validation as their own checks. Sources: [MCP 2026-07-28 client registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration). ## Then, inspect the skill boundary Our Agent Skills guide explains that SKILL.md can declare an allowed-tools field, but the open specification marks it experimental and host implementations vary. Read the instruction body and any scripts before installing a third-party skill. Decide what tools and destinations the host will actually permit independently of what the skill says about itself. Try a harmless local skill that asks to read a file outside its task. Verify that your host denies the call when the tool permission is absent. If the call succeeds, change the host configuration or connection scope; editing metadata alone does not establish the boundary. Sources: [Agent Skills specification](https://agentskills.io/specification). ## The public BotBento update The three linked guides are live in the BotBento blog. Together they offer a practical sequence: trace the run, check how the client is registered, and verify who can call each tool. They describe patterns an operator can test in their own system. BotBento remains a pre-release workspace. This public archive does not claim that BotBento runtime monitoring, MCP connections, or skill permission controls are generally available. Newsletter email goes only to confirmed subscribers after the archive is deployed and its private delivery checks pass. ## Primary sources Sources checked 2026-10-09. Standards and product documentation can change; follow the linked version when implementing. - [OpenTelemetry GenAI spans](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/) — OpenTelemetry - [MCP 2026-07-28 client registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration) — Model Context Protocol - [Agent Skills specification](https://agentskills.io/specification) — Agent Skills BotBento is in development. [Suggest a correction](/contact/). ## Keep reading - [How Do You Trace a Bot's Tool Calls to Debug a Failed Run?](/blog/bot-tool-call-tracing-otel/) - [MCP Deprecated Dynamic Client Registration. What Should Your Bot Use Now?](/blog/mcp-client-registration-cimd-vs-dcr/) - [Agent Skills' allowed-tools Field Won't Sandbox a Skill by Itself](/blog/agent-skills-allowed-tools-is-not-a-sandbox/)