Agent skill · software engineering · jeremylongshore
exa-install-auth
Configure an Exa client without leaking credentials or mixing API-key, MCP OAuth, enterprise managed authorization, and payment-protocol trust models. Use when operating or reviewing this Exa boundary. Trigger with "Exa install auth", "review Exa install auth", or "fix Exa install auth".
Why this skill is useful
Adds installation scripts and configuration steps for the Exa SDK that are not commonly known or documented publicly.
What it needs
Requires npm, pip installed locally. Requires exa account access. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Exa Authentication and Installation Boundary Overview Configure an Exa client without leaking credentials or mixing API-key, MCP OAuth, enterprise managed authorization, and payment-protocol trust models. Treat credentials, queries, retrieved content, generated output, spend, and destructive state as separately governed boundaries. Prerequisites The target repository, environment, Exa team, product surface, and accountable owner. The workload's data classification, latency and freshness promise, cost ceiling, and retention policy. Current first-party documentation plus credentials only for a narrowly approved live check. Current Contract The public REST API uses the Exa API host and an Authorization Bearer header. SDKs can read EXAAPIKEY. Team Management uses a separately enabled service key against the admin API; hosted MCP normally uses OAuth, while enterprise managed authorization currently requires an eligible Exa organization, Claude organization, and Okta setup. Authentication For normal REST work, inject EXAAPIKEY from an approved server-side secret manager and send it only as Authorization: Bearer to the configured first-party Exa API host. Team Management service keys, hosted MCP OAuth or enterprise managed authorization, and payment-protocol calls are separate trust models. Never print, commit, place in a URL, or expose a credential to an untrusted client. Instructions 1. Inventory the runtime, endpoint family, team, environment, and data class. 2. Choose exactly one supported authentication model for that boundary. 3. Place the credential in the approved secret manager and inject it only at runtime. 4. Pin the current SDK or raw-HTTP contract and validate configuration offline. 5. Run a synthetic read-only smoke check only when live access and spend are approved. 6. Record credential owner, scope, rotation path, test result, and rollback state. Tool Discipline Use Read, Glob, and Grep to inspect repository code, configuration, fixtures, and evidence. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/exa-install-auth--f98a0a