Skip to main content
Glama

Tereno on Base

by xyz.tereno
OverviewDiscussionsAdmin

Publish work you already computed, and get it attested on-chain

tereno_publish

Free, no payment and no gas. Submit a contract bytecode fingerprint you computed yourself. Tereno recomputes it against chain state: a mismatch burns the submission, a match makes you the seeder and pays you the reuse dividend in non-transferable credits whenever another wallet's settled call reuses it. Supply an ERC-8004 agentId you own and the passing audit is also projected to the Reputation Registry on Base under tag tereno.audit. No agentId yet? This tool has no HTTP-only sibling here: pay POST /api/v1/agents/register once (small flat fee, covers the mint gas) to get one, then publish again with it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYesYour Base wallet. Becomes the seeder and earns the reuse dividend.
addressYesBase contract address the fingerprint is for.
agentIdNoOptional ERC-8004 agentId you own, as a decimal string. Ownership is verified against ownerOf before anything is written on-chain; an unverifiable claim is skipped and changes nothing about the publication.
bytecodeHashNokeccak256 of the deployed bytecode you read. Omit only for an address with no code.
bytecodeBytesNoLength of the deployed bytecode in bytes. Must be 0 exactly when bytecodeHash is omitted.
computedAtBlockYesBlock number you read the bytecode at.
registerIfMissingNoExplicit consent to be attested via a Tereno-delegated identity you already paid POST /api/v1/agents/register for. Bind it by signing <contract-address>:erc8004-register as the resource. Does not itself trigger a mint — it only unlocks reuse of one you hold.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral disclosure burden. It explains costs (free, no gas), consequences (mismatch burns, match pays dividends), requirements (owning an agentId), and side effects (reputation registry projection). It also notes that unverifiable agentId claims are skipped without affecting the publication.

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

Conciseness4/5

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

The description is a single dense paragraph with six sentences. It front-loads key information (free, no gas) and every sentence contributes useful context. It is not overly verbose, though structured formatting could improve scanability.

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?

The description comprehensively covers the tool's effects and prerequisites: burn on mismatch, dividend on match, reputation projection with agentId, and the external registration process. Despite lacking an output schema, it provides a complete picture of what happens before, during, and after the call.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds some context for agentId (audit projection) and the registration flow, but it largely repeats schema information. It does not significantly elaborate on computedAtBlock or bytecodeBytes beyond their existing schema descriptions.

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 and title clearly state the tool's function: submitting a self-computed contract bytecode fingerprint for on-chain attestation. It uses a specific verb (submit/publish) and a specific resource (contract bytecode fingerprint), making the purpose unambiguous and distinct from sibling tools.

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?

The description explicitly states when to use the tool (after computing a fingerprint) and provides an alternative path for obtaining an agentId via an external HTTP endpoint. It also notes that there is no HTTP-only sibling for this, guiding the agent to the correct external registration route.

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

All Tereno on Base toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources