osint

Query Power Asset Ownership

query_power_asset_ownership_v1

Read-onlyIdempotent

Query verified annual EIA-860 generator ownership.

Returns the Owner schedule's raw owner names and ownership shares for each eia_plant_id + generator_id. percent_owned is the workbook's raw fraction of one (0.6 = 60%), not a whole-number percent. Filter by plant, generator, exact raw owner name, state, owner state, annual vintage, or source-reported balancing authority code; {"state":"TX","balancing_authority_code":"ERCO"} returns an ERCOT slice in one call. Owner-name matching is exact and intentionally performs no normalization or entity resolution.

Critical EIA convention: the Owner schedule contains only jointly owned generators and generators wholly owned by an entity other than the operator. A generator absent from it is wholly owned by the operator in that same annual EIA-860 Generator schedule. An exact plant+generator query exposes this as ownership_resolution; it does not fabricate an Owner row or a 1.0 source share. Annual vintages remain independently queryable. Every returned share cites its exact ZIP member, sheet, row, and Percent Owned cell for SHA-256 verification.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

Discloses behavioral traits beyond annotations: raw fraction format, exact owner-name matching without normalization, EIA convention for omitted generators, and citation with SHA-256 verification. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent with the description.

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?

Well-structured with front-loaded purpose and detailed sections. Length is justified by the complexity of EIA conventions and filtering options, but could be slightly more concise.

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?

Given the complexity of the domain (EIA ownership conventions, verification), the description covers all necessary aspects: return values, filtering, edge cases (absent generators), and data provenance. The presence of an output schema is noted, but the description adds valuable context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description lists all filterable fields (plant, generator, owner name, state, etc.) with an example, fully compensating for the sparse schema. It adds meaning beyond the generic 'params' object.

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?

Clearly states it queries verified annual EIA-860 generator ownership, specifying the resource (power asset ownership) and output (raw owner names and shares). Distinguishes from sibling query_ tools by focusing on ownership data.

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?

Provides explicit filtering options (plant, generator, owner name, state, etc.), an example query, and critical EIA convention details about which generators appear. Gives clear guidance on when to use and what to expect, including the absence of fabricated rows.

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

All osint tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Each capability has a clearly named describe/query pair, and domains like power, AI infrastructure, robotics, and space are distinct. The generic describe_capability_v1/query_capability_v1 could be confused with the named variants, and the many ISO-specific interconnection queues share similar names, but descriptions explicitly disambiguate them.

Naming Consistency5/5

All tools follow a consistent lowercase snake_case verb_noun pattern: describe_<capability>_v1 and query_<capability>_v1, with a few utility tools like list_capabilities_v1 and get_source_evidence_v1. There is no mixing of conventions.

Tool Count2/5

At 62 tools, the set is far too large for typical server scope. The describe/query pairs inflate the count even though each is justified, and the generic capabilities plus per-ISO variants make it feel heavy and hard to navigate.

Completeness4/5

The server covers each domain thoroughly with describe, query, and evidence verification, plus generic fallbacks for capabilities not yet in the client's tool list. Minor gaps exist (e.g., no county/state attribution for some data, no load types in ISO queues) but they are explicitly documented and workable.

Resources

Need Help?