Run it automatically
The three places Saylent runs without you typing the command - a CI step, an agent, and your own code.
The command is one person at one terminal. These three are the same engine with nobody watching: a check on every push, a tool an agent can call, and the pipeline imported straight into your own program.
The GitHub Action
Fail a deploy that blocks the AI crawlers. $0, no keys, no LLM call, and a badge committed into your repo.
The MCP server
Four tools on stdio, so Claude Code, Claude Desktop or Cursor can audit, verify, gate-check and read a report itself.
Use it as a library
runAudit() from @saylent/engine and the renderers from @saylent/report - your own persistence, your own presentation.
Which one you want
| You want | Use | What it costs |
|---|---|---|
| CI to fail when a search or user-fetch bot gets blocked | the Action | $0 - it has no keys and calls no model |
| An agent to run the audit and read the result back | the MCP server | Your own credits: about $0.60 to $1.20 for a smoke run with four engines, $3.70 to $5.50 for a full one, checked against max_usd before anything is sent |
| The pipeline inside your own program, with your own database | @saylent/engine | Your own credits, at the same per-run cost |
| Your own presentation of a run you already have | @saylent/report | $0 - pure functions, no network |
| A re-check on a schedule, with no app deployed | a cron entry or a scheduled workflow | Your own credits, at the same per-run cost, once a month |
The Action and a scheduled saylent verify are different jobs and belong in
different workflows: the Action is the $0 gate that runs on every push, and a
verify spends real credits, so it goes on a schedule you chose.
They cannot drift
saylent audit's flags and the MCP audit tool's arguments are generated
from one shared schema, and a test fails the build if the argument table on
the MCP page stops listing every
field. The Action runs the same gate-check code the CLI does. Nothing here
is a second implementation.