Skip to main content
Glama
0xddneto

AI Proof of Us MCP Server

by 0xddneto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

complete_ai_task

Finish an AI task by submitting its nonce, token counts, duration, and output hash to validate usage and receive a signed, replay-resistant receipt.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nonceYesUnique 32-byte nonce returned by begin_ai_task for this exact task.
outputHashYesSHA-256-style 32-byte hash of the task output; never send the raw output.
inputTokensYesNon-negative input-token count for this task, capped at 10,000,000.
outputTokensYesNon-negative output-token count for this task, capped at 10,000,000.
durationSecondsYesTask duration in whole seconds from 0 through 86,400.
providerEvidenceNoOptional provider-signed evidence. Omit it for a client-signed receipt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.1.1
    • addedInput schema / properties / durationSeconds / description
      Added value: +"Task duration in whole seconds from 0 through 86,400."
    • addedInput schema / properties / inputTokens / description
      Added value: +"Non-negative input-token count for this task, capped at 10,000,000."
    • addedInput schema / properties / nonce / description
      Added value: +"Unique 32-byte nonce returned by begin_ai_task for this exact task."
    • removedInput schema / properties / outputHash / $ref
      Removed value: -"#/properties/nonce"
    • addedInput schema / properties / outputHash / description
      Added value: +"SHA-256-style 32-byte hash of the task output; never send the raw output."
    • addedInput schema / properties / outputHash / pattern
      Added value: +"^0x[a-fA-F0-9]{64}$"
    • addedInput schema / properties / outputHash / type
      Added value: +"string"
    • addedInput schema / properties / outputTokens / description
      Added value: +"Non-negative output-token count for this task, capped at 10,000,000."
    • addedInput schema / properties / providerEvidence / description
      Added value: +"Optional provider-signed evidence. Omit it for a client-signed receipt."
    • addedInput schema / properties / providerEvidence / properties / keyId / description
      Added value: +"Configured provider-verification key identifier, between 1 and 128 characters."
    • addedInput schema / properties / providerEvidence / properties / signature / description
      Added value: +"Provider signature over the canonical evidence payload; invalid evidence fails closed."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the sparse annotations, the description discloses that it validates the nonce and bounded usage, derives an evidence tier, rejects replay, writes a local receipt store, and returns an Ed25519-signed receipt. It also explicitly states non-goals: no Merkle root publication, no token minting, and no blockchain transaction. This is rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the most critical usage rule and every sentence contributes new information: requirements, behavior, non-goals, and alternative tool routing. It is dense but appropriately sized for a 6-parameter lifecycle tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With sparse annotations and no output schema, the description carries the full burden of contextual explanation. It covers what happens, what is returned, what fails closed, and what not to expect. Everything an agent needs to invoke this tool correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds useful relational context: the nonce comes from the begin_ai_task session, outputHash should never be the raw output, and providerEvidence is optional and only for a configured provider key. This goes beyond the schema without repeating it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: completing an AI task after begin_ai_task finishes meaningful work. It clearly distinguishes the tool from publishing, minting, and blockchain transactions, and names get_aipou_status for inspection. An agent can accurately identify what this tool does and what it does not do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use exactly once after begin_ai_task finishes meaningful work' is an explicit trigger condition. The description also explains when providerEvidence should be supplied, what happens on replay, and which sibling tool to use for inspecting recorded work. This gives both positive and negative usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools