texas-rrc-wellbores

Server Details

Texas RRC oil & gas wellbores: API numbers, completion dates, depth, plug status

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 33 days
Last Tested: 2026-11-01 15:25
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-17 10:15 across 2 tools

Disambiguation5/5

The two tools are cleanly separated: describe_texas_wellbores returns metadata/schema with no records, while search_texas_wellbores returns actual rows. The description even instructs the caller to invoke describe first, eliminating any chance of misselection.

Naming Consistency5/5

Both names follow the same verb_noun snake_case pattern (describe_/search_) with a consistent domain suffix (texas_wellbores). The convention is predictable and unambiguous.

Tool Count3/5

Two tools is thin even for a read-only dataset service; the surface is essentially one discovery call plus one query call. It is defensible for a narrowly scoped lookup API, but leaves no room for variants such as single-record fetch or field-level filtering.

Completeness3/5

Read-only search plus schema description covers the core access pattern, and search supports several useful filters. However, there is no lookup-by-API-number/identity fetch, no aggregation or count operation, and the describe tool itself admits parts of the source are not yet parsed, so the surface is notably partial.

Available Tools

2 tools

describe_texas_wellboresDescribe the Texas RRC wellbore datasetAInspect

Free, no API key required. Describes the Texas Railroad Commission wellbore identity dataset decoded from RRC's EBCDIC mainframe corpus: the exact fields available, row count, freshness, pricing, and which parts of the source are NOT yet parsed. Returns no records. Call this before search_texas_wellbores.

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and discharges it: it discloses the auth profile (free, no API key), the non-mutating nature ('Returns no records'), and data-quality limits ('which parts of the source are NOT yet parsed'). Freshness and pricing are also surfaced, which an agent cannot infer from an empty schema.

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

Conciseness5/5

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

Three tight sentences with zero waste. The most decision-relevant facts (free, no key, no records, call before the search sibling) are all front-loaded before the detailed field list.

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?

With no output schema and no parameters, the description fully covers what the agent needs: access requirements, the nature of the return (metadata, not records), the specific metadata categories, and routing to the companion search 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?

The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly adds nothing about parameters because there is nothing to parameterize, keeping focus on the metadata payload.

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?

States a specific verb (describes) and resource (Texas RRC wellbore identity dataset), and enumerates the exact metadata returned: fields, row count, freshness, pricing, and unparsed source. It explicitly distinguishes itself from the sibling search_texas_wellbores by noting it 'Returns no records' and directing the agent to call it first.

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?

Gives an explicit routing rule: 'Call this before search_texas_wellbores,' which names the alternative tool and the condition selecting it. Access guidance ('Free, no API key required') is also front-loaded, leaving nothing to inference about when this tool is appropriate.

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

search_texas_wellboresSearch Texas RRC wellboresAInspect

Search Texas oil and gas wellbore identities by district, county, API number, plugged status, orphan-well hold, completion date range or minimum depth. FREE tier: up to 25 real decoded rows per call with no API key, so you can judge the data before paying. Asking for more than 25 rows or using offset requires a key and otherwise returns a payment_required error carrying a checkout URL.

Name	Required	Description
`limit`	No	Rows to return. Without a key the ceiling is 25; asking for more returns a payment_required error carrying the price.
`county`	No	Railroad Commission numeric COUNTY CODE (1-507), NOT a county name -- 'MIDLAND' is not accepted. Integer or numeric string. Call describe_texas_wellbores for the field reference.
`offset`	No	Pagination offset. Any non-zero offset requires a key.
`plugged`	No	True for plugged wellbores only, False for unplugged.
`district`	No	Railroad Commission district number, 1-14. Integer or numeric string.
`min_depth`	No	Minimum total depth in feet. Integer or numeric string.
`api_number`	No	Full API number, e.g. '42-007-01820'.
`completed_since`	No	ISO date, inclusive lower bound on completion_date.
`completed_before`	No	ISO date, inclusive upper bound on completion_date.
`orphan_well_hold`	No	True for wellbores under an orphan-well hold.

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the 25-row free-tier ceiling, that no API key is needed at that tier, that more rows or any offset require a key, and that the resulting error is payment_required with a checkout URL. This is exactly the kind of auth and paywall behavior an agent needs before invoking the tool.

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

Conciseness5/5

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

The description is front-loaded with purpose, then immediately states the free-tier constraint and payment behavior in two tight sentences. Every sentence earns its place, with no redundant restatement of schema details.

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?

Given no output schema, the description explains that rows are decoded and that free-tier rows are available for evaluation, which is sufficient for a search tool. It could say a bit more about the returned row shape or pagination beyond the offset key requirement, but the essential call-time context is present.

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 description coverage is 100%, so every parameter is already documented in the schema. The description enumerates the filter concepts but adds no syntax, validation, or interactive detail beyond what the schema already provides, making this a baseline 3.

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

Purpose4/5

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

States a specific verb (search) and resource (Texas oil and gas wellbore identities), and enumerates the filter dimensions, so the agent knows exactly what the tool retrieves. It does not explicitly name or contrast with the sibling describe_texas_wellbores, so sibling differentiation is left to inference.

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?

Gives clear context for when the tool is appropriate (filtering by district, county, API number, etc.) and explains the free-tier/key condition that governs usage. It does not name an alternative or spell out when-not-to-use conditions, but the operating context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 13, 2026

Changedsearch_texas_wellbores16 fields changed

addedInput schema / properties / api_number / description
```
Added value: +"Full API number, e.g. '42-007-01820'."
```

addedInput schema / properties / completed_before / description

Added value: +"ISO date, inclusive upper bound on completion_date."

addedInput schema / properties / completed_since / description

Added value: +"ISO date, inclusive lower bound on completion_date."

changedInput schema / properties / county / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / county / description

Added value: +"Railroad Commission numeric COUNTY CODE (1-507), NOT a county name -- 'MIDLAND' is not accepted. Integer or numeric string. Call describe_texas_wellbores for the field reference."

changedInput schema / properties / district / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / district / description

Added value: +"Railroad Commission district number, 1-14. Integer or numeric string."

changedInput schema / properties / limit / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / limit / description

Added value: +"Rows to return. Without a key the ceiling is 25; asking for more returns a payment_required error carrying the price."

changedInput schema / properties / min_depth / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / min_depth / description

Added value: +"Minimum total depth in feet. Integer or numeric string."

addedInput schema / properties / offset / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]

addedInput schema / properties / offset / description

Added value: +"Pagination offset. Any non-zero offset requires a key."

removedInput schema / properties / offset / type
```
Removed value: -"integer"
```

addedInput schema / properties / orphan_well_hold / description

Added value: +"True for wellbores under an orphan-well hold."

addedInput schema / properties / plugged / description

Added value: +"True for plugged wellbores only, False for unplugged."

2 tool updatesSep 28, 2026
- First observeddescribe_texas_wellbores
- First observedsearch_texas_wellbores

Related MCP Connectors

Pointer Minerals — Texas Oil & Gas Data A
com.pointerminerals
Read-only Texas oil & gas data: operator directory, county production, and dataset catalog.
Energy Open Data Government Data
61
https://mcp.pointerminerals.com/mcp
Well-Intel Drilling PermitsOAuth
app.wellintel
Drilling permits for TX, NM, OK and LA from state regulators. Free account; Pro adds same-day data.
Energy Government Data Databases
1
https://www.wellintel.app/api/mcp
Tx Dmv A
io.github.pipeworx-io
Texas DMV MCP — statewide vehicle, pickup and motorcycle registration totals by fiscal year, from…
Government Data Open Data
451
https://gateway.pipeworx.io/tx-dmv/mcp
Fracfocus A
io.github.pipeworx-io
fracfocus -- U.S. hydraulic fracturing chemical disclosures (fleet #2982).
Energy Open Data Government Data
471
https://gateway.pipeworx.io/fracfocus/mcp

Related MCP Servers

FracFocus MCP Server
Energy Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables AI agents to search U.S. hydraulic fracturing disclosure records — well-level frac job details (operator, API number, location, dates, base fluid volumes) and the disclosed chemical additives per job — by state, county, operator, or API number, plus lookups of where a given chemical has been used by CAS number. Responses include source, license, and coverage-window metadata so callers can distinguish missing data from out-of-window disclosures.
Updated 3 days ago (2026-10-29 03:33 UTC)
21 npm
MIT
gom-deepwater-radar
Energy Government Data Legal & Compliance
tudadada
A
license
A
quality
C
maintenance
Model Context Protocol (MCP) server for Gulf of Mexico deepwater intelligence: BSEE NTL 2019-G03 HPHT regulatory classification, API 17TR8 20,000 PSI qualification mandates, BOEM OCS protraction area intelligence, and subsea tie-back economic heuristics.
Updated a month ago (2026-09-30 03:14 UTC)
3
4 npm
MIT
mcp-data-texas
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables searching and querying Texas open data from data.texas.gov via the Socrata SoQL API, supporting dataset discovery, filtering, and metadata retrieval without an API key.
Updated 4 days ago (2026-10-29 02:43 UTC)
421 npm
MIT
teadata-mcp
Government Data Education & Learning Tools Open Data
adpena
A
license
A
quality
D
maintenance
MCP server for exploring Texas public school data through conversational interfaces, enabling campus search, district details, geospatial lookup, comparisons, and transfer insights using TEA data.
Updated 8 months ago (2026-03-10 19:37 UTC)
16
1
Apache 2.0