Skip to main content
Glama
Sign In

OpenNodes

by io.github.opennodes-io
OverviewDiscussionsAdmin

Recommend a node and model

recommend
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. Pass task (sent to this registry, which extracts features and discards the text) or features already extracted on your side with extractFeatures from @opennodes/core, which keeps the prompt private. 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.

Input Schema

NameRequiredDescriptionDefault
taskNoThe task description or the prompt itself. Sent to the registry for feature extraction; use `features` to keep it private. Give this or `features`.
policyNoOptional constraints and preferences for the recommendation.
featuresNoFeatures from extractFeatures(prompt) in @opennodes/core: task class, size, language and needs, no prompt text. Give this or `task`.
est_output_tokensNoExpected answer length in tokens, if known. Improves the cost estimate; otherwise inferred from the task.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / policy / properties / local_memory_gb / description
      Previous value: -"RAM/VRAM this machine can give a local model, in GB. Local models that cannot fit are left out, and the largest size that fits is picked (4-bit estimate). The local stdio server fills this from the machine when it is not given."New value: +"RAM/VRAM this machine can give a local model, in GB. Local models that cannot fit are left out, and the largest size that fits is picked (4-bit estimate). The local stdio server fills this from the machine when it is not given; otherwise catalogue models are scored for a typical 16 GB laptop, and none is picked."
  2. Changed1 schema field changed
    • changedInput schema / properties / policy / properties / region / description
      Previous value: -"Required data region, e.g. \"CA\" or \"EU\". Offerings pinned to, or served from, other regions are excluded."New value: +"Required data region, e.g. \"CA\" or \"EU\" (EU and EEA include their member states). Offerings pinned to, or served from, other regions are excluded, and so are hosted offerings with no known location; models on this machine or LAN always qualify."
  3. Changed1 schema field changed
    • changedInput schema / properties / policy / properties / region / description
      Previous value: -"Required data region, e.g. \"eu\". Offerings pinned to other regions are excluded."New value: +"Required data region, e.g. \"CA\" or \"EU\". Offerings pinned to, or served from, other regions are excluded."
  4. Changed1 schema field changed
    • addedInput schema / properties / policy / properties / local_memory_gb
      Added value: +{
+  "description": "RAM/VRAM this machine can give a local model, in GB. Local models that cannot fit are left out, and the largest size that fits is picked (4-bit estimate). The local stdio server fills this from the machine when it is not given.",
+  "minimum": 1,
+  "type": "number"
+}
  5. Changed1 schema field changed
    • addedInput schema / properties / policy / properties / jurisdiction
      Added value: +{
+  "description": "Only operators in this jurisdiction: \"eea\" or ISO country codes (\"DE,FI\"). Local and LAN models always qualify.",
+  "type": "string"
+}
  6. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint/openWorldHint/idempotentHint; the description adds real context beyond them, notably that `task` text is sent to the registry but discarded after feature extraction, while `features` keeps the prompt private, and that the cost estimate is pinned to the node's card revision. It does not cover latency, rate limits, or failure modes (e.g. what happens when no candidate satisfies the policy), which keeps it off 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 purpose, then usage, then input/return behavior, then alternatives — a sound order with no filler sentences. The prose is dense with inline code references and a long first sentence, which costs a little readability but not much.

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?

There is no output schema, so the description carries the return-value burden and does: ranked candidates with score components, a pinned cost estimate, an optional cheaper two-step scenario, and predicted MCP tool categories. Privacy handling and default behavior for local memory are also disclosed, which is what an agent needs for a 4-param recommendation tool.

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 baseline is 3; the description goes further by explaining the privacy semantics of choosing `task` versus `features` and naming the extractFeatures source, which is meaning the schema does not convey. It says nothing extra about `policy`, `est_output_tokens`, or how the two inputs interact when both are supplied, so it is not exhaustive.

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?

"Recommend the best AI node + model for a task" states a specific verb and resource, and the closing sentence explicitly separates this tool from search_offerings (browsing) and estimate (pricing a chain). An agent can route between the three siblings without opening any 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?

"Use this first when you know the task but not the model" gives an explicit entry condition, and the alternatives are named with the conditions that select them: search_offerings to browse, estimate to price a specific chain. Both the task-vs-features input paths are also framed as choices (privacy tradeoff).

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

All OpenNodes toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources