Exa

Purpose

Exa AI search (neural web search) with the user-connected custom.exa
credential. Four agent tools: search, contents, find-similar, answer.

Tooling

exa.py search <query> [--n N] [--type auto|neural|keyword] [--livecrawl always|fallback|never] [--chars N]
exa.py contents <url>... [--chars N]
exa.py find-similar <url> [--n N]
exa.py answer <query>

Output is JSON on stdout. Every call is appended to
~/.cache/shingle/exa_calls.jsonl (endpoint, elapsed_ms, ok, cost_usd) for
cost tracking.

Auth

The credential is already stored; nothing here collects one. Resolve auth
through the skill's connection flow — credential values never enter chat,
secret environment variables, secret flags, or auth files. Only the hsurr:* surrogate is sent,
and only to api.exa.ai; authd substitutes the real key at egress.

A 401 or 403 is a question about the request before it is a question about
the key. Check that the credential was attached at all: a request built
without the helpers carries nothing, and that looks exactly like a wrong or
under-scoped token. Only once a request that did carry the credential is
still rejected, call credentials.request_api_access with reconnect to
replace it. The connector is stored as custom.exa.

Operating Rules

1. Use this skill when the user asks for Exa or neural web search.
2. Restrict authenticated requests to: api.exa.ai.
3. Do not print, log, or persist raw credentials.
4. If auth is missing or rejected, follow the Auth section rather than asking for a key.
5. Note: yote (the bridge box) has no credential broker — the vault
   credential only works from this cell. Yote's awrawr_mcp.py carries
   exa_* tools too, but they need a key file provisioned operator-side at
   ~/.config/exa/api_key (mode 600).