Skip to main content
Glama
opennodes-io

opennodes

Official
by opennodes-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Search inference offerings

search_offerings
Read-onlyIdempotent

Find AI inference offerings across OpenNodes registry and imported catalogs with optional filters for model, price, trust, speed, and capabilities; returns matching nodes and pricing details.

Instructions

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.

Input Schema

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed24 schema fields changedv0.1.1
    • 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"
+]
  2. First observedv0.1.0

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.

Deploy Server

Other Tools