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

No annotations are provided, so the description carries the full burden. It discloses the behavior of handling different API formats (dashes, state prefixes) and the fallback matching strategy. It also reveals that if state is omitted, it iterates over all states, which implies potential performance implications. This is good coverage beyond what the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, which is concise and front-loaded with the main purpose. The first sentence defines the function and output. The second sentence adds important behavioral details about formatting tolerance and multi-state search. Some redundancy with the schema examples is present, but the description as a whole is tightly written without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (two parameters, one optional enum), the description covers everything an agent needs: the output format (raw + summary), the handling of input variations, the matching algorithm, and the behavior when state is omitted. No additional context is necessary for correct invocation.

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

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

The schema already provides a clear description of the api parameter (with examples) and the state parameter (with enum). The description adds nuance that the api parameter tolerates formatting differences and that state is optional but speeds up the lookup. This meaningfully enhances what the schema states, so a 4 is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the specific verb ('Look up') and resource ('a specific well by API number'), and clearly defines the output as the full raw record plus the normalized summary. It distinguishes itself from siblings like search_wells and wells_near by focusing on exact API lookup rather than broad search or proximity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly explains when to use this tool: to retrieve a specific well by API number, and even notes that omitting the state will try every state (slower, but still functional). While it doesn't name alternatives, it implies that for broader search one would use search_wells or wells_near, and for raw queries raw_query. The description of the matching fallbacks (exact, bare digits, contains-match) also guides usage in edge cases.

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

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

With no annotations, the description carries the behavioral burden. It usefully reveals that results are exact, case-insensitive name strings, distinct, 'containing the search text', and grouped 'per source'. However, it does not clarify what 'per source' means, whether state is required, or what the response shape looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, then behavior, then usage guidance. The quoted examples are slightly long but earn their place by illustrating the tool's core warning that operator strings rarely match guesses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, basic behavior, and a usage trigger, which is good for a simple lookup tool. However, without annotations or an output schema, the vague 'per source' wording and unaddressed state parameter leave meaningful gaps for an agent deciding how to call it correctly.

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

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

Schema description coverage is only 50%; the description does not meaningfully explain the 'state' parameter beyond 'a state uses' and 'per source'. The 'name' parameter is already described in the schema, but the optional state parameter's role and default behavior remain unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Find') and resource ('exact operator name strings a state uses') and makes the domain concrete with real examples. It clearly differentiates this tool from sibling search_wells by focusing on operator name strings rather than well records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly gives a usage context: 'Use before search_wells when an operator search returns nothing.' It names an alternative and the condition for choosing this tool, though it does not discuss exclusions for other sibling tools.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. The description explains it returns coverage, agency, searchable filters, and caveats, and frames the operation as non-mutating discovery. It does not detail error behavior or performance, but for a zero-parameter list operation this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the most useful instruction ('Call this first') included. Every word earns its place and the key content is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-parameter discovery tool, the description completely covers what an agent needs to know: what it will receive, why it should call it, and that it is the initial discovery step. No output schema or annotation gaps need compensation here.

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

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

There are no parameters Except for the schema's empty object, and schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline for a zero-parameter tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List'), a clear resource ('state regulator well-data sources'), and a scope ('this server can query'). It clearly distinguishes itself from search_tools and other list-like tools because it describes a catalog/discovery function, not a data query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly says 'Call this first to see what is available,' giving clear when-to-use guidance for discovery before querying. It does not explicitly mention alternatives or exclusions, but the context strongly implies this is the correct initial tool among the siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses that field names are the layer's own rather than normalized, and recommends querying where='1=1' limit=1 to inspect a record, which sets expectations about raw output. It could say more about read-only guarantees or error modes, but the main behavioral quirk is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences pack the tool's purpose, usage context, and field-name caveat without redundancy. The inline example 'where='1=1' limit=1' is a compact, actionable illustration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an escape-hatch tool with no output schema and no annotations, it gives an agent enough to call it correctly: how to choose source keys, how to discover valid fields, and what kind of filters it supports. Minor gaps remain around exact response shape and behavior when SQL is invalid, but the critical invocation steps are present.

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

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

Schema covers 60% of parameters with descriptions (where, source, out_fields). The description adds beyond the schema by advising list_sources for source keys and explaining that where-clause field names are raw and can be discovered via a probe query. It doesn't elaborate on limit/offset, but those are constrained with defaults in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'run a raw SQL-92 WHERE clause against one source's ArcGIS layer and get raw attributes back.' The 'Escape hatch' framing differentiates it from sibling search tools, making its role in the family immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly positions itself as a fallback: 'filters the normalized search does not cover (dates, depths, cumulative production).' It also directs the agent to list_sources for valid source keys and suggests a field-inspection technique, so when to use it and what to do first are clear.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses that filters are ANDed case-insensitive substrings, that data is local and offline, and that results are project/field level rather than well level. It does not describe response format or any limits, but the core query behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause earns its place: data source, tracker coverage, scope, filter behavior, performance characteristics, and citation requirement. The core purpose and exclusion are front-loaded before the supporting details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no annotations and no output schema, the description provides substantial context: data provenance, geographic coverage, project-level scope, match semantics, offline behavior, and citation obligations. It stops short of explaining result fields or how limit/radius parameters shape output, but it is detailed enough for an agent to select and invoke the tool correctly.

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

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

The schema already documents five of nine parameters with useful examples, and the description adds general filter semantics with 'Filters are ANDed, case-insensitive substrings'. Still, the main description does little to clarify limit, longitude, or radius_km on its own, so it only partially compensates for the 56% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'Search bundled Global Energy Monitor tracker data' and enumerates the exact trackers and coverage areas. It explicitly distinguishes itself from the well-level sibling tools by saying 'Project/field level, NOT well level', so an agent can tell it apart from search_wells and wells_near.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear context on when this tool is appropriate: for project/field-level searches over bundled GEM geothermal and oil & gas data, and it explicitly excludes well-level use. However, it never names sibling alternatives such as search_wells or raw_query, so the when-not guidance is implied rather than fully explicit.

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

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

With no annotations, the description carries the full burden, and it does well: it explains that terms are ANDed, that results return titles/DOIs/dates/links, and even warns about a false-match case ('cape station' also matching Cape Grim air station). It does not mention pagination, sorting, or auth/rate limits, but the disclosed search semantics are materially useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: scope, content types, key corpus examples, a query ambiguity warning, AND semantics, and return fields. It is front-loaded with the resource name and keeps all guidance relevant without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no output schema and no annotations, the description covers the essential invocation context: what is indexed, how to phrase queries, what results look like, and notable edge cases. Minor gaps such as row-count behavior and pagination are not likely to prevent an agent from calling the tool successfully.

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

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

Schema coverage is 50%: the query parameter has examples, but rows has only schema constraints with no description. The tool description compensates by explaining AND semantics and giving realistic query patterns, which adds meaning beyond the schema. It doesn't elaborate on rows behavior, but the schema's default/min/max plus the name make it reasonably self-evident.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: searching U.S. DOE-funded geothermal datasets via OSTI Data Explorer/GDR. It names the content types (well logs, stimulation data, microseismic) and cites concrete projects like Fervo Cape Station and Utah FORGE, which clearly separates it from sibling tools such as search_wells or search_gem_projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear context for when to use the tool: it is the source for GDR/Fervo/FORGE and international geothermal datasets, and it offers concrete query examples such as 'cape egs' or 'fervo'. It does not explicitly rule out alternatives or name when_not scenarios, but the domain-specific examples and scope make the intended use fairly unambiguous.

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

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

With no annotations supplied, the description carries the full behavioral burden and largely delivers: it discloses date normalization to ISO YYYY-MM-DD (or null), states that filters combine with AND, describes the returned record shape, and flags the performance cost of omitting state. It stops short of covering error behavior, rate limits, or what 'source-specific extras' concretely contain, so it's strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded paragraph that leads with purpose, then normalization, then filter semantics, then the count_only usage tip. Each sentence carries distinct information and nothing is redundant with the schema. It is dense, but that density is justified for a 12-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 12 parameters, no output schema, and no annotations, the description covers the essential ground: return format, date normalization, filter combination, and query sizing. Gaps include pagination semantics across multiple sources (offset/limit are only defined 'per source' in the schema) and the precise shape of multi-source results, which an agent would want when aggregating.

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

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

Schema description coverage is 100% with inline examples (e.g. 'Fervo', 'California Resources', 'CA-GEO'), so the schema already documents every parameter well. The description adds global semantics that enrich parameter understanding — AND-combination of filters and date normalization across returned fields — but does not extend per-parameter meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('Search state regulator well databases') and enumerates the exact search dimensions (operator, well/lease name, county, field, status, type). It further differentiates from get_well via the api parameter note ('For cross-state API lookup use get_well instead'), which explicitly carves out the sibling's territory. An agent can immediately tell what this tool does and how it relates to get_well.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives concrete usage direction: the api param steers exact API lookups to get_well, the state param advises preferring a state code to avoid slower all-state searches, and count_only is positioned as a way to size a query before pulling records. It does not, however, address when to reach for spatial sibling wells_near or raw_query over this tool, leaving part of the alternative routing implicit.

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

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

With no annotations provided, the description carries the full behavioral burden. It adds important non-obvious behavior: 'Searches the geographically relevant sources unless state/source is given.' This explains default source selection and how optional filters change behavior, which is valuable beyond the schema. It does not describe response format, but the core behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The core action and use case are front-loaded, and the source-selection behavior is stated compactly. Every clause contributes to an agent's understanding of when and how to call the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with six parameters and no output schema or annotations, the description covers the essential invocation context: what it finds, how it selects sources, and when to use it. It does not describe return shape or result limits, but those are less critical for correct invocation given the detailed schema and defaults.

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

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

Schema description coverage is only 17%, so the description must compensate. It does clarify the central parameters: lat/lon as the search point, radius_km as the search radius, and state/source as optional filters. The limit parameter is not mentioned, but its name and default make it inferable; the description still adds meaning for the most important parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Find'), a precise resource ('wells'), and a clear spatial criterion ('within a radius of a lat/lon point'). This distinguishes it from siblings like search_wells or get_well, and the example of pads/leases/project sites reinforces its intended scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives a clear use case ('all wells on or around a pad, lease, or project site') and explains when to narrow by state/source ('unless state/source is given'). It does not explicitly name alternatives or state when not to use this tool, but the context is clear enough for an agent to select it appropriately.

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