Skip to main content
Two tools return the bytes a marked function actually saw. vexlo_get_values fetches named slots on named steps of one trace. vexlo_get_function_examples fetches up to five real executions of one function. Reach them with a path from vexlo_get_trace or a name from find, and only where a preview looks worth reading in full. Every response below comes from the seeded server find describes: the spec’s conformance trace on team fixture, with one three-attempt step.

vexlo_get_values

A path is a step’s identity and is opaque. Copy it verbatim from vexlo_get_trace: never construct, decode, or guess one. The path ceiling is the API’s own hard limit, read from the server’s limits rather than hardcoded, so the tool’s description always carries the number that field reports. Call again for more paths. Omitting slots returns every slot the step has, so a step with no error slot has none to return. The root step’s path is the empty string, which is a real path:
value is always a string, and encoding says how to read it: json is canonical JSON text to parse, text the captured string itself, base64 binary bytes to decode first. state and the presence of value are independent. A slot reads state: "pending" and still carries a real value, as the step below does, when the value record shipped in the same batch as the shape before this trace’s sampling fate was settled, and reads state: "pending" with no value when nothing has shipped yet. Branch on whether value is present, never on the state string:
state is an open string: the nine states conventions documents are what the server emits today, and an unrecognised one passes through rather than failing the call. Three mean the bytes never existed, so asking again cannot produce them: redacted, too_large, and not_captured. A slot that resolves to expired at read time arrives with path, slot, and state only (traces); a value record that never shipped reads expired too, not missing. A path that matches no step in the trace is not an error. It comes back in unknown_paths, in the server’s canonical spelling. Count its entries rather than matching them to what you sent: a mistyped path is named as what it decoded to. Here AAZZZZZ was asked for alongside a real path and came back as AAZZZZY:
A third answer is neither: no entries, and the path absent from unknown_paths too. Read that as a path the trace has with no slot to read only for a path vexlo_get_trace returned in steps; for any other string it is as likely a path this trace never had. Two situations produce it, a step whose attempts are all still in flight and a completed attempt that captured no slot, so read the attempt’s own status in vexlo_get_trace to tell them apart. Neither is state: "not_captured", which is a slot that is present and says so. A retried step returns one entry per attempt, each with the same path and slot, in attempt order. Nothing names the attempt, so the only way to pair entries with attempts is the order vexlo_get_trace lists them in. This step failed three times with the same error:
Cost tracks the bytes captured, not the number of paths asked for. Over the one-line text each call returned, of which the blocks above are jq . renderings, the root’s two slots are 444 bytes and 121 tokens, one step’s two slots 396 bytes and 113 tokens, the three error entries above 859 bytes and 234 tokens, and the root plus the first seven steps in path order, eight paths in one call, 2,788 bytes and 806 tokens.

vexlo_get_function_examples

Returns up to five real executions of one function: the trace id, the path, the attempt, when it ran, whether it succeeded, and a preview of its input and output. team and environment are as find defines them: environment takes {"named": [...]} or {"unset": true} and nothing else. There is no cursor. The function index keeps at most five example ids per (service, name), combined across every environment the function has run in, so asking again returns the same five. team and environment filter those five, never a wider pool. started_at is when the example was ingested, not when the trace ran, which functions explains.
includeValues: true replaces every example’s preview with its complete stored value, the only widening parameter in the read surface. The preview response above is 466 bytes and 158 tokens, the widened one 525 bytes and 179 tokens: the same example with its 116-byte input in full rather than 64 code points of it.
A handle carries preview or value, never both: the widened form drops the preview. The output slot above reads not_captured because this tool rewrote it. The route renders a slot the example does not carry as the zero value of its handle type, an empty state that is not one of the documented states:
The tool maps that empty string to not_captured, and its description tells an AI agent to read an absent input or output key the same way: this attempt carried no such slot. The mapping is a workaround, not a promise: the same empty state appears on a successful attempt as on this failed one. The API’s other two routes leave an absent slot out entirely, as the spec’s conformance case requires.