Tensorust Ontology

Query the ontology (search or graph)

query_ontology

Read-only

Read-only, parameterized query over the Tensorust Ontology (no query language, nothing to inject). Search mode: filter objects by name (match contains | prefix | exact), type (Organization, ControlGroup, FCCLicense, Sanction, PAC, Rule), rule (objects a federal rule applies to: ROAD-1001, DFARS-FOCI, FCC-FAC, FCC-FAC-FLAG, CBAND-LUMP, ERATE-LATEINV, OFAC-SDN) with an optional rule status, min_sources (objects found in N+ public data sources) and min_links; sort by relevance, sources, links or name; returns total, a page of rows {oid, name, type, sources, links, status} and next_offset. Graph mode: from= lists that object's links with counts; add link (OWNS, HOLDS, RECEIVED, MEMBER_OF, SUBSIDIARY_OF, SUBJECT_TO, APPLIED, SERVES, BORROWS, LENDS_TO, SANCTIONED, LOBBIES_FOR, HAS_PAC, FILED) and direction (out | in) to page the linked objects. Pages are 10 rows by default, 25 max (100 with a Tensorust key). Errors say exactly which value to send. Call describe_schema first if unsure. Free.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_ontology"
  }
}

Input Schema

Name	Required	Description
`from`	No	Graph mode: an object id from a search row, e.g. 'org:LOCKHEED MARTIN', 'cg:632693'.
`link`	No	Graph mode: which link to list.
`name`	No	Text to match on object names; case and punctuation are ignored. e.g. 'blackstone', 'Lockheed Martin'
`rule`	No	Only objects this federal rule applies to (call describe_schema for each rule's meaning and statuses).
`sort`	No	Default relevance: exact name matches first, then by sources and links.
`type`	No	Only objects of this type.
`limit`	No	Rows per page, default 10; max 25 without a key, 100 with one.
`match`	No	How name matches. Default contains.
`offset`	No	Paging offset from next_offset. The free tier sees the first 100 matches (25 for a rule list, 10 linked objects).
`status`	No	With rule: one of that rule's statuses, e.g. 'applies', 'listed', 'likely', 'action_by_2026-11-12'.
`direction`	No	Graph mode: out = this object -> others (default); in = others -> this object (e.g. subsidiaries of a parent: link SUBSIDIARY_OF, direction in).
`min_links`	No	Only objects with at least this many links.
`min_sources`	No	Only objects present in at least this many public data sources (cross-source entities are the best-resolved).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, and the description adds substantial context beyond them: no query language so "nothing to inject," the exact return envelope (total, rows, next_offset), page sizes (10 default, 25 max, 100 with a key), free-tier result caps (100 matches, 25 for rule lists, 10 linked objects), and that errors name the offending value. That is unusually rich disclosure for a read tool.

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?

The read-only guarantee and the two modes are front-loaded, and nearly every clause carries operative information (enums, defaults, caps). It is a single dense block that packs a lot into one paragraph, making it harder to scan than a short bulleted mode split, but there is little genuine filler.

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 a 13-parameter, dual-mode tool with no output schema, the description covers what an agent needs: how to enter each mode, what the row shape and paging fields are, the limits on paging and free-tier result depth, and where to go for rule semantics. Nothing essential to a correct call appears to be 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%, so the baseline is 3, but the description adds real value by grouping the 13 parameters into search-mode vs graph-mode sets and showing cross-parameter dependencies (status only meaningful with rule; link and direction only with from). It also explains sort's default ordering and how offset relates to next_offset. The per-parameter detail largely remains in the schema, so it falls short of a 5.

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 opens with a specific verb and resource ("Read-only, parameterized query over the Tensorust Ontology") and then splits the tool into two named modes, search and graph, enumerating the filters each supports. An agent can tell this apart from narrower siblings like search_organizations or get_object 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mode selection is clearly implied: use search fields (name/type/rule/min_sources/min_links/sort) to filter objects, and use from=<oid> plus link/direction to page links. It also routes the agent to describe_schema "if unsure" and for rule meanings. It stops short of explicitly stating when to prefer this over sibling tools such as search_organizations or get_object, so it is not a full when/when-not/alternatives statement.

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

All Tensorust Ontology tools Inspect

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

Need Help?