Skip to main content
Glama
0xddneto

AI Proof of Us MCP Server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AIPOU_RPC_URLNoOptional Base-compatible JSON-RPC endpoint.
AIPOU_DATA_DIRNoOptional local directory for receipt and collector state.
AIPOU_CLAIMS_ADDRESSNoAIPOU claims contract address on Base.
AIPOU_CONTRACT_ADDRESSNoAIPOU token contract address on Base.
AIPOU_AGENT_PRIVATE_KEYNoOptional private key for a dedicated farming wallet. Never use a primary wallet.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_aipou_contractA

Read the configured AIPOU token and claims contract details for display or client setup. Returns Base chain metadata, explorer URLs, and minimal ABIs; it does not contact a wallet, submit a transaction, or change local state.

get_aipou_identityA

Read the public identity used by this MCP installation when a client needs to display or verify its farming wallet and collector. Returns the wallet address, Ed25519 public key, and fingerprint; it never returns private keys, submits transactions, or changes state.

get_aipou_statusA

Use this first when the user asks for pending, claimed, or wallet-balance information; use a settlement tool only after an explicit claim request. Returns a read-only JSON summary of receipt counts, estimated pending AIPOU, prior settlement state, and the farming wallet's on-chain AIPOU balance. It may read Base through the configured RPC, but it never signs or submits a transaction, changes receipts, reveals private keys, or returns full receipt payloads.

estimate_ai_rewardA

Use before complete_ai_task only when a preview is useful. Provide non-negative inputTokens, outputTokens, and durationSeconds for one task; it returns JSON with estimatedReward and unit for a client-signed estimate. It creates no task or receipt, changes no state, and submits no transaction. The result is informational: complete_ai_task derives the receipt evidence, and the validator determines final eligibility and trust tier.

begin_ai_taskA

Use once before meaningful AI work to create a task session. Provide the provider, model, client, and a 32-byte hash of the task description; returns a unique nonce and EIP-712 authorization signed by the dedicated farming wallet. This writes a pending local task session but does not publish, mint, or submit an on-chain transaction. Pass the returned nonce to complete_ai_task; do not reuse it for another task.

complete_ai_taskA

Use exactly once after begin_ai_task finishes meaningful work. Supply that session's nonce, non-negative inputTokens and outputTokens, whole-second durationSeconds, and a 32-byte outputHash; providerEvidence is optional and only for a configured provider key. It validates the nonce and bounded usage, derives the evidence tier, rejects replay, then writes the local receipt store and returns an Ed25519-signed receipt plus compact workReceiptId metadata. It does not publish a Merkle root, mint tokens, or submit a blockchain transaction. Use get_aipou_status to inspect recorded work; repeating a nonce or evidence fails closed instead of creating another receipt.

export_ai_receiptsA

Export signed receipts already stored in this MCP installation, optionally limited to one farming wallet address. Returns JSON with count and receipt payloads, so use it only where local receipt data is appropriate to expose. It does not create a receipt, validate a claim, contact Base, or submit a transaction; use get_aipou_status instead for a compact private summary.

create_paybox_work_linkA

Derive and return a digest-only external evidence link between an existing AIPOU workReceiptId and an opaque Paybox operation artifact. It is a pure local calculation: it does not persist the link, call Paybox, unlock a wallet, create a payment, sign a transaction, or change AIPOU claim eligibility. Use it for portable correlation only, and verify both artifacts with their native systems before relying on the returned link.

create_technocore_work_linkA

Derive and return a digest-only external evidence link between an existing AIPOU workReceiptId and a Technocore transport artifact. It is a pure local calculation: it does not persist the link, call Technocore, sign a message, read a key, verify a transport signature, change AIPOU claim eligibility, or establish delivery. Use it for portable correlation only, and verify the Technocore artifact with its native verifier before relying on the returned link.

settle_ai_rewardsA

Use only after an explicit user request to claim one limited batch, not for status or reward previews. maxReceipts defaults to 25 and is capped at 100; the tool validates eligible local receipts against settlement policy, publishes one Merkle root, and mints the included rewards. It submits two Base transactions, so the host client and user must apply their own confirmation policy. Use settle_all_ai_rewards instead for an explicit request to claim all pending eligible receipts.

settle_all_ai_rewardsA

Use only after an explicit broad request such as 'claim my AIPOU' or 'settle all pending AIPOU'; do not use it for a status check. batchSize defaults to 100 and maxBatches to 20, with bounds of 1-100 and 1-50, so large queues remain bounded. It validates all currently eligible local receipts and submits Base transactions for each batch: one Merkle-root publication and one claim transaction per batch. The host client and user must apply their own confirmation policy; use settle_ai_rewards when the user asks for one limited batch.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 11 tools

Disambiguation5/5

Each tool has a distinct, clearly defined role: task lifecycle (begin, complete, estimate), settlement (settle one batch vs all), linking (Paybox vs Technocore), and read/utility (status, contract, identity, export). No two tools could be easily confused; even the two settlement tools are explicitly differentiated by scope and usage conditions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with clear, domain-specific verbs (begin, complete, estimate, export, create, settle, get) and nouns (ai_task, ai_reward, paybox_work_link, aipou_status). The only slight variation is 'settle_all_ai_rewards' vs 'settle_ai_rewards', which is logical and still follows the pattern.

Tool Count5/5

With 11 tools, the set is well-scoped and neither sparse nor bloated. Each tool covers a meaningful operation in the AI task farming and settlement workflow, from task initiation to reward claiming, without redundancy.

Completeness5/5

The domain of AI proof-of-work reward management is fully covered: task creation, completion, estimation, settlement (both single-batch and all), receipt export, external linking, and read-only status/contract/identity queries. There are no obvious missing operations; the lifecycle is closed from start to finish.

Maintenance

ActivityActive
ResponsivenessWithin a week