Recent updates to Model Context Protocol (MCP) servers now include two practical changes: servers can embed guidance about what they just did and what to do next, and they can accept a session‑ID (and optional prompt summary) that lets callers stitch individual tool invocations into a single observable journey. Engineers care because the changes turn a stateless data fetch into a traceable conversation, making it possible to measure tool effectiveness and iterate on agent behavior.
Why Guidance Matters for Agents
Previously, an agent would request a piece of data and the MCP server would simply return it, acting like a traditional database API. James Ward of AWS argues that the server should act as another participant in the dialogue, returning not only the data but also metadata that tells the agent what operation was performed, a suggestion for the next step, and a pointer to additional resources. This conversational cue helps agents decide whether to continue fetching single records, switch to a batch operation, or invoke a different tool.
Implementing Session Tracing
The default MCP protocol lacks a built‑in trace identifier. AWS’s low‑tech workaround adds a session_id parameter to each tool definition and requires the agent to propagate it on every call. A second optional parameter can carry the original user prompt or a concise goal summary. By logging these values, teams can reconstruct the full request path, compare the user’s intent with the actual sequence of tool calls, and quantify task‑completion rates.
Operational Impact and Tool Design
Internally, AWS built this tracing and guidance layer for its own MCP servers, opened the MCP Server to external users in May, and introduced Lambda‑based diagnostics in September. Practitioners should consider the following implications:
- Interface changes: Tool contracts now need to accept
session_idand optional goal metadata. - Observability pipelines: Logs or metrics must capture the guidance payloads and session identifiers to enable end‑to‑end tracing.
- Evaluation loops: Teams can run automated evals that compare the intended user goal against the observed tool chain, then adjust tool descriptions or add batch operations where patterns emerge (e.g., single‑record fetches turning into batch tools).
- Alternative access methods: AWS also offers a CLI and skill‑based access; the MCP OAuth model does not toggle between AWS profiles as the CLI does, so the choice of interface may affect workflow ergonomics.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Adopt the session‑ID pattern on any MCP‑backed tool you expose, and capture the guidance metadata returned by the server. Use the collected traces to build simple evals that surface inefficient call patterns, such as repeated single‑record fetches, and iterate on tool design accordingly. Keep an eye on the Lambda diagnostics feature for deeper runtime insight, and compare MCP’s OAuth‑based access with the AWS CLI when profile switching is required. By treating the agent‑tool interaction as an observable conversation, you gain the data needed to improve reliability, performance, and security of your AI‑driven workflows.