Build from local source

Generate an API collection and draft consumer MCP from a local working tree, including changes that have not been committed. This workflow sends selected source files to Elva for AI analysis.

Choose the source and consumer

 
elva auth login
elva --path ./services/orders \
  --prompt "Create a read-only partner API for order lookup and shipment tracking. Exclude internal notes." \
  --audience partner --auth-type bearer \
  --api-base-url https://api.example.com

Run this in your checkout and replace the path and example URL with your service's real values. No GitHub remote or existing API specification is required. Without --path, the CLI starts at the nearest Git root, or the current directory when there is no Git repository.

Review the upload summary and confirm the selected files. --yes accepts the upload and requested draft creation, so use it only after reviewing the scope.

Control what is uploaded

Use .elvaignore to exclude files from this workflow. Git ignore rules, including local and global rules, also apply; a Git include rule cannot override an .elvaignore exclusion. The collector skips dotfiles, symlinks, dependency and build directories, test fixtures, and known secret files, and restricts the source file types it accepts.

Embedded-secret detection is a heuristic. Review the selected source and exclude confidential files before uploading. Source goes to Elva AI; resulting API specifications and collections are retained. Saved plans do not contain the raw source snapshot, but their schemas and examples can still be sensitive.

An oversized snapshot is rejected rather than silently truncated. Narrow --path for large repositories or services hosted at different base URLs.

Review the generated resources

Treat inferred endpoints and fields as a proposal. Check completeness, consumer-facing names, response schemas, the upstream URL, and authentication. Bearer is the default. For an API key, use --auth-type api_key and --api-key-header; use --auth-type none only for an intentionally public upstream.

The audience can be partner, public, or internal. It describes the intended consumer; the upstream API still enforces permissions and tenant boundaries. Generated contracts and MCPs are drafts until you publish the contract.

Resume and publish

 
elva --resume JOB_ID
elva --json contract show CONTRACT_ID
elva --yes contract publish CONTRACT_ID

Save the job and resource IDs printed by the CLI. --resume can wait for a running job, supply missing input such as the base URL, or retry planning from collections already created. It preserves the original source, name, audience, and authentication settings.

A failed scan that created no collections requires a new upload because the raw source is not retained for resuming. If draft application fails after a plan was saved, use apply with the printed plan file. Once a job ID exists, resume it instead of starting duplicate jobs.

For automation, add --json for the success result and inspect stderr for progress or errors. Keep the command's exit status: not every command emits failures as JSON. Use elva --json schema to inspect supported input and output shapes.