Skip to main content
Glama
Sign In

texas-rrc-wellbores

by com.tppflow
OverviewDiscussionsAdmin

Search Texas RRC wellbores

search_texas_wellbores

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.

Input Schema

NameRequiredDescriptionDefault
limitNoRows to return. Without a key the ceiling is 25; asking for more returns a payment_required error carrying the price.
countyNoRailroad 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.
offsetNoPagination offset. Any non-zero offset requires a key.
pluggedNoTrue for plugged wellbores only, False for unplugged.
districtNoRailroad Commission district number, 1-14. Integer or numeric string.
min_depthNoMinimum total depth in feet. Integer or numeric string.
api_numberNoFull API number, e.g. '42-007-01820'.
completed_sinceNoISO date, inclusive lower bound on completion_date.
completed_beforeNoISO date, inclusive upper bound on completion_date.
orphan_well_holdNoTrue for wellbores under an orphan-well hold.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema 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. First observed

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.

All texas-rrc-wellbores 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