Skip to main content
An agent can use Vexlo to establish what code received, which calls ran and what they returned. That evidence becomes working context for the task: follow a calculation, understand a dependency, examine an unfamiliar input or determine what to inspect next. First connect the agent to your instance. The examples below use a recorded checkout from Follow an investigation. For your own work, use service names and identifiers from your instance; the example’s trace ID identifies its captured run.

​
Start with the context you have

A recorded business identifier, such as an order ID, is searched as a tag value. A Vexlo trace_id identifies one recording; MCP tool arguments call it traceId. Keep service, environment and team scope aligned with the task. Copy exact function names from returned name fields; function filters do not support substring matching. Read any scope_note: requesting a team outside the read token’s access cannot widen the query. An empty scoped result does not establish that the application performed no work.

​
Follow the recorded operation

In the checkout example, the task supplied an order identifier and an unexpected total. Search for that order with vexlo_search_traces:
The result included trace_id: "e2b8215fb046214bf8844325d21f2c8e", the service and an app_revision tag. Its root_status was ok and its completeness was complete. The entry point returned normally and the server reported the recording as complete; neither establishes that the total was correct. Pass the returned ID as traceId to vexlo_get_trace. Follow parent relationships to the branch relevant to the question. Here, checkout called price_order, which called discount_for and tax_for. Successful calls mattered: the discount function returned normally while producing the unexpected value. A trace response is a page, not necessarily the entire graph. Follow next_cursor until null, and compare distinct recorded paths with the newest step_count. If they disagree, restart the walk without a cursor. Records arriving during the walk can change the graph. Keep that limit in mind before interpreting an absent call. Use each call’s attempts and previews to decide where more data is needed. An earlier error can be followed by a successful retry, while a successful helper can explain an incorrect result. Preserve attempt identity when discussing retries: vexlo_get_values selects paths and slots, not numbered attempts, so repeated returned values from that tool cannot be assigned to retry numbers by position.

​
Read the data that answers the next question

Copy paths from the graph rather than constructing them. In this recording, the discount call’s path was AABAAAI. Request its arguments and return value with vexlo_get_values:
The decoded data was:
The recording establishes that the membership flag reached this call and that it returned zero. Explaining why requires the pricing rule and the corresponding source. The investigation connects those facts to the helper’s field lookup. In tool results, value is a string: decode it according to encoding. Check whether a value is present and whether the capture was truncated before treating it as a complete input case. A readable zero-length payload omits value and bytes_count, but retains encoding and truncated. A preview can exist without readable full bytes. See MCP tools for availability and attempt-selection limits.

​
Budget context with progressive disclosure

Vexlo’s MCP tools support progressive disclosure: search returns summaries, graph reads add calls and previews, and value reads retrieve selected payloads. Let the evidence determine which read comes next. Narrow a search before increasing its result limit, and inspect the graph before loading every available input and output. For this checkout, the three reads returned these exact payload sizes, measured with tiktoken 0.14.0 and cl100k_base as an explicit reference encoding: These measurements count only the exact JSON text inside each MCP result. They exclude tool schemas, prompts, arguments, reasoning and other host context, and are not Claude billing-token counts. Function examples follow the same principle: read previews first, then set includeValues when full retained examples are needed. Full payload size depends on the selected values. Choose enough data to answer the question without filling the working context with unrelated payloads.

​
Connect execution evidence to the task

Move between an individual recording and observed function relationships as needed. vexlo_get_function can identify callers and callees worth inspecting; retained examples provide concrete calls whose trace_id opens their surrounding execution. For a shared business identifier across services, vexlo_find_related_traces finds recordings sharing tags. Shared tags relate records; they do not prove a cross-service call edge. For example, the function-usage recording shows order_service.checkout calling order_service.price_order, whose observed callees include order_service.price_lines, order_service.discount_for and order_service.tax_for. To understand where pricing inputs come from, follow the caller. To examine their transformation, follow the relevant callee and open an example execution. Match the application’s recorded revision before attributing behavior to the current checkout. In the checkout investigation, the agent compared recorded inputs with supplied source and identified a mismatched field name. It proposed the field correction; a regression test and a corrected recording verified that input case. Vexlo’s MCP tools read execution data. Editing code or running tests requires the host’s other tools. Report the recording’s facts separately from an interpretation or a proposed change, and identify which later checks were actually performed. Observed callers and retained examples inform the task; they do not establish all possible dependencies or inputs.