Tenzro
Agents

Skills.

Built-in skill registry. Skills are named capabilities discoverable through the SDK and the desktop app.
STATUS
Testnet
CRATE
tenzro-node
STABILITY
Stable
TYPE
Component
01

In-process built-ins

Skills on the builtin:// scheme run inside the node that serves them. No outbound MCP hop.

web-search             builtin://web-search
code-review            builtin://code-review
data-analysis          builtin://data-analysis
text-summarization     builtin://text-summarization
blockchain-query       builtin://blockchain-query
oneinch-aggregator     builtin://oneinch-aggregator
tenzro-trainer         builtin://tenzro-trainer
02

Remote built-ins

The rest of the built-in set points at an MCP endpoint and is invoked over Streamable HTTP.

solana-defi            https://solana-mcp.tenzro.xyz/mcp
ethereum-defi          https://ethereum-mcp.tenzro.xyz/mcp
canton-enterprise      https://canton-mcp.tenzro.xyz/mcp
layerzero-bridge       https://layerzero-mcp.tenzro.xyz/mcp
chainlink-oracle       https://chainlink-mcp.tenzro.xyz/mcp
debridge-cross-chain   https://agents.debridge.com/mcp
openclaw-tenzro        https://mcp.tenzro.xyz/mcp
03

Inputs

code-review, data-analysis and text-summarization take text and route through intent-based model selection — the caller names an outcome, not a model. They also forward budget, optimize, quality_floor, max_tokens and temperature when present.

# web-search
{ "query": "...", "limit": 10, "categories": "news", "language": "en" }

# blockchain-query
{ "operation": "balance", "address": "0x..." }
# operation: balance | nonce | block | transaction | block_number | status

# oneinch-aggregator
{ "operation": "quote", "src": "0x...", "dst": "0x...", "amount": "1000000" }
# operation: quote | swap | tokens | liquidity_sources
#            approve_spender | approve_transaction | approve_allowance

# tenzro-trainer
{ "operation": "list_runs" }
# operation: post_task | list_runs | get_run | get_receipt | enroll_trainer
#            submit_gradient | finalize_round | decide_round
#            challenge_commitment | install_sealed_manifest | get_sealed_manifest
04

Operator upstreams

Two built-ins call a third-party API with the operator's own credential. A node that has not configured the upstream does not register the skill, so discovery lists only what that node can serve.

[builtins]
# SearXNG-compatible JSON search endpoint, backs web-search
search_url = "https://search.example.org"
search_api_key = "..."          # optional bearer token

# 1inch Developer Portal key, backs oneinch-aggregator
oneinch_api_key = "..."
05

CLI

tenzro skill list
tenzro skill list --bundled-only
tenzro skill search retrieval
tenzro skill get <skill_id>
tenzro skill use <skill_id> --input '{"query":"..."}'
tenzro skill register --name summarize --description "Summarize a document" \
  --capabilities nlp --creator-did did:tenzro:human:... \
  --endpoint https://skills.example.org/summarize
06

Custom skills

A published skill takes one of two forms. An endpoint skill names an HTTP, MCP, or A2A URL, and the node calls it — the publisher or the operator hosts the code. A bundled skill ships a content-addressed WASI 0.2 component instead, and the node runs it. Creator DID is did:tenzro:system:tenzro-network for built-ins; user-owned skills carry the registering identity.

# endpoint form
{ "endpoint": "https://skills.example.org/summarize" }

# bundled form
{ "bundle": {
    "uri": "tenzro://blob/<blake3-hex>",
    "sha256": "<sha256-hex>",
    "size_bytes": 481232
} }
07

Bundled skills run sandboxed

Registry admission is permissionless, so a published bundle is untrusted code from an unknown author. The sandbox, not admission control, is the boundary a caller relies on: the component runs with no filesystem, no network, no environment and no host methods, under a 50,000,000-fuel budget and a ten-second deadline. It gets the JSON it was handed and returns JSON.

The bundle carries two digests. The tenzro://blob/ locator is BLAKE3, which the transport verifies on read; sha256 is the digest the publisher declares, and the node re-hashes the fetched bytes against it before the component runs. Both are checked ahead of settlement, so a mismatch costs the caller nothing.

The guest contract is one invoke export inside the tenzro:skill/skill@1.0.0 interface, taking a JSON request string and returning a JSON response string. The receipt records the digests of the bytes, the request and the response, the outcome, and the fuel and wall-clock the guest consumed.

{ "output": { },
  "sandbox": {
    "content_hash": "<sha256-hex>",
    "bundle_uri": "tenzro://blob/<blake3-hex>",
    "receipt": {
      "component_id": "skill:<skill_id>:<invocation_id>",
      "content_hash_hex": "<sha256-hex>",
      "function": "invoke",
      "input_hash_hex": "<sha256-hex>",
      "output_hash_hex": "<sha256-hex>",
      "outcome": "success",
      "fuel": {
        "budget": 50000000,
        "consumed": 182344,
        "remaining": 49817656,
        "elapsed": { "secs": 0, "nanos": 41230000 }
      },
      "completed_at_ms": 1769472000000
    }
} }
08

Pinning an invocation

Because anyone can publish and a publisher can update their own row, a caller that needs certainty names what it expects to run. expected_version and expected_sha256 are checked against the registry row before settlement; a mismatch is refused rather than silently substituted.

tenzro skill use <skill_id> \
  --expected-version 1.4.0 \
  --expected-sha256 <sha256-hex> \
  --input '{"query":"..."}'
Related
← All docs