WellState Labs SB 1150 Screening (read-only)

Get the plug record

get_plug_record

Read-onlyIdempotent

Returns the publication's plug record (contract 1.4.0 and later): W-3 plug dates on the Railroad Commission of Texas Full Wellbore file, counted by the calendar year the operator reported and by district, as published. Without a district it returns the statewide count for each year and each district's count for each year. With a district it returns that district's years with state-funded plug numbers, well types and district bases. With rows_limit it pages the per-wellbore rows one district and one year's count is made of, each with the line of the Full Wellbore file it was read from. Every response carries the publication's claims with their labels (DOCUMENTED_FACT, INFERENCE, UNKNOWN), the two UNKNOWN claims that travel with every count, and the publication's statement of what the record is not. This server computes no figure from these counts and combines none with the screening counts. On an edition without a plug record the plug_record field is null.

Input Schema

Name	Required	Description
`district`	No	A district key of the plug record: a Commission district (e.g. 08, 7C, 8A) or NOT_IN_SOURCE for wellbore-years the file gives no district. Omit for the statewide years and every district's counts.
`last_year`	No	Last calendar year returned. Default: the last year of the plug record's window.
`first_year`	No	First calendar year returned. Default: the first year of the plug record's window.
`rows_limit`	No	Per-wellbore rows to return, 0-200. Default 0 (counts only). Rows are served for one district and one year per call: pass district, and first_year equal to last_year.
`rows_offset`	No	Rows to skip before the first one returned, for paging. Default 0.

Output Schema

Name	Required	Description	Default
`note`	Yes
`terms`	Yes
`boundary`	Yes
`plug_record`	Yes
`contract_version`	Yes
`publication_root`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

addedOutput schema / properties / terms

Added value: +{
+  "const": "https://mcp.wellstatelabs.com/terms",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "boundary",
-  "publication_root",
-  "contract_version",
-  "note",
-  "plug_record"
-]New value: +[
+  "boundary",
+  "terms",
+  "publication_root",
+  "contract_version",
+  "note",
+  "plug_record"
+]

First observedOct 30, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful behavioral context beyond that: every response carries labeled claims (DOCUMENTED_FACT, INFERENCE, UNKNOWN), two UNKNOWN claims travel with each count, the server computes and combines nothing, and plug_record is null on editions without a plug record.

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

Conciseness3/5

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

The key scoping sentence is front-loaded, but the body is a dense run of long sentences covering district modes, paging, claims labels, null behavior, and disclaimers. It is informative rather than padded, yet the volume and lack of structure make it harder to scan than it needs to be.

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?

With an output schema present, return values need not be spelled out, and the description still covers null-field behavior, claims labeling, and non-computation guarantees. The one gap is that it never contrasts itself with the screening tools, leaving the agent to infer when to reach for it.

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 a baseline of 3 applies. The description adds real semantics on top: district omission vs. supply changes the shape of the result, and rows_limit requires district plus first_year equal to last_year to page per-wellbore rows, which clarifies the constraint that the schema only implies.

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 and resource ('Returns the publication's plug record') and immediately scopes what the record is: W-3 plug dates on the Railroad Commission Full Wellbore file, counted by reported year and district. It is clearly distinct from screening siblings, though it never names an alternative tool explicitly.

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?

Explicitly lays out three modes of use: no district → statewide year counts plus per-district counts; district → that district's years with state-funded plug numbers, well types and bases; rows_limit → per-wellbore rows for one district and one year. It does not name sibling tools or say when to prefer them, which keeps it below a 5.

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

All WellState Labs SB 1150 Screening (read-only) 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?