connect

connect — link this repo to evals.tessary.ai and load its tools

This is the front door to the Tessary evals platform for a coding agent. It does four things and then gets out of the way:

1. Link this repo to a project (a one-time device-code handshake in the browser).

2. Detect whether this repo already emits OpenTelemetry and, if so, wire its OTLP export to the project (point it at POST /v1/traces with the link token). OTLP is the only supported ingestion path. This is the "detect the setup in the project and wire it to tessary" step.

3. Register the platform's authenticated MCP server into Claude Code (privately, per-repo) so you — the coding agent — get native tools. Every one of them reads; there is no write, nothing that spends, and nothing that starts an agent run. Roughly: get_project (what this token is bound to, plus whether anything is arriving at all), list_cases / get_case (what is wrong right now — and get_case carries the root-cause report inline once one has finished), list_findings / get_finding (classifier drift), list_call_sites / list_failure_modes / list_quality_dimensions (the imported taxonomy), list_traces / get_trace, list_spans / get_span, list_sessions / get_session (find the traffic, then read it — the get_* half is where the raw conversation text lives), describe_dataset plus query_count / query_timeseries / query_facets / query_search (aggregates over tool calls, classifier events and usage rollups), and list_graders / get_grader where the org holds the graders capability.

   Do not treat that as a fixed list — read tools/list and report what it actually returns. That instruction is the durable part of this step; the paragraph above it is a hint about shape and it will drift again. Every tool declares a capability the org must hold to be offered it, so the real catalogue is per-token and shorter for most projects; a tool the org does not hold reads as an unknown tool, not a permission error. Naming tools from memory is how this skill spent two releases telling the agent to call a tool that had become a no-op while never mentioning get_span / get_trace — and then, one release later, still named five triage and RCA tools the platform had deleted. Twice now the prose was wrong and tools/list was right.

   If the user asks for something no offered tool answers, say so — do not reach for a name you remember. Concretely: starting a triage run and editing a grader are not tools, by design. Those are platform UI actions; your part is to read the result afterwards (a finished report arrives inline on get_case).

4. Report what's in the project so the user knows what they can do next.

After this, the user assesses call sites by talking to you — you call the platform tools directly. No local synthesis pipeline, no Python per read. The .tessary/ bundle itself is authored and maintained by the platform's observer: once tagged traffic is flowing and the repo is connected on the platform (Settings → Git integration), the observer reads the code on the org's schedule and proposes the bundle — call sites, failure modes, grader definitions — as a draft PR the user reviews and merges. There is no local bootstrap step anymore.