Skip to main content
Glama

Find the NET programs and mechanisms that fit an objective

net_programs
Read-onlyIdempotent

NET PROGRAMS: say in plain words what you want to do with NET (buy an independent review of work evidence, commission or take a specialist task, keep up a place, earn NET by accepted work, hold NET for a future obligation) and get the programs and the demand mechanisms that fit, each with the level it has really reached on the evidence ladder (design, contract complete, dry-executable, deployed, used, paid, settled) and what code runs it. Most mechanisms are contract-complete only and say so; a level is derived from evidence and never from configuration. Discovery and the first useful read need no wallet, no registration and no NET. Free, keyless, read-only, moves no money. Cost and signer: free and keyless, nothing to sign.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many to list, 1 to 46. Default 12.
familyNoOptional: only mechanisms of one family (SPEND, HOLD, EARN, MATCH, RECYCLE or SPECULATE).
objectiveNoWhat you want to do, 5 to 300 characters, e.g. 'get a second look at the proof a worker submitted'.

Output Schema

NameRequiredDescriptionDefault
okNo
toolNo
fundedNo
payUsdNo
workIdNo
claimIdNo
claimableNo
next_callNo
proofRuleNo
fulfillableByNo
definitionOfDoneNo
needs_from_callerNo
notClaimableReasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only annotations, it discloses important behavior: evidence-ladder levels are derived from evidence and never configuration, most mechanisms are contract-complete only, and discovery requires no wallet, registration, or NET. It also states the tool is free, keyless, read-only, moves no money, and requires nothing to sign.

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

Conciseness3/5

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

The core purpose is front-loaded, but the main sentence is dense and the access/cost information is repeated: free/keyless/read-only/no money appears in both the body and the closing cost-and-signer line. It is informative but could be tightened.

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?

Given the output schema and rich annotations, the description is complete enough for an agent to call it correctly: it explains the input intent, the returned evidence levels, what code runs mechanisms, and the wallet/registration-free access model.

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 description coverage is 100%, so the schema already documents limit, family, and objective. The description reinforces that the objective should be plain-language, but it does not add meaningful semantics for limit or family beyond the schema.

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 uses a specific verb-and-resource framing: it takes a plain-language objective and returns the NET programs and demand mechanisms that fit. It also distinguishes the output from a single-mechanism lookup by returning a set of programs with evidence levels and running code.

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?

It clearly describes when to use the tool: when the user can state a NET objective in plain words and wants matching programs and mechanisms. It also states access prerequisites, but it does not explicitly name sibling alternatives such as net_mechanism or net_review_evidence and when to use those instead.

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.

Resources