Skip to main content
Glama

TWZRD Agent Intelligence

get_poec_score

Read-onlyIdempotent
Free preview: PoEC v0 (Proof of Economic Contribution) for a payer wallet,
computed from the same observed x402 snapshot score_wallet_for_intel returns.

poec_score = log10(1 + observed USDC sent) x success_quality x diversity
x wash_cleanliness, behind hard floors (>=5 paid calls, >=3 distinct
counterparties, wash_factor >= 0.5, not single-counterparty, wash_flag
clean). Any failed floor, or an unobservable corpus, scores 0.0 with
floors_passed=false - the floors fail closed, never open. wash_factor is a
cleanliness multiplier (1.0 = clean) and is never inverted.

Honesty contract: `claimable` is ALWAYS false. Volume here is
corpus-observed, not a payout unlock. `success_quality` comes from the
payer join onto signed `receipt_settlement_leaves` (0211); if that join
is unobservable, `success_rate` stays in evidence_gaps and the score
reads 0.0. What this surface already shows honestly is the floor filter
(eligible_v0) and every component the score is built from. Self-reported
settlements go through submit_contribution_claims.

Base (EVM) 0x wallets are scored from the relayer-attributed x402_base_daily
rollup (90d) with the same shape, but no wash/sybil graph exists for Base
payers yet, so their wash_flag reads "unknown" (never "clean"), the wash
floor stays closed, and poec_score stays 0.0 regardless of real volume.
A wallet the corpus could not observe at all returns `error` set; on that
path any real observed Base volume is attached under `base_observed`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYesPayer wallet (Solana base58 or Base 0x) to score for Proof of Economic Contribution.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNoISO timestamp the snapshot was scored at.
errorNoPresent only when the wallet could not be observed at all (e.g. not a valid Solana pubkey, upstream unavailable) -- distinguishes 'not scoreable' from a genuinely inactive wallet, both of which otherwise read as poec_score 0.0.
walletNoThe scored payer wallet.
claimableNoAlways false: volume is corpus-observed, not facilitator-attested or joined to a settlement leaf.
wash_flagNo"clean" | "single_counterparty" | "unknown", from the intel snapshot.
componentsNoobserved_volume, success_quality, diversity, hop_multiplier, wash_cleanliness, solana_boost.
paid_callsNoObserved x402 paid calls sent.
poec_scoreNolog10(1 + observed USDC sent) x success_quality x diversity x wash_cleanliness; 0.0 when any floor fails.
eligible_v0NoFloors passed and observed volume > 0. A floor filter, not an unlock.
success_rateNoSigned receipt_settlement_leaves for this payer / observed paid_calls, capped at 1.0. None = join unobservable; 0.0 = join ran, zero attested leaves. Never implies claimable.
base_observedNoPresent only for a Base (EVM) wallet TWZRD has independently observed paid calls from: real paid_calls/total_usdc/distinct_counterparties (90d, high-confidence, x402_base_daily). Informational only -- no wash/sybil evaluation exists for Base payers yet, so poec_score and floors_passed are unaffected by this field.
evidence_gapsNoInputs with no live source. Empty plus success_rate 0.0 means the 0211 join ran and this wallet has no signed settlement leaf — not a missing join.
floors_passedNoAll hard floors held: >=5 paid calls, >=3 distinct counterparties, wash_factor >= 0.5, not single-counterparty, wash_flag clean, corpus observable.
score_versionNoPoEC contract version, e.g. "poec_v0".
source_intel_scoreNointel_score of the underlying snapshot.
source_effective_scoreNoeffective_score of the underlying snapshot.
distinct_counterpartiesNoDistinct counterparties observed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / evidence_gaps / description
      Previous value: -"Inputs with no live source. \"success_rate\" has none today, so success_quality and poec_score read 0.0 until a settlement-success join exists."New value: +"Inputs with no live source. Empty plus success_rate 0.0 means the 0211 join ran and this wallet has no signed settlement leaf — not a missing join."
    • addedOutput schema / properties / success_rate
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Signed receipt_settlement_leaves for this payer / observed paid_calls, capped at 1.0. None = join unobservable; 0.0 = join ran, zero attested leaves. Never implies claimable.",
      +  "title": "Success Rate"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / wallet / description
      Previous value: -"Solana payer wallet public key (32-44 base58 chars) to score for Proof of Economic Contribution."New value: +"Payer wallet (Solana base58 or Base 0x) to score for Proof of Economic Contribution."
    • addedOutput schema / properties / base_observed
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Present only for a Base (EVM) wallet TWZRD has independently observed paid calls from: real paid_calls/total_usdc/distinct_counterparties (90d, high-confidence, x402_base_daily). Informational only -- no wash/sybil evaluation exists for Base payers yet, so poec_score and floors_passed are unaffected by this field.",
      +  "title": "Base Observed"
      +}
  3. Changed1 schema field changed
    • addedOutput schema / properties / error
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Present only when the wallet could not be observed at all (e.g. not a valid Solana pubkey, upstream unavailable) -- distinguishes 'not scoreable' from a genuinely inactive wallet, both of which otherwise read as poec_score 0.0.",
      +  "title": "Error"
      +}
  4. Added

TDQS

A4.2/5.0
Behavior5/5

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

The description is highly transparent about edge-case behavior, including returning an error for unobserved wallets, Base wallets being marked wash_flag 'unknown', floors staying closed, and scores being 0.0 in those cases. This goes well beyond the readOnlyHint and idempotentHint annotations without contradicting them.

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

Conciseness2/5

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

The description is heavily repetitive, restating the same floor/failure semantics multiple times with nearly identical phrasing (e.g., 'floors fail closed, never open' and 'never inverted'). While the structure is logical, the redundancy makes it less concise than it should be.

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?

Even though an output schema exists and return values need not be explained, the description covers important contextual edge cases such as unobserved wallets, Base-specific limitations, and the error path. It is complete enough for an agent to understand when and how the tool behaves.

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?

The input schema already fully describes the wallet parameter as a payer wallet with Solana base58 or Base 0x formats, so the description adds little new parameter-level meaning. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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 clearly states that the tool scores a payer wallet for Proof of Economic Contribution and explicitly references the same x402 snapshot returned by score_wallet_for_intel, helping distinguish it from that related tool. It also mentions the alternative path for self-reported settlements via submit_contribution_claims.

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

Usage Guidelines4/5

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

The description gives usable guidance by contrasting this tool with score_wallet_for_intel's snapshot and explicitly routing self-reported settlements to submit_contribution_claims. It could more explicitly state when to choose this tool over other siblings, but the main alternatives are addressed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.