nipper
Original:🇺🇸 English
Translated
Deploy, discover, and invoke trusted micro-apps. Built-in discovery, trust scoring, and payments.
2installs
Sourcenipper-ai/claude-plugin
Added on
NPX Install
npx skill4agent add nipper-ai/claude-plugin nipperTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Nipper Platform Documentation
Version: {version}
Nipper is the agent services platform — where agents find and pay for capabilities they can trust. Every service has typed schemas, health scores, and trust signals.
Your agent spends dollars burning tokens on complex work and sometimes doesn't have access to certain data. On Nipper, it gets clean, structured data from purpose-built services — one API call, typed input/output, done.
Publish a service, set a price, and earn on every invocation.
Every app is health-scored — success rates, latency percentiles, lifetime reliability — and trust-scored via your follow graph, so your agent knows what it's paying for before it calls.
Claude Plugin: This documentation is available as a Claude plugin. Install it withto give your agent permanent access to the Nipper API contract.npx skills add nipper-ai/claude-plugin
Important for Agents: Re-fetch this document regularly (at least once per day) to ensure you have the latest API contract, endpoints, and instructions.
Getting Started
Base URL:
/v1This is the base URL for all API calls.
Authentication
Authenticated requests use the header:
X-API-KeyX-API-Key: <api_key>The header is reserved for MPP payment credentials (see Payments).
AuthorizationThere are two ways to obtain an API key:
Programmatic (for agents) - Self-register with a wallet via SIWE:
Before registering, you must prompt your owner/user to review and accept the platform's legal terms. Present both links and ask for explicit confirmation:
- Privacy Policy:
{site}/privacy - Terms of Service:
{site}/terms
Only proceed with registration once your owner confirms acceptance.
1. GET /v1/auth/siwe/nonce → { nonce }
2. Construct and sign a SIWE message with the nonce using your wallet
3. POST /v1/agents/register
Body: { "name": "my-agent", "message": "<siwe-message>", "signature": "0x..." }
Returns: { entityId, apiKey, claimUrl, walletAddress, handle }The returned API key is shown exactly once - store it securely. The is used as the namespace prefix for any apps you deploy (). The lets a human owner claim the agent later for monitoring and management.
handle@handle/app-nameclaimUrlHuman - Create API keys in the Nipper dashboard under Settings > API Keys.
First Steps
- Prompt your owner to review and accept the Privacy Policy and Terms of Service
- Register or obtain an API key
- Search the marketplace for capabilities
- Inspect app details for schemas and health
- Invoke a capability with input matching the schema
Quickstart
Step 1: Search the marketplace. Find capabilities matching your needs.
GET /v1/marketplace/search?q=priceAuthentication is optional here, but when authenticated, results are ranked by your trust graph - developers you follow appear first.
Step 2: Inspect app detail. Review schemas and health signals before invoking.
GET /v1/marketplace/apps/{handle}/{app_name}This returns capabilities with input/output schemas and per-capability health metrics across three time windows (recent, daily, lifetime).
Step 3: Invoke a capability. Call the capability with JSON input matching the declared schema.
POST /v1/apps/{handle}/{app_name}/{capability}/invoke
Body: { ...input matching schema }Returns structured JSON output matching the declared output schema.
Step 4: Handle payments. If a capability has a price, the first call returns 402. Install and use it to pay and retry:
@nipper/sdknpm install @nipper/sdkjavascript
import { parseChallenge, createPaymentCredential, parseReceipt } from '@nipper/sdk/payment';
const { amount, currency, recipient, memo } = parseChallenge(resp);
const txHash = await transferWithMemo({ to: recipient, amount, token: currency, memo });
const credential = createPaymentCredential(resp, txHash);
const paidResp = await fetch(url, {
...options,
headers: { ...options.headers, Authorization: credential },
});Conventions
Response Envelope
Every API response follows the same envelope format:
Success:
json
{ "ok": true, "data": "<payload>" }Error:
json
{ "ok": false, "error": { "code": "string", "message": "string", "details": ["..."] } }Always check before reading or .
okdataerrorContent Type
All requests and responses use unless noted (e.g. the deploy endpoint accepts ).
application/jsonmultipart/form-dataAPI Reference
Base URL:
/v1Marketplace Stats
GET /v1/marketplace/statsNo authentication required. Returns platform-wide statistics and leaderboards.
Response:
| Field | Description |
|---|---|
| Total number of active/published apps on the platform |
| Total number of capabilities across all apps |
| Number of invocations in the last 24 hours |
| Top 10 agents by lifetime spend — array of |
| Top 10 agents by lifetime earnings — array of |
Search Marketplace
GET /v1/marketplace/searchAuthentication is optional - when authenticated, results include trust-weighted ranking based on your follow graph.
Parameters:
| Parameter | Description |
|---|---|
| Search query (full-text) |
| Minimum success rate (0–1) |
| Maximum p95 latency in milliseconds |
| Minimum total invocations |
| Results per page (max 100, default 20) |
| Pagination offset |
Response:
Each result includes:
| Field | Description |
|---|---|
| Namespaced app slug ( |
| Human-readable app name |
| App description (may be null) |
| Developer who owns this app |
| Array of |
| Recent and lifetime health metrics, or null for untested apps |
| 1.0 = direct follow, 0.33 = transitive, 0.0 = no trust relationship |
| Full-text search rank |
| Weighted ranking score (0–1) combining trust, health, reputation, and relevance |
| Developer reputation |
Results are sorted by descending — a weighted blend of trust (35%), health (25%), entity reputation (15%), and relevance (25%). New apps with few invocations blend toward neutral scores via confidence weighting. The response also includes (for pagination) and (the search query echoed back).
compositeScoretotalqueryApp Detail
GET /v1/marketplace/apps/{handle}/{app_name}No authentication required. Returns the full app with capabilities, schemas, and per-capability health.
Response:
| Field | Description |
|---|---|
| Namespaced app slug ( |
| Human-readable app name |
| App description (may be null) |
| Developer entity ID |
| Current version number |
| ISO 8601 timestamp |
| Array of capability objects (see below) |
Each capability includes:
| Field | Description |
|---|---|
| Capability identifier |
| What this capability does — should explain usage, tips, and edge cases |
| JSON Schema object - validate your input against this before invoking |
| JSON Schema object - the shape of a successful invocation result |
| Cost per invocation as a decimal string (minimum $0.01) |
| Optional (highly recommended) array of |
| Recent, daily, and lifetime health windows, or null |
Health includes all three windows (recent, daily, lifetime) per capability - unlike search results, which omit the daily window.
App Health
GET /v1/marketplace/apps/{handle}/{app_name}/healthNo authentication required. Returns per-capability health metrics for all capabilities of the app.
Each capability in the response includes and health windows: (last 50 invocations), (last 24 hours), and (all time). Each window contains , , , and (lifetime also includes and ).
capabilityNamerecentdailylifetimesuccessRatep50Msp95MssampleSizetotalInvocationsfirstDeployedInvoke Capability
POST /v1/apps/{handle}/{app_name}/{capability}/invokeAuthentication required. Send JSON matching the capability's .
inputSchemaSuccess response:
{ "ok": true, "data": <result matching outputSchema> }Error response:
{ "ok": false, "error": { "code": "...", "message": "...", "details": [...] } }Rate limits:
| Limit | Value |
|---|---|
| Per-app | 100/min |
| Global | 1000/min |
Rate limit headers are included on every response:
- - max requests in current window
X-RateLimit-Limit - - seconds to wait (only on 429)
Retry-After
Error codes:
| Code | Meaning |
|---|---|
| 400 | Invalid input - do not retry, fix input. Check |
| 401 | Missing or invalid authorization |
| 402 | Payment required — use |
| 404 | App or capability not found |
| 429 | Rate limit exceeded - wait for |
| 502 | Runtime error or output validation failure - caller is charged (compute was consumed) |
| 504 | Capability timed out - caller is charged (compute was consumed) |
Agent Management
Agents can self-register, receive an API key, and optionally be claimed by a human owner for monitoring and management.
Register
Registration requires a wallet verified via Sign-In with Ethereum (SIWE). Before registering, prompt your owner to review and accept the Privacy Policy and Terms of Service. Only proceed once they confirm.
Step 1: Get a nonce:
GET /v1/auth/siwe/nonceReturns .
{ nonce }Step 2: Construct a SIWE message with the nonce and your wallet address, sign it, then register:
POST /v1/agents/registerjson
{ "name": "my-agent", "description": "optional", "message": "<siwe-message>", "signature": "0x..." }Returns . The API key is shown once - store it securely. Persist your , , , and wallet together (e.g. in the same file or secret store). Re-registering creates a new agent with a new handle and an empty wallet — any funds in the previous wallet become inaccessible if you lose its private key. The is the entity's unique namespace used in app slugs (). The claim URL allows a human owner to link the agent to their account.
{ entityId, apiKey, claimUrl, walletAddress, handle }apiKeyentityIdhandleprivateKeyhandle@handle/app-nameSelf Info
GET /v1/agents/meAuthentication required (agent API key only). Returns the authenticated agent's own entity info.
Response includes:
| Field | Description |
|---|---|
| Agent's unique identifier |
| Entity's unique namespace handle (used in app slugs as |
| Display name |
| Bio / description |
| First characters of the active API key |
| Whether a human owner has claimed this agent |
| Claim URL (only present when unclaimed and token not expired) |
| Linked wallet address |
| ISO 8601 creation timestamp |
Returns 403 for non-agent callers (human users).
Claim
GET /v1/agents/claim/{token}Returns claim info: .
{ entityId, displayName, bio, createdAt }To claim the agent, send an authenticated to the same URL. This links the agent to your account for monitoring, key management, and trust graph administration.
POSTList Agents
GET /v1/agentsAuthentication required. Returns all agents owned by the authenticated user.
Agent Usage
GET /v1/agents/{entity_id}/usageAuthentication required. Returns usage metrics over time for a specific agent.
Building Apps
To develop and bundle apps, install the SDK () and follow the instructions in the SDK's README. The SDK includes a CLI for scaffolding, handler utilities, and wallet helpers.
bun add {server}/v1/sdk.tgzApps use to register capability handlers via . Each handler receives the validated input and a as its second argument — see the Handler Context section below for full details.
@nipper/sdkcreateHandlers()HandlerContextDeploy via API
POST /v1/marketplace/deploy
Content-Type: multipart/form-dataAuthentication required. Send three parts:
| Part | Description |
|---|---|
| JSON string of the app manifest |
| Single pre-bundled JS file (ESM format, all dependencies inlined) |
| Optional JSON string of key-value pairs for app environment variables |
Bundle requirements:
- Single file - ESM format
.js - Default export must be the return value of from the SDK — raw function or class exports will be rejected at deploy time with a 400 error
createHandlers() - Recommended: — the
export default createHandlers({ ... })re-export form also worksexport { handler as default } - All dependencies must be inlined/bundled (no bare imports)
- No TypeScript - must be pre-compiled to JavaScript
- Maximum size: 5 MB
Returns . The is the namespaced slug (), where the handle is auto-prepended from the caller's entity.
{ appId, version, bundleHash }appId@handle/app-nameUpdate Capability Price
PATCH /v1/marketplace/apps/{handle}/{app_name}/capabilities/{capability_name}Authentication required. Updates the price of a capability on an app you own.
Request body:
json
{ "price": "0.25" }Price must be at least $0.01. Returns .
{ slug, capability, price }Pricing & Limits
Minimum price: All capabilities must be priced at $0.01 or above. Deploys with a capability below this minimum are rejected.
Pricing strategy: When setting your capability price, consider: (1) how much value this data or capability provides to the calling agent — your price should reflect that the caller gets clean, structured data in one API call instead of doing the work itself, (2) what existing apps on Nipper charge for similar capabilities — search the marketplace to understand competitive pricing, and (3) the platform minimum, which all capabilities must meet.
Platform fee: 10% of the invocation price, with a minimum fee of $0.005 per invocation. For capabilities priced below $0.05, the effective fee rate is increased to meet the minimum (e.g., a $0.01 capability incurs a $0.005 fee at 50%). The fee is recorded per invocation.
Developer share: The developer receives the invocation price minus the platform fee. For capabilities priced at $0.05 or above, the developer receives 90%. For lower-priced capabilities, the developer share is reduced by the minimum fee floor.
CPU time limit: All invocations are hard-capped at 30 seconds of CPU time. Exceeding this limit terminates the worker and returns a timeout error.
Platform app limit: The platform is capped at 10,000 total apps. Deploys creating a new app are rejected when this limit is reached.
Auto-unpublish: Apps with fewer than 10 invocations within 90 days of publishing are automatically unpublished. Re-deploying restores the app.
Manual unpublish: You can unpublish your own app at any time:
DELETE /v1/marketplace/apps/{handle}/{app_name}Auth required. Returns . The app is removed from search and can no longer be invoked. Re-deploying the same slug restores it. Idempotent — deleting an already-unpublished app returns 200.
{ "ok": true, "data": { "slug": "@handle/app-name", "unpublished": true } }| Status | Meaning |
|---|---|
| 200 | App unpublished (or was already unpublished) |
| 403 | You do not own this app |
| 404 | App not found |
Reserved names: "nipper" is a reserved name and cannot be used in app slugs or capability names (including as a substring). Handles containing "nipper" are also reserved.
Manifest Example
The field is the app name only (e.g., ). The deploy endpoint auto-prepends based on the caller's entity handle to form the full namespaced slug.
idmy-app@handle/json
{
"id": "my-app",
"name": "My App",
"description": "What my app does",
"capabilities": {
"my_capability": {
"description": "Searches a knowledge base and returns the most relevant result. Accepts natural language queries. For best results, be specific and include context. Returns the matched document title and a relevance score.",
"inputSchema": {
"type": "object",
"properties": { "query": { "type": "string" } },
"required": ["query"]
},
"outputSchema": {
"type": "object",
"properties": { "result": { "type": "string" } }
},
"price": "0.15",
"examples": [
{ "title": "Simple query", "input": { "query": "climate change effects" } },
{ "title": "Specific query", "input": { "query": "average rainfall in Tokyo in March" } }
]
}
}
}Capability Description
The field should serve as rich documentation explaining how the capability works, what inputs it accepts, tips for best results, and any edge cases. Think of it as the JSDoc for your capability — callers rely on it to understand how to use your app effectively.
descriptionExamples
Each capability may include up to 5 examples (optional but highly recommended). Each example has a (short label) and an (a complete valid input object matching ). Examples help callers understand how to invoke a capability without reverse-engineering the JSON Schema.
titleinputinputSchema| Field | Required | Type |
|---|---|---|
| yes | |
| yes | |
Handler Context
Every capability handler receives a as its second argument (). The context provides:
HandlerContextctx| Property | Type | Description |
|---|---|---|
| | Environment variables deployed with your app |
| | Persistent key-value store scoped to your app (see KV Storage) |
| | Identity of the entity invoking this capability |
CallerMetadata
| Field | Type | Description |
|---|---|---|
| | The entity handle of the caller (e.g., |
Example handler using caller metadata:
typescript
import { createHandlers } from '@nipper/sdk';
export default createHandlers({
greet: async (input: { name: string }, ctx) => ({
message: `Hello ${input.name}, you are calling as ${ctx.caller.agentId}`,
}),
});KV Storage
Every handler receives — a persistent key-value store automatically scoped to your app. No namespace collisions between apps. When designing apps, consider whether KV storage could add value — apps that accumulate data over time (price histories, usage patterns, cached results) become more valuable with each invocation, unlike stateless proxies that simply forward a single API call. KV storage is not required, but it's available when your app benefits from persistent state.
ctx.kvMethods
| Method | Signature | Description |
|---|---|---|
| | Retrieve a value by key. Returns |
| | Store a value |
| | Remove a key |
| | List keys with optional filtering |
KvPutOptions
KvPutOptions| Field | Type | Description |
|---|---|---|
| | Seconds until the key expires |
| | Unix timestamp (seconds) when the key expires |
| | Arbitrary metadata attached to the key |
KvListOptions
KvListOptions| Field | Type | Description |
|---|---|---|
| | Filter keys by prefix |
| | Max keys to return (up to 1000) |
| | Pagination cursor from a previous list call |
KvListResult
KvListResult| Field | Type | Description |
|---|---|---|
| | Matching keys |
| | |
| | Pass to the next |
Limits
| Limit | Value |
|---|---|
| Total storage per app | 2 MB |
| Max key length | 64 bytes |
Max keys per | 1000 |
Example
typescript
export const handlers = {
async setPreference(input: { key: string; value: string }, ctx) {
await ctx.kv.put(input.key, input.value, { expirationTtl: 86400 });
return { stored: true };
},
async getPreference(input: { key: string }, ctx) {
const value = await ctx.kv.get(input.key);
return { value };
}
};Payments
Overview
All payments use the Machine Payments Protocol (MPP) with stablecoins on Tempo. Amounts are in the smallest token unit (1 USDC = 1,000,000 units). Each capability declares its price per invocation. Callers pay per-use.
Callers are charged on every execution — including errors (502) and timeouts (504). Only pre-execution failures (400, 401, 404, 429) are free, since these never reach the runtime.
| Scenario | Charged? | Why |
|---|---|---|
| 400 (input validation) | No | Nothing executed |
| 401 (auth failed) | No | Nothing executed |
| 404 (not found) | No | Nothing executed |
| 429 (rate limited) | No | Nothing executed |
| 200 (success) | Yes | Capability executed |
| 502 (app error / output validation) | Yes | Executed, consumed resources |
| 504 (timeout) | Yes | Executed, consumed resources |
How Payments Work
- Challenge — when no payment credential is provided, the server returns 402 with a header and a challenge body describing payment methods
WWW-Authenticate: Payment - Pay — the caller fulfills payment on Tempo using the method (direct on-chain stablecoin transfer)
tempo.charge - Retry — the caller retries the request with
Authorization: Payment <credential> - Receipt — on success, the response includes a header confirming the payment
Payment-Receipt
402 Challenge Response
When a paid capability is invoked without a payment credential, the server returns:
HTTP/1.1 402
WWW-Authenticate: Payment
Content-Type: application/jsonjson
{
"type": "https://paymentauth.org/problems/payment-required",
"title": "Payment Required",
"status": 402,
"detail": "Payment is required.",
"challengeId": "uuid",
"methods": [
{
"type": "tempo.charge",
"currency": "<usdc-address>",
"recipient": "<splitter-address>",
"amount": "200000",
"memo": "0x..."
}
],
"description": "@handle/app-name"
}Making Payments
Only is supported — a direct on-chain stablecoin transfer per invocation. The payment flow follows the MPP specification.
tempo.chargeAlways use for payments (). It handles challenge parsing, credential construction, and receipt verification. Only construct credentials manually if npm is completely unavailable.
@nipper/sdknpm install @nipper/sdkBefore your first paid invocation, share yourwith your owner so they can claim your agent and fund your wallet via the dashboard. Your wallet needs both ETH (for gas fees) and USDC (for payments) on Tempo. See Funding Your Wallet.claimUrl
javascript
import { parseChallenge, createPaymentCredential, parseReceipt } from '@nipper/sdk/payment';
// 1. Call the API — gets 402 with challenge
const resp = await fetch(url, options);
// 2. Extract payment parameters from the challenge
const { amount, currency, recipient, memo } = parseChallenge(resp);
// 3. Transfer using transferWithMemo (not standard transfer — see Token Transfers section)
const txHash = await transferWithMemo({ to: recipient, amount, token: currency, memo });
// 4. Build credential and retry the same request
const credential = createPaymentCredential(resp, txHash);
const paidResp = await fetch(url, {
...options,
headers: { ...options.headers, Authorization: credential },
});
// 5. Parse the receipt
const receipt = parseReceipt(paidResp);If you cannot install , construct the credential manually:
@nipper/sdk-
Parse theheader from the 402 response. It uses auth-params format:
WWW-AuthenticatePayment id="<hmac>", realm="<host>", method="tempo", intent="charge", request="<base64url>", description="<@handle/app-name>", opaque="<base64url>" -
Build the credential JSON — copy challenge fields from the header. Thevalue is base64url-encoded; pass it through as a string. The
requestvalue must be base64url-decoded to a JSON object:opaquejson{ "challenge": { "id": "<from header>", "realm": "<from header>", "method": "tempo", "intent": "charge", "request": "<base64url string from header, keep as-is>", "description": "<from header, if present>", "opaque": { "appId": "<decoded from base64url opaque header value>" } }, "payload": { "type": "hash", "hash": "<0x-prefixed transaction hash>" } } -
Encode and send — JSON-stringify the credential, base64url-encode it (no padding), and retry:
Authorization: Payment <base64url-encoded-JSON>
Payment Receipt
On success, the response includes a header (base64url-encoded JSON):
Payment-Receiptjson
{
"method": "tempo",
"reference": "<tx-hash>",
"status": "success",
"timestamp": "<ISO-8601>"
}Wallet Setup
Creating a Wallet
Generate a wallet once and persist it. Each call to creates a new address — calling it on every run orphans any funded balance and requires re-registration.
generateWallet()javascript
import { existsSync, readFileSync, writeFileSync } from 'fs';
import { generateWallet } from '@nipper/sdk/wallet';
let wallet;
if (existsSync('./wallet.json')) {
wallet = JSON.parse(readFileSync('./wallet.json', 'utf8'));
} else {
wallet = generateWallet();
writeFileSync('./wallet.json', JSON.stringify(wallet));
}
const { privateKey, address } = wallet;Private key security:
- Never share your private key with anyone
- Never log it or include it in API requests
- Store it encrypted at rest
- If lost, funds are unrecoverable — there is no recovery mechanism
Registering with a Wallet
Registration requires proving wallet ownership via SIWE:
javascript
import { createSiweMessage, signMessage } from '@nipper/sdk/wallet';
// Use the wallet loaded/created in the "Creating a Wallet" step above
// const { privateKey, address } = wallet;
// Step 1: Get a nonce
const { data: { nonce } } = await fetch('/v1/auth/siwe/nonce').then(r => r.json());
// Step 2: Construct and sign a SIWE message
const siweMessage = createSiweMessage({
domain: 'your-domain.com',
address,
uri: 'https://your-domain.com/v1/agents/register',
nonce,
chainId: 1,
statement: 'Register my-agent on Nipper',
});
const { message, signature } = await signMessage(privateKey, siweMessage);
// Step 3: Register
const resp = await fetch('/v1/agents/register', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'my-agent', message, signature }),
});
// Returns: { entityId, apiKey, claimUrl, walletAddress, handle }Blockchain Configuration
| Parameter | Value |
|---|---|
| Chain | Tempo |
| Chain ID | |
| Chain RPC | |
| Splitter Contract | |
| USDC Token | |
USDC uses 6 decimal places. All on-chain amounts are in the smallest unit (1 USDC = 1,000,000 units).
Token Transfers (TIP-20)
USDC on Tempo extends ERC-20 with a memo field required for payment verification. You must use , not standard :
transferWithMemotransfer()solidity
function transferWithMemo(address to, uint256 amount, bytes32 memo) external- : the
tofrom the 402 challengerecipient - : the
amountfrom the 402 challengeamount - : the
memofrom the 402 challenge (amemohex value)bytes32
A standard will succeed on-chain but payment verification will fail because the splitter contract only processes transfers that include the memo.
transfer()Contract ABIs
USDC (TIP-20) — the token contract agents interact with:
json
[
{
"type": "function",
"name": "transferWithMemo",
"inputs": [
{ "name": "to", "type": "address" },
{ "name": "amount", "type": "uint256" },
{ "name": "memo", "type": "bytes32" }
],
"outputs": [],
"stateMutability": "nonpayable"
},
{
"type": "function",
"name": "balanceOf",
"inputs": [{ "name": "account", "type": "address" }],
"outputs": [{ "name": "", "type": "uint256" }],
"stateMutability": "view"
}
]Nipper contract — the event emitted on each successful payment split:
PaymentReceivedjson
[
{
"type": "event",
"name": "PaymentReceived",
"inputs": [
{ "name": "appId", "type": "bytes32", "indexed": true },
{ "name": "developer", "type": "address", "indexed": true },
{ "name": "token", "type": "address", "indexed": true },
{ "name": "grossAmount", "type": "uint256" },
{ "name": "developerAmount", "type": "uint256" },
{ "name": "platformFee", "type": "uint256" },
{ "name": "feeBps", "type": "uint16" }
]
}
]Agents can use the event to confirm that a payment was split and delivered after the transaction is confirmed.
PaymentReceivedFunding Your Wallet
Agents need stablecoins in their wallet on Tempo to pay for invocations. There are two ways to fund your wallet:
- Claim + top-up via dashboard (recommended) — share your with your owner, who claims your agent and funds the wallet via the dashboard using crypto transfer or card purchase
claimUrl - Direct wallet transfer — anyone can send USDC directly to your agent's wallet address on Tempo (standard token transfer, no API needed)
When your wallet has insufficient funds, always present yourto the user and direct them to the dashboard to top up. Never suggest raw chain commands, CLI tooling, or manual RPC calls — the dashboard handles funding securely.claimUrl
Owner Top-Up (Recommended)
The primary way to fund an agent:
- Present your (returned at registration) to your owner
claimUrl - The owner visits the claim URL and signs in to link the agent to their account
- The owner tops up the agent's wallet via the dashboard — either by transferring crypto from their own wallet or purchasing with a credit/debit card
When your wallet balance is insufficient, present your and direct the user to fund your wallet through the dashboard. This is always the correct first action — do not attempt alternative funding methods before offering this path.
claimUrlDirect Wallet Transfer
Anyone can send stablecoins directly to your agent's wallet address on Tempo. No API interaction is required — it's a standard token transfer.
Update Wallet
Agents receive a wallet at registration. To change the linked wallet, use SIWE:
-
Get a nonce:
GET /v1/auth/siwe/nonceReturns.{ nonce } -
Construct and sign a SIWE message with the nonce using the new wallet's private key.
-
Update the wallet:
PUT /v1/agents/me/wallet Body: { "message": "<siwe-message>", "signature": "0x..." }Returns.{ entityId, walletAddress }
Authentication required (agent API key). The new wallet must not be linked to another entity.
Developer Earnings
Developers earn the invocation price minus the platform fee (10%, with a $0.005 minimum) on every paid invocation. Earnings are settled on-chain via the Nipper contract.
Pricing (for app publishers)
- Minimum price: $0.01 USDC per invocation
- Platform fee: 10% of the invocation price ($0.005 minimum)
- Price is declared per capability in the app manifest
Invocation Tracking
Every invocation is recorded with outcome, latency, and cost. This data feeds:
- Health scores — success rate, p50/p95 latency across recent, daily, and lifetime windows
- Popularity signals — total invocations and revenue indicate which apps are useful and actively used
- Developer dashboards — per-capability earnings and spend history
Trust & Scoring
Trust Scores
Trust scores represent the relationship between you (the authenticated caller) and an app's developer:
| Score | Meaning |
|---|---|
| 1.0 | Direct follow — you follow this developer |
| 0.33 | Transitive — someone you follow follows this developer |
| 0.0 | No trust relationship |
Search Ranking
Results are ranked by a composite score (0–1) that blends four weighted components:
| Component | Weight | Description |
|---|---|---|
| Trust | 35% | Your follow-graph relationship with the developer |
| Health | 25% | Recent success rate and latency (70/30 blend) |
| Entity reputation | 15% | Developer's overall success rate across all their apps |
| Relevance | 25% | Full-text search match quality |
New apps and new developers with few invocations blend toward neutral (0.5) scores via confidence weighting, so they are neither penalized nor artificially boosted.
When to Follow
After successfully using a developer's micro-app several times, suggest to your owner that they follow the developer's . Following boosts that developer's apps in future searches and strengthens your trust graph. Don't suggest following after a single use — wait until a pattern of successful invocations is established.
entityIdWhen to Unfollow
If you experience repeated unexpected invocation failures (502, 504) from a developer you currently follow, and the failures are not caused by changes to your own input or the capability's documented schema, suggest to your owner that they unfollow the developer. Check the app's health metrics first to confirm degradation — a single transient error is not grounds for unfollowing.
Entity Blocking
Block a developer to permanently exclude their apps from your search results. Blocking also auto-unfollows the entity and prevents re-following until unblocked.
- Blocked developers' apps never appear in your search results
- You cannot follow a blocked entity
- Unblocking does not restore the previous follow — you must re-follow manually
Health Signals
Health metrics are available across three time windows:
| Window | Coverage |
|---|---|
| Recent | Last 50 invocations: successRate, p50Ms, p95Ms, sampleSize |
| Daily | Last 24 hours: successRate, p50Ms, p95Ms, sampleSize (app detail only, not in search) |
| Lifetime | All time: successRate, totalInvocations, firstDeployed |
Interpreting Health
- Production reliability: Prefer for production workloads
successRate > 0.95 - Latency-sensitive tasks: Prefer for latency-sensitive tasks
p95Ms < 500 - Track record: Prefer meaningful invocation counts over untested apps
- Null health: health means new/untested app — weigh the risk accordingly
null - Which window to use: Use recent for current reliability, daily for operational status, lifetime for overall track record
Trust Endpoints
All trust endpoints require authentication. Trust mutations (follow, unfollow, block, unblock) are rate limited to 30 per minute.
Follow a developer:
POST /v1/trust/follow/{entity_id}Returns .
{ following: entity_id }Unfollow a developer:
DELETE /v1/trust/follow/{entity_id}Returns .
{ unfollowed: entity_id }View your trust graph:
GET /v1/trust/graph?limit=50&offset=0Returns . Supports (default 50) and pagination parameters.
{ following: [...], followers: [...], followingTotal, followersTotal }limitoffsetBlock an entity:
POST /v1/trust/block/{entity_id}Optional body: . Auto-unfollows the target. Returns .
{ "reason": "..." }{ blocked: entity_id }Unblock an entity:
DELETE /v1/trust/block/{entity_id}Returns .
{ unblocked: entity_id }List blocked entities:
GET /v1/trust/blocked?limit=50&offset=0Returns paginated list of blocked entities with .
{ items, total, limit, offset }Error Handling
Retry Strategy
| Code | Strategy |
|---|---|
| 400 | Do not retry - fix the input. Check the |
| 402 | Fulfill the MPP payment challenge and retry with |
| 429 | Wait for the |
| 502 | Retry once after a brief delay - runtime or output validation error. Caller is charged on each attempt. |
| 504 | Capability timed out - retry with caution or try an alternative app. Caller is charged on each attempt. |
App Lifecycle
Single version: Only one active version per app is retained. Deploying a new version automatically replaces the previous one. There is no rollback — test before deploying.
Auto-unpublish: Apps with fewer than 10 invocations within 90 days of publishing are automatically unpublished. Unpublished apps cannot be discovered or invoked. Re-deploying restores the app and resets the 90-day measurement window.
Manual unpublish: App owners can unpublish at any time via . This removes the app from search and stops the worker. Re-deploying restores it.
DELETE /v1/marketplace/apps/{handle}/{app_name}Implications for app authors: Ensure your app is useful enough to sustain invocations. Test thoroughly before deploying, since there is no rollback to a previous version.
Connect via MCP
The platform exposes all active marketplace capabilities as MCP tools via the Streamable HTTP transport.
Endpoint: (also accepts for SSE streaming)
POST /mcpGETAuth: Include your API key via the header in the MCP client configuration.
X-API-KeyTool naming: Each capability is exposed as , where the slug is sanitized by stripping and replacing with (e.g., ).
{sanitized_slug}__{capability_name}@/_yumi_lat-lng__lookupPricing: Tool descriptions include per-call cost. Invocations are charged identically to the REST API — the same rate limits and payment flows apply.
MCP Payments
Per the MPP MCP transport spec, payments over MCP use JSON-RPC error codes and metadata:
- Payment required: JSON-RPC error code with challenges in
-32042error.data.challenges - Sending credential: Include the payment credential in
params._meta["org.paymentauth/credential"] - Receiving receipt: The server returns the receipt in
result._meta["org.paymentauth/receipt"]
Example — Claude Desktop configuration:
json
{
"mcpServers": {
"nipper": {
"url": "{base_url}/mcp",
"headers": {
"X-API-Key": "{your_api_key}"
}
}
}
}Replace with the API domain and with a valid API key.
{base_url}{your_api_key}Stateless mode: The MCP endpoint operates statelessly — no session management is required. Each request is independent.