Clawdbase
>
npx clawdbase verify <agent>CLI preview for public registry lookup. REST is the developer contract.
Documentation
DevelopersOperations

Operations

The canonical Clawdbase trust primitives, prices and required scopes.

Operation IDs, credits and scopes are imported by the Console, billing UI, operation route and these visual cards from one source of truth. Changing an operation requires updating that shared constant and the operation-specific behavior, not duplicating display values in multiple components.

OperationCreditsScope
agent_score10scores:read
creator_score8scores:read
skill_score8scores:read
agent_skill_lineage20lineage:read
x_account_score5scores:read
telegram_account_score5scores:read

Shared request envelope

All operations use POST /api/clawdbase/operations/run with a bearer credential, subject, channel and idempotency key.

{
  "operation": "agent_score",
  "subject": "owner/repository",
  "channel": "api",
  "idempotency_key": "job-123:agent_score:owner-repository"
}

channel defaults to api, the only executable channel. channel: "mcp" is rejected with mcp_not_available before reservation or scoring — no credits are charged and no ledger entry is created. MCP is planned and not available until a public transport is separately deployed and verified.

Shared response envelope

A settled success includes ok, operation, channel, the raw inVerus result, ledger_id, charge_source, balance_after and settled. The exact evidence inside result follows the deployed inVerus response; do not fabricate a normalized schema in client code.

Billing behavior

The displayed credit price applies after free-call accounting. A successful Free allowance request consumes one call, regardless of operation price. Paid sources consume 5, 8, 10 or 20 credits according to the canonical constant. Upstream failure reverses the reservation.

Subject resolution

Use the most specific stable subject available: canonical Page ID or immutable source identifier when supported, otherwise the exact owner/repository or handle expected by the resolver. A subject string locates evidence; it does not prove ownership.

Production requirements

  • Authenticate from trusted server code.
  • Grant only the operation's required scope.
  • Persist one idempotency key per logical evaluation.
  • Apply a timeout slightly above the server bound.
  • Store ledger ID with your policy outcome.
  • Handle missing or partial evidence explicitly.
  • Keep Agent, Skill, Creator, X and Telegram scores on their own subject records.

Open an operation page for its intended decision context and examples.