Skip to main content
Glama

verify_reputation

Re-derive PageRank over a directed trust graph to confirm provided reputation scores are correct. Optionally checks against a graph commitment for integrity.

Instructions

Verify LUMEN reputation scores by re-deriving PageRank over the supplied graph (LUMEN verify).

Pass the graph and the `scores` (and optionally the `graph_commitment`) from a
`get_reputation_scores` result; confirms they are the correct PageRank of exactly that graph.

Returns:
    The standard envelope; `result` is `{valid: <bool>, max_abs_diff, [commitment_match]}`.
    Cost ~$0.002 USDC.

Example:
    verify_reputation(nodes=3, edges=[[0,1,1.0],[1,2,0.5],[2,0,0.5]], scores=[0.33,0.33,0.34])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodesYesNumber of nodes in the directed trust graph, 1..100000. Node indices in `edges` must be in [0, nodes).
edgesYesDirected, weighted trust edges as `[from_index, to_index, weight]`. An edge i→j with weight w means node i confers w trust on node j. Weights need not be normalized.
scoresYesThe `scores` array from a get_reputation_scores result, to be re-derived and confirmed.
dampingNoPageRank damping factor in [0,1] (default 0.85). Lower = more weight on the uniform prior, dampening graph manipulation.
graph_commitmentNoOptional `graph_commitment` (0x… SHA-256) from the result, to bind the check to the exact graph. Pass '' to skip.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries the burden. It discloses the re-derivation logic, cost (~$0.002 USDC), and return fields (valid, max_abs_diff, commitment_match). It does not cover error handling or authentication, but is sufficiently transparent for a verification tool.

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 concise with four sentences and an example, all of which add value. It is well-structured with a title line, usage instruction, return specification, cost note, and example. No redundancy or waste.

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

Completeness4/5

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

Given five parameters (three required) and an output schema, the description provides enough context to understand the tool's functionality and usage. It mentions cost and a return envelope. However, missing details on error conditions or prerequisites slightly reduce completeness.

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% with descriptions for all five parameters. The description adds value by explaining usage context (pass from get_reputation_scores) and providing an example, which goes beyond the schema alone. It also clarifies the role of optional parameters.

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 the tool verifies LUMEN reputation scores by re-deriving PageRank, with the parenthetical 'LUMEN verify' distinguishing it from get_reputation_scores. The verb 'verify' and resource 'reputation scores' are specific and unambiguous.

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 explicitly instructs to pass the graph and scores (and optionally graph_commitment) from get_reputation_scores results, and confirms they are the correct PageRank. It provides an example and implies usage after get_reputation_scores, but lacks explicit when-not or alternative tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexar76/aimarket-oracle-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server