Verify before you execute
Clawdbase is trust infrastructure for Agents, Skills, Creators and their source identities.
Clawdbase helps people and software evaluate an Agent or Skill before adoption, installation, delegation or execution. It joins canonical registry records with Trust and Confidence scores, source authentication and lineage context.
The decision model
Clawdbase does not replace code review, sandboxing, permission boundaries or your own policy. It supplies evidence at the point where a person, agent or workflow must decide what to do next.
- 1Resolve the canonical subject
- 2Read Trust and Confidence
- 3Inspect source and lineage
- 4Apply your own policy
Start with your job
Evaluate an Agent or Skill
Use the registry and T&C signals before adoption or execution.
Register a canonical Page
Authenticate through X, Telegram or GitHub. Handles are never accepted as ownership proof.
Build with Clawdbase
Create a scoped Access Key and run a metered trust operation.
Operate the Console
Manage Pages, connections, usage, billing and account security.
Get activated
- 1Sign up or connect GitHub
- 2Creator identity / Page prepared
- 3Create an Access Key
- 4Run the first Agent T&C operation
- 5Core activation complete
- 6Connect X or Telegram (optional)
- 7Register authorized Agent or Skill repositories (optional)
Six programmable operations
REST API is the available delivery channel for these operations and prices today. MCP is a planned delivery channel for the same operations — see MCP for its availability gate. The source of truth is shared with the Developer Access and Usage & Billing screens.
Returns Trust and Confidence outputs for a registered Agent.
agent_scoreReturns Trust and Confidence outputs for a registered Skill.
skill_scoreReturns lineage, associated creator identity and Creator T&C Score.
agent_skill_lineageReturns Trust and Confidence outputs for a creator identity.
creator_scoreReturns Trust and Confidence outputs for an X account.
x_account_scoreReturns Trust and Confidence outputs for a Telegram account, channel or bot.
telegram_account_scoreCanonical Pages
Registry Pages represent a canonical Agent, Skill, Creator, X account or Telegram identity. Registration starts from the provider, reads the provider's immutable identifier server-side, matches an existing Page or creates one, verifies control and starts scoring.
Initial automatic scoring after authenticated registration is not an API/MCP call. Later on-demand developer operations use the credit ledger.
Powered by inVerus
Clawdbase delegates scoring to inVerus and presents the returned evidence in the registry, Pages and developer workflows. Scores are computed from available evidence; owners cannot type or set their own score.
Choose the right surface
Use the public registry when you are evaluating an identity or artifact. Use the Console when you own Pages, connections, credentials or billing. Use the developer operation endpoint when a server-side workflow needs a fresh assessment at the moment of decision.
| Goal | Start here | Result |
|---|---|---|
| Inspect an Agent before execution | Registry search | Canonical Page, scores, source and lineage context |
| Register an identity you control | Page registration | Verified ownership and automatic initial scoring |
| Add a check to an application | Developer quickstart | Metered operation result and auditable ledger entry |
| Manage usage and account state | Console | Pages, connections, keys, billing and security controls |
A complete evaluation
Resolve the subject
Search for the exact Agent, Skill, Creator, X account or Telegram account. Confirm the public route, provider and source identifiers before reading a score.
Read both scores
Trust describes the evidence direction. Confidence describes how much weight that assessment can support. Keep missing, stale and pending values distinct from zero.
Inspect origin and relationships
For executable artifacts, follow the Creator and repository context. Request lineage when upstream relationships materially affect the decision.
Apply your policy
Combine Clawdbase evidence with permissions, sandboxing, code review, reversibility and the consequence of failure. Store the evidence and policy outcome separately.
Product guarantees
- A provider handle is never accepted as proof of ownership.
- One immutable provider identity resolves to one canonical Page.
- Page cards and public Pages read the same authoritative score source.
- Initial scoring after verified registration does not consume an API/MCP call.
- Paid developer operations reserve usage and reverse it when inVerus fails.
- Owners can manage presentation where entitled, but cannot edit verification or score facts.
Continue with Getting started, or open the API contract when you already know the subject you need to assess.