Skip to main content
Glama
Sign In

OpenNodes

by io.github.opennodes-io
OverviewDiscussionsAdmin

Find where models run

find_locations
Read-onlyIdempotent

Where AI models are served, by country: every known serving site (provider, region, city or facility, live or planned) with its evidence basis (claimed, documented, measured, attested), its source page, a map point (geo: lat, lon, precision; derived when only the region is known), and the models it serves. Sites whose provider publishes no model list are included with a note. Built from node cards, imported catalogs and curated location seeds. Use it to answer "which providers serve which models in Canada" or "what serves gpt-oss within 500 km of Montréal", or to check a residency requirement before choosing an offering; then search_offerings with region to pick one.

Input Schema

NameRequiredDescriptionDefault
nearNoA point as "lat,lon" in decimal degrees, e.g. "45.50,-73.57" for Montréal. Adds distance_km to each site and sorts nearest first.
basisNoMinimum evidence for a site: claimed < documented < measured < attested.
modelNoSubstring of a model name or artifact, e.g. "gpt-oss" or "command". Keeps only sites serving a match.
statusNoOnly live or only planned sites. Omit for both.
countryNoISO 3166 code; a country also matches its subdivisions, e.g. "CA" matches "CA-QC". Omit for every country.
residencyNoOnly sites covered by a residency commitment at least this strong: processing (inference and stored data stay in the area) or storage (data at rest only).
within_kmNoWith `near`: only sites within this great-circle distance. Sites known only to the country are excluded, since their point is a placeholder.
availabilityNoWith a residency filter: count only commitments offered this widely: default (every customer), opt_in (adds settings and regional endpoints), enterprise (adds contract-only offers; the default).
exclude_lineageNoComma-separated ISO country codes; drops models whose declared lineage includes any of them, e.g. "CN".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / availability
      Added value: +{
+  "description": "With a residency filter: count only commitments offered this widely: default (every customer), opt_in (adds settings and regional endpoints), enterprise (adds contract-only offers; the default).",
+  "enum": [
+    "default",
+    "opt_in",
+    "enterprise"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / residency
      Added value: +{
+  "description": "Only sites covered by a residency commitment at least this strong: processing (inference and stored data stay in the area) or storage (data at rest only).",
+  "enum": [
+    "processing",
+    "storage"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the read-only, open-world, idempotent profile, and the description adds substantive context beyond them: data provenance (node cards, imported catalogs, curated location seeds), the evidence ladder, inclusion of sites whose provider publishes no model list (with a note), and placeholder geo points marked `derived`. It also flags that country-only sites are dropped by distance filters, which is exactly the kind of caveat an agent cannot infer from annotations.

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?

It is front-loaded with the resource and its fields, then pivots to usage, which is the right order. The single dense paragraph with stacked parentheticals is heavy to parse, and the phrase 'Built from node cards, imported catalogs and curated location seeds' is the least load-bearing sentence, but nothing is truly redundant.

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?

With no output schema, the description usefully enumerates the returned fields (evidence basis, source, geo with precision, models served) and warns about derived/placeholder points, which is what an agent needs to interpret results. For a 9-parameter, zero-required filter tool it is nearly complete; only the relationship to find_residency is left unstated.

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 coverage is 100% and the parameter descriptions are already detailed (evidence ordering, residency strengths, availability tiers), so the schema carries most of the semantic load. The description contributes mainly by demonstrating parameter combinations in its example queries ('gpt-oss within 500 km of Montréal' implies near + within_km + model), which is a modest addition rather than new parameter meaning.

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 opening clause names a specific resource and scope ('every known serving site ... provider, region, city or facility, live or planned') and enumerates the attributes returned (evidence basis, source page, geo point, models served). This is clearly a location/site lookup, distinct from search_offerings (offerings) and find_residency (commitments), so an agent can route without opening the 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?

It gives concrete trigger questions ('which providers serve which models in Canada', 'what serves gpt-oss within 500 km of Montréal') and an explicit follow-up route: use search_offerings with `region` to pick an offering. The gap is that it also claims to support 'check a residency requirement' without acknowledging the sibling find_residency, leaving ambiguity about which of the two to call for residency questions.

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