Skip to main content
Glama
opennodes-io

opennodes

Official
by opennodes-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

# OpenNodes Protocol (ONP) — Draft 0.1

An open standard for discovering, invoking, and paying AI inference endpoints ("AI Nodes") across vendors — from frontier labs to a university GPU cluster — with bridges to MCP and WebMCP.

Status: Draft 0.1 (working proposal, 2026-08-20) — not affiliated with any standards body yet. Home: opennodes.io

The one-sentence pitch

MCP standardized how AI applications reach tools; the OpenAI API shape standardized how they invoke models; x402 standardized how machines pay each other — but nothing standardizes how a client finds an inference endpoint it doesn't already know about: what model it serves, how big it is, what hardware backs it, how well it benchmarks, what it costs per token, and whether it's up. ONP fills exactly that gap and composes the rest from existing standards.

Related MCP server: hive-mcp-depin

Documents

Start here

  • 00 — Project overview — the concept, architecture, implementation status, completed development stages, and next steps in one document.

Research (why this standard, and why now)

Specification suite

Development requirements

  • REQ-001 — Discovery Service (registry) — MVP registry: registration, admission battery, search, estimation, MCP surface; acceptance criteria.

  • REQ-002 — Test client — CLI + OpenAI-compatible gateway + MCP modes; compatibility matrix (Cursor, VS Code, Open WebUI…).

  • REQ-003 — Node Kit — reverse-proxy wrapper turning vLLM/Ollama/TGI into a conforming node: card generation, receipts, registration, self-test.

Install (published packages)

npx @opennodes/cli mcp --print-config   # discovery + advisor tools for Cursor / VS Code / Claude Desktop
npx @opennodes/cli gateway --port 4141  # OpenAI-compatible gateway with onp/auto routing; base URL http://127.0.0.1:4141/v1
npx @opennodes/registry                 # run a registry: web app + API + MCP on http://127.0.0.1:4300
npx @opennodes/ollama-router            # OpenNodes for Ollama: one Ollama endpoint over local + LAN + verified public models
pipx install onp-node                   # Node Kit: turn a vLLM / Ollama / TGI deployment into a conforming node

npm: @opennodes/core · @opennodes/cli · @opennodes/registry · @opennodes/ollama-router — PyPI: onp-node

OpenNodes for Ollama: one endpoint for local, LAN and verified public models

OpenNodes for Ollama (impl/packages/ollama-router): point Open WebUI, Continue, Zed, or the ollama CLI at OLLAMA_HOST=127.0.0.1:11435 and one model list spans your local Ollama, other machines on your LAN (plain Ollama servers or Node Kit nodes, auto-discovered via mDNS), and verified public nodes from the registry — with auto, auto-cheap, auto-fast, auto-quality, and auto-private (never leaves the LAN) routed by the advisor, pinned prices, budget caps, and signed receipts for public calls.

Implementation

  • schemas/open-node.schema.json — normative JSON Schema for the Node Card (Phase 0 deliverable).

  • impl/ — reference stack source (registry + fixture node + onp CLI/gateway); npm install && npm test in impl/.

  • node-kit/ — Python Node Kit (REQ-003): wraps any OpenAI-compatible engine (vLLM/Ollama/TGI) into a conforming node; cross-language e2e against the JS registry.

Ecosystem

Clients and products consuming ONP — independent of the standard, listed here for discovery:

  • Surge (desktop client, pre-release — Windows installer; macOS and Linux build from source) — a desktop "browser for MCP" and the reference OpenNodes client: the model picker is fed live from the registry (trust tier, measured latency, price), Auto runs the advisor on your machine to pick a node per prompt, and every call is pinned to the node's card revision and comes back with a signed receipt Surge verifies. A spend policy is on from first launch, a dashboard keeps the ledger, and one click switches to private mode (local Ollama and LAN only). The first client to span both discovery layers (models via ONP, tools via MCP).

    Surge: OpenNodes models with verified receipts, a spend dashboard and one-click private mode

  • Your client here — ONP is an open standard; any client can implement discovery via ONP-3 and invocation via ONP-4. Open a PR to be listed.

Design principles

  1. Standardize the gap, reuse the rest. ONP defines only the Node Card, the Registry API, and thin profiles binding existing standards together. Invocation is OpenAI-compatible; payment is x402/prepaid; identity is domain-based with optional DIDs; tool access is MCP.

  2. Registry as a protocol, not a place. Like the MCP Registry, ONP specifies an OpenAPI interface any registry can implement. Anyone can run a registry; clients can query several; a root "meta-registry" is a bootstrap convenience, not an architectural requirement.

  3. Metadata is claims + attestations. Nodes self-report; registries and third-party attesters verify (liveness probes, conformance tests, benchmark attestations as Verifiable Credentials). Rank is computed by registries from declared, transparent components — ONP standardizes the signal format, not the ranking formula.

  4. Curated trust tiers, permissionless entry. Anyone can publish a Node Card and register (Community tier). Paid production traffic concentrates in Verified/Attested tiers — this is the lesson of Bittensor/Akash vs. OpenRouter/HF.

  5. The client is the orchestrator. Multi-node scenarios, MCP bridging, and WebMCP access are client-side composition over standard primitives — ONP specifies the primitives and a portable scenario format, not an orchestration runtime.

Available Tools

5 tools
estimateEstimate the cost of a chainA
Read-onlyIdempotent

Pre-price an invocation chain BEFORE spending money. Each step is either a concrete offering ("node_id/offering_id") or a select query that picks the best match, plus expected input and output tokens. Returns per-step cost bounds in USD, the pinned card_revision that makes each estimate enforceable at invocation, and chain totals. Use it to compare routes or budget a multi-model pipeline; nothing is invoked or charged.

ParametersJSON Schema
NameRequiredDescriptionDefault
stepsYesSteps in execution order.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, yet the description adds real value: it states what is returned (per-step cost bounds in USD, the pinned card_revision, chain totals) and guarantees no invocation or charge. This is genuine behavioral context beyond the structured fields.

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?

Front-loaded with the key frame ('Pre-price an invocation chain BEFORE spending money') and three dense sentences that each carry information (step forms, return contents, usage). Slightly packed but nothing is wasted.

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?

No output schema, but the description compensates by naming the return payload (cost bounds, card_revision, totals) and the enforceability of the estimate. For a one-parameter nested tool this covers what an agent needs to call and interpret it, leaving only minor details like chain-size limits unstated.

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% (baseline 3), but the description adds conceptual meaning: each step is either a concrete offering or a `select` query that picks the best-ranked match, plus expected input/output tokens. This explains the dual-mode `steps` structure better than the schema alone, and ties `select` to search_offerings semantics.

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?

States a specific verb and resource: 'pre-price an invocation chain BEFORE spending money,' with the scope (chain, not single offering) and the two step forms made explicit. An agent can distinguish this cost-estimation tool from search_offerings/get_offering without opening either schema.

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?

Gives clear when-to-use: 'compare routes or budget a multi-model pipeline,' and notes the safety condition ('nothing is invoked or charged'). It references search_offerings implicitly ('same as search_offerings') but does not name a specific alternative for actually invoking the chain, so no explicit when-not routing.

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

get_nodeGet one nodeA
Read-onlyIdempotent

Who runs a node and how it has behaved: operator, country and regions, endpoints, declared hardware, trust tier and its history (verifications, suspensions, reinstatements, with reasons), recent registry probe results with an availability summary, and its offerings with context window and price. Use it to vet a provider before relying on it; take node_id from search_offerings, recommend or get_offering results. For one offering's full card, use get_offering.

ParametersJSON Schema
NameRequiredDescriptionDefault
node_idYesReverse-DNS node id, e.g. "io.opennodes.demo-node" or "import.openrouter.ai".
offering_limitNoMaximum offerings to list; imported catalogs can hold hundreds. `offerings_total` always gives the full count.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description goes beyond them by disclosing the returned payload in detail — trust-tier history with reasons, probe results with an availability summary, offerings with window and price — which is the useful behavioral context here since there is no output schema. It does not mention auth requirements or result-size limits, so it stops short of a 5.

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?

Front-loaded with the payload inventory, then usage and the sibling pointer, in two sentences with no filler. The first sentence is a dense compound list, but every clause names a returned field and earns its place.

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?

No output schema exists, so the description carries the full burden of describing returns — and it does so comprehensively while also routing to sibling tools. An agent has everything needed to call it correctly.

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 both parameters (node_id format, offering_limit cap) are fully documented in the schema. The description adds only the provenance of node_id, which the schema does not state — marginal but real value, so the baseline 3 holds.

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?

States a specific verb+resource (get one node) and then enumerates exactly what the record exposes: operator, regions, endpoints, hardware, trust tier and its history, probe results, offerings. It also names the sibling it is not (get_offering) so an agent can distinguish it without opening a schema.

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?

Explicit when-to-use ("vet a provider before relying on it"), an explicit input source ("take node_id from search_offerings, recommend or get_offering results"), and an explicit alternative for the adjacent case ("For one offering's full card, use get_offering"). Nothing is left to inference.

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

get_offeringGet one offeringA
Read-onlyIdempotent

Full detail for one offering: endpoints, pricing, serving capabilities (context window, supported features, languages, hardware), data policy, trust tier, and the registry's observed probe results. Take node_id and offering_id from search_offerings or recommend results.

ParametersJSON Schema
NameRequiredDescriptionDefault
node_idYesReverse-DNS node id, e.g. "io.opennodes.demo-node".
offering_idYesOffering id within that node, as returned by search_offerings.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so safety is covered without the description. The description goes further by enumerating the richness of the payload, including live 'registry's observed probe results', which tells the agent this is a heavy, authoritative retrieval rather than a cached summary.

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?

Two sentences, no filler, with the payload summary front-loaded and the input-sourcing instruction second. Every clause earns its place.

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 no output schema, the description carries the return-value burden and does so by listing the exact facets an agent would want (endpoints, pricing, context window, languages, hardware, data policy, trust tier, probe results). Nothing needed to invoke or interpret the tool is missing.

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% and both parameters carry examples, so the baseline is 3. The description adds provenance the schema cannot express — that node_id/offering_id must come from search_offerings or recommend output — which meaningfully reduces wiring mistakes.

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?

Specific verb+resource ('Full detail for one offering') followed by an explicit inventory of what that detail contains (endpoints, pricing, serving capabilities, data policy, trust tier, probe results). The singular 'one offering' naturally contrasts with the plural sibling search_offerings.

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?

Explicitly instructs where to source the inputs ('Take node_id and offering_id from search_offerings or recommend results'), which routes the agent correctly relative to those siblings. It does not, however, state any when-not condition or what to do if the ids are unknown/invalid.

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

recommendRecommend a node and modelA
Read-onlyIdempotent

Recommend the best AI node + model for a task, with an enforceable cost estimate and human-readable reasons. Use this first when you know the task but not the model. Features (task class, size, language, needs) are extracted LOCALLY from task and only those features are sent to the registry — the prompt never leaves this machine. Returns ranked candidates with score components, a cost estimate pinned to the node's card revision, an optional cheaper two-step scenario, and MCP tool categories the task likely needs. To browse instead, use search_offerings; to price a specific chain, use estimate.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYesThe task description or the prompt itself, e.g. "Translate this Polish contract to English and list the risks". Analysed locally; not sent.
policyNoOptional constraints and preferences for the recommendation.
est_output_tokensNoExpected answer length in tokens, if known. Improves the cost estimate; otherwise inferred from the task.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover readOnly/idempotent/openWorld, but the description adds substantial beyond-schema behavior: features are extracted LOCALLY and the prompt never leaves the machine; results are pinned to the node's card revision; returns ranked candidates with score components and an optional cheaper two-step scenario. This privacy and determinism context goes well past what annotations declare.

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?

Front-loaded with purpose, then when-to-use, then privacy mechanics, return shape, and sibling routing in five efficient sentences. Slightly dense with the returns enumeration, but every sentence earns its place and none is filler.

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 a 3-param tool with a nested policy object, no output schema, and read-only annotations, the description covers purpose, routing, privacy behavior, and return contents well. It omits error/failure modes (e.g. what happens when no candidates pass the filters) and turnaround/latency behavior, which a full 5 would address.

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 baseline is 3. The description adds meaning beyond the schema by clarifying that `task` is analysed locally and never sent, and that est_output_tokens improves cost estimation (matching the schema's hint). It doesn't extend the policy object semantics, which the schema already covers, so it lands just above baseline.

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?

States a specific verb+resource ('Recommend the best AI node + model for a task') with the value proposition (enforceable cost estimate, human-readable reasons). It explicitly distinguishes itself from siblings search_offerings (browse) and estimate (price a specific chain), so an agent can route correctly without opening schemas.

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?

Explicit when-to-use: 'Use this first when you know the task but not the model.' It also names both alternatives and the condition that selects each (browse vs price a chain). This is textbook when/when-not/alternatives coverage.

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

search_offeringsSearch inference offeringsA
Read-onlyIdempotent

Search AI inference offerings in the OpenNodes registry — registered nodes AND imported catalogs (OpenRouter, Hugging Face Inference Providers, models.dev, local nodes). All filters are optional and combine with AND. Returns { offerings, total }: each offering has node_id, offering_id, model, pricing (USD per MTok), trust tier, serving capabilities, measured probe results, and a rank explanation. Use get_offering for one offering's full card, recommend to let the advisor choose.

ParametersJSON Schema
NameRequiredDescriptionDefault
qNoFree-text match against the model metadata, offering id, and node id, e.g. "bielik" or "coder".
langNoLanguage with minimum grade, "<iso-code>[:basic|strong|native]", e.g. "pl:strong" or "de".
sortNorank = registry ranking (price, trust, reliability); price = cheapest input first; ttft = fastest first token; tps = highest throughput.rank
tierNoMinimum trust tier. unverified < community (passed automated checks) < verified (identity and context verified) < attested.
limitNoMaximum offerings to return; `total` still counts every match.
familyNoModel family or exact artifact, e.g. "llama-3.3" or "qwen3". Matches model.family or model.artifact exactly.
schemeNoPayment scheme the offering must accept. "free" finds no-cost offerings.
modalityNoWhat the model consumes/produces. Use "text" for chat and completion models.
supportsNoComma-separated features the offering must all support: tool_calls, json_mode, vision, streaming. Example: "tool_calls,json_mode".
min_contextNoMinimum context window in tokens, e.g. 32768.
max_input_priceNoMaximum input price in USD per million tokens.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds meaningful context the annotations cannot: the returned envelope ({ offerings, total }), the per-offering fields (pricing in USD per MTok, trust tier, probe results, rank explanation), and the breadth of the underlying catalog. It does not discuss rate limits or result ordering guarantees beyond the sort enum.

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?

Front-loaded with purpose and scope, then return shape, then sibling routing. Every sentence carries information, though the return-field enumeration sentence is dense and could be trimmed slightly.

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?

For an 11-parameter, no-required-args search tool with no output schema, the description compensates by naming the return envelope and key fields, plus the data sources searched. Nothing an agent needs in order to call it correctly is missing.

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 all 11 parameters in detail. The description only adds the AND-combination semantics of filters, which is a minor addition. Baseline 3 is appropriate where the schema does the heavy lifting.

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?

States a specific verb and resource ('Search AI inference offerings') and immediately scopes the corpus: registry nodes AND imported catalogs (OpenRouter, Hugging Face, models.dev, local). An agent can distinguish it from get_offering and recommend without opening either schema.

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?

Explicitly routes to alternatives with the selecting condition: 'Use get_offering for one offering's full card, recommend to let the advisor choose.' It also states that all filters are optional and combine with AND, removing ambiguity about call behavior.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.2
    • Addedget_node
  2. 4 tool updatesv0.1.1
    • Changedestimate16 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / steps / description
        Added value: +"Steps in execution order."
      • addedInput schema / properties / steps / items / additionalProperties
        Added value: +false
      • addedInput schema / properties / steps / items / properties / est_input_tokens / description
        Added value: +"Expected prompt tokens for this step."
      • addedInput schema / properties / steps / items / properties / est_input_tokens / minimum
        Added value: +0
      • changedInput schema / properties / steps / items / properties / est_input_tokens / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / steps / items / properties / est_output_tokens / description
        Added value: +"Expected completion tokens for this step."
      • addedInput schema / properties / steps / items / properties / est_output_tokens / minimum
        Added value: +0
      • changedInput schema / properties / steps / items / properties / est_output_tokens / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / steps / items / properties / offering / description
        Added value: +"Concrete offering as \"node_id/offering_id\". Give this or `select`."
      • addedInput schema / properties / steps / items / properties / select / additionalProperties
        Added value: +false
      • addedInput schema / properties / steps / items / properties / select / description
        Added value: +"Pick the best-ranked offering matching these filters (same as search_offerings). Give this or `offering`."
      • addedInput schema / properties / steps / items / properties / select / properties
        Added value: +{
+  "family": {
+    "description": "Model family or exact artifact, e.g. \"llama-3.3\" or \"qwen3\". Matches model.family or model.artifact exactly.",
+    "type": "string"
+  },
+  "lang": {
+    "description": "Language with minimum grade, \"<iso-code>[:basic|strong|native]\", e.g. \"pl:strong\" or \"de\".",
+    "type": "string"
+  },
+  "max_input_price": {
+    "description": "Maximum input price in USD per million tokens.",
+    "minimum": 0,
+    "type": "number"
+  },
+  "min_context": {
+    "description": "Minimum context window in tokens, e.g. 32768.",
+    "minimum": 1,
+    "type": "integer"
+  },
+  "modality": {
+    "description": "What the model consumes/produces. Use \"text\" for chat and completion models.",
+    "enum": [
+      "text",
+      "image",
+      "audio",
+      "video",
+      "embedding",
+      "multimodal",
+      "agent"
+    ],
+    "type": "string"
+  },
+  "q": {
+    "description": "Free-text match against the model metadata, offering id, and node id, e.g. \"bielik\" or \"coder\".",
+    "type": "string"
+  },
+  "scheme": {
+    "description": "Payment scheme the offering must accept. \"free\" finds no-cost offerings.",
+    "enum": [
+      "free",
+      "prepaid",
+      "x402"
+    ],
+    "type": "string"
+  },
+  "supports": {
+    "description": "Comma-separated features the offering must all support: tool_calls, json_mode, vision, streaming. Example: \"tool_calls,json_mode\".",
+    "type": "string"
+  },
+  "tier": {
+    "description": "Minimum trust tier. unverified < community (passed automated checks) < verified (identity and context verified) < attested.",
+    "enum": [
+      "unverified",
+      "community",
+      "verified",
+      "attested"
+    ],
+    "type": "string"
+  }
+}
      • addedInput schema / properties / steps / items / required
        Added value: +[
+  "est_input_tokens",
+  "est_output_tokens"
+]
      • addedInput schema / properties / steps / maxItems
        Added value: +20
      • addedInput schema / properties / steps / minItems
        Added value: +1
    • Changedget_offering5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / node_id / description
        Added value: +"Reverse-DNS node id, e.g. \"io.opennodes.demo-node\"."
      • addedInput schema / properties / node_id / minLength
        Added value: +1
      • addedInput schema / properties / offering_id / description
        Added value: +"Offering id within that node, as returned by search_offerings."
      • addedInput schema / properties / offering_id / minLength
        Added value: +1
    • Changedrecommend9 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / est_output_tokens / description
        Added value: +"Expected answer length in tokens, if known. Improves the cost estimate; otherwise inferred from the task."
      • addedInput schema / properties / est_output_tokens / minimum
        Added value: +1
      • changedInput schema / properties / est_output_tokens / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / policy / additionalProperties
        Added value: +false
      • addedInput schema / properties / policy / description
        Added value: +"Optional constraints and preferences for the recommendation."
      • addedInput schema / properties / policy / properties
        Added value: +{
+  "limit": {
+    "default": 3,
+    "description": "Number of candidates to return.",
+    "maximum": 20,
+    "minimum": 1,
+    "type": "integer"
+  },
+  "max_input_per_mtok": {
+    "description": "Maximum input price in USD per million tokens.",
+    "minimum": 0,
+    "type": "number"
+  },
+  "max_total_usd": {
+    "description": "Maximum estimated total cost of the call in USD.",
+    "minimum": 0,
+    "type": "number"
+  },
+  "min_tier": {
+    "description": "Exclude offerings below this trust tier.",
+    "enum": [
+      "unverified",
+      "community",
+      "verified",
+      "attested"
+    ],
+    "type": "string"
+  },
+  "prefer_local": {
+    "description": "Give a bonus to nodes on this machine or LAN.",
+    "type": "boolean"
+  },
+  "preset": {
+    "description": "Weighting preset: cheap favours price, fast favours latency/throughput, quality favours model strength, private favours trust tier.",
+    "enum": [
+      "cheap",
+      "fast",
+      "quality",
+      "private"
+    ],
+    "type": "string"
+  },
+  "region": {
+    "description": "Required data region, e.g. \"eu\". Offerings pinned to other regions are excluded.",
+    "type": "string"
+  }
+}
      • addedInput schema / properties / task / description
        Added value: +"The task description or the prompt itself, e.g. \"Translate this Polish contract to English and list the risks\". Analysed locally; not sent."
      • addedInput schema / properties / task / minLength
        Added value: +1
    • Changedsearch_offerings24 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / family / description
        Added value: +"Model family or exact artifact, e.g. \"llama-3.3\" or \"qwen3\". Matches model.family or model.artifact exactly."
      • addedInput schema / properties / lang / description
        Added value: +"Language with minimum grade, \"<iso-code>[:basic|strong|native]\", e.g. \"pl:strong\" or \"de\"."
      • addedInput schema / properties / limit / default
        Added value: +50
      • addedInput schema / properties / limit / description
        Added value: +"Maximum offerings to return; `total` still counts every match."
      • addedInput schema / properties / limit / maximum
        Added value: +200
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • changedInput schema / properties / limit / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / max_input_price / description
        Added value: +"Maximum input price in USD per million tokens."
      • addedInput schema / properties / max_input_price / minimum
        Added value: +0
      • addedInput schema / properties / min_context / description
        Added value: +"Minimum context window in tokens, e.g. 32768."
      • addedInput schema / properties / min_context / minimum
        Added value: +1
      • changedInput schema / properties / min_context / type
        Previous value: -"number"New value: +"integer"
      • addedInput schema / properties / modality / description
        Added value: +"What the model consumes/produces. Use \"text\" for chat and completion models."
      • addedInput schema / properties / modality / enum
        Added value: +[
+  "text",
+  "image",
+  "audio",
+  "video",
+  "embedding",
+  "multimodal",
+  "agent"
+]
      • addedInput schema / properties / q / description
        Added value: +"Free-text match against the model metadata, offering id, and node id, e.g. \"bielik\" or \"coder\"."
      • addedInput schema / properties / scheme / description
        Added value: +"Payment scheme the offering must accept. \"free\" finds no-cost offerings."
      • addedInput schema / properties / scheme / enum
        Added value: +[
+  "free",
+  "prepaid",
+  "x402"
+]
      • addedInput schema / properties / sort / default
        Added value: +"rank"
      • addedInput schema / properties / sort / description
        Added value: +"rank = registry ranking (price, trust, reliability); price = cheapest input first; ttft = fastest first token; tps = highest throughput."
      • addedInput schema / properties / sort / enum
        Added value: +[
+  "rank",
+  "price",
+  "ttft",
+  "tps"
+]
      • addedInput schema / properties / supports / description
        Added value: +"Comma-separated features the offering must all support: tool_calls, json_mode, vision, streaming. Example: \"tool_calls,json_mode\"."
      • addedInput schema / properties / tier / description
        Added value: +"Minimum trust tier. unverified < community (passed automated checks) < verified (identity and context verified) < attested."
      • addedInput schema / properties / tier / enum
        Added value: +[
+  "unverified",
+  "community",
+  "verified",
+  "attested"
+]
  3. 4 tool updatesv0.1.0
    • First observedestimate
    • First observedget_offering
    • First observedrecommend
    • First observedsearch_offerings
Deploy Server
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation4/5

Each tool has a fairly distinct role: search_offerings browses, get_node and get_offering drill into details, recommend picks a model, and estimate prices a chain. The two pairs (search vs recommend, get_node vs get_offering) could be momentarily confused, but descriptions explicitly cross-reference each other ('Use get_offering for one offering's full card', 'To browse instead, use search_offerings'), which resolves most ambiguity.

Naming Consistency3/5

Three tools follow a verb_noun pattern (search_offerings, get_node, get_offering), but estimate and recommend are bare verbs, so the convention is mixed. Names remain readable and predictable enough to guess intent, but the set is not uniformly patterned.

Tool Count5/5

Five tools is well within the ideal range and each covers a distinct facet of the registry/advisory workflow: browse, node details, offering details, recommend, and estimate. Nothing appears redundant or padded, and the scope (advisory/pricing, not invocation) justifies the count.

Completeness4/5

The surface covers discovery (search_offerings), provider vetting (get_node), offering detail (get_offering), recommendation (recommend), and cost projection (estimate), which is a coherent advisory lifecycle. Minor gaps exist—no direct comparison or bulk listing tool beyond search/recommend—but agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • hive-mcp-compute

    srotzin
    A
    license
    Not graded
    quality
    C
    maintenance
    OpenAI-compatible inference broker that routes AI requests to the cheapest qualifying model and settles payments per token in USDC on Base L2 via x402 micropayments.
    MIT

  • Kairos Signal MCP Server

    OV3RK177
    A
    license
    A
    quality
    B
    maintenance
    Enables AI agents to access verifiable DePIN supply-side telemetry, browse and purchase data products using credits, query datasets, and verify data provenance with cryptographic and zero-knowledge tools.
    10
    386 npm
    MIT
  • GateCore by GateCoreAI-com

    GateCoreofficial

    GateCoreAI-com
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to discover governed capabilities, inspect machine-readable contracts, and request policy-checked procurements with signed receipts and audit trails.
    Apache 2.0