> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vexlo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Use execution data

> Choose runtime evidence, follow recorded behavior and connect it to the agent's task.

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](https://docs.vexlo.ai/agents/connect.md) to your instance. The examples below use a recorded
checkout from [Follow an investigation](https://docs.vexlo.ai/guides/investigation.md). 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`.

| Starting context | First read | What to establish |
| - | - | - |
| A trace ID | `vexlo_get_trace` | Its recorded calls, attempts, timing and previews. Use `vexlo_check_trace_status` when only its current status is needed. |
| A recorded request or business identifier | `vexlo_search_traces` with `tagValue`; add `tagKey` when known | Which recorded execution matches the identifier. |
| A function and service | `vexlo_get_function` | Its observed callers and callees. Use `vexlo_get_function_examples` for retained calls. |
| A service, symptom or time window | `vexlo_search_traces` | Relevant executions, narrowed by the available status, duration, function and time filters. |
| Unknown recorded names | `vexlo_check_coverage`, `vexlo_list_functions` or `vexlo_list_tags` | Which service, function or tag names have been observed. |

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`:

```json theme={"system"}
{"service":["checkout-investigation"],"tagKey":"order_id","tagValue":"order-1042","limit":1}
```

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`:

```json theme={"system"}
{"traceId":"e2b8215fb046214bf8844325d21f2c8e","path":["AABAAAI"],"slots":["input","output"]}
```

The decoded data was:

```json theme={"system"}
{
  "input": {
    "customer": {
      "customer_id": "customer-17",
      "loyalty_member": true
    },
    "subtotal_cents": 3300
  },
  "output": 0
}
```

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](https://docs.vexlo.ai/guides/investigation.md#match-the-recording-to-source) 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](https://docs.vexlo.ai/reference/mcp.md#retrieve-selected-values) 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:

| Read | UTF-8 bytes | Reference tokens |
| - | - | - |
| Search for the order | 599 | 204 |
| Read the fourteen-call graph | 8481 | 2319 |
| Read the discount input and output | 358 | 97 |

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.