An MCP server that gives any MCP-capable agent (Claude Desktop, Cursor, and compatible clients) direct access to a keyless public-data API — no signup, no API key, no accounts.
Built and operated by an autonomous AI agent that pays for its own compute.
Tool | Cost | What it returns |
| free | Current Base L2 gas fee (gwei) — useful for costing a payment before making it |
| free | Recent worldwide earthquakes (USGS), magnitude-ordered |
| free | Live position/altitude of the ISS |
| free | Temperature, wind, condition for a lat/lon |
| free | Live verse composed from weather + nearest quake + ISS at a coordinate |
| x402 (USDC on Base) | Fused exposure brief for a coordinate |
The paid tool returns the standard HTTP 402 challenge. This server never touches your wallet — your own x402 client pays and retries.
Related MCP server: earthquake-mcp-server
pip install pubdata-mcp{
"mcpServers": {
"pubdata": {
"command": "pubdata-mcp"
}
}
}Claude Desktop config lives at ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows).
No other setup. Stdlib-only, Python 3.9+.
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}python3 -m pubdata_mcpOpen-Meteo (weather), USGS (earthquakes), wheretheiss.at (ISS), Base RPC (gas). Public, keyless, no personal data collected or stored.
Coordinates (and the values) you send are forwarded to the API host at
13-62-217-51.sslip.io to answer the call. Nothing is logged there, nothing is
stored, and no personal data is collected or shared. If you would rather not send a
coordinate anywhere, use base_fee and iss, which need none.
The paid tool risk_brief never touches your wallet — it returns the HTTP 402
challenge for your x402 client to pay. Even so, this server refuses to hand
out pay-and-retry instructions (and once blocked, the challenge itself is withheld — no pay_to, no amount, no how-to-pay) once the authorised spend for that tool would
exceed a local cap:
lifetime cap (not daily): 0.10 USDC total across the life of the state file (PUBDATA_MCP_MAX_SPEND_USDC to change, delete the state file to reset)
state file: ~/.pubdata-mcp-spend.json
unknown or non-positive price in a challenge → refused (fail closed)
check anytime with the free spend_status tool
Worst-case spend is therefore bounded even if the driving agent loops.
Current Base L2 gas fee estimate (gwei), for costing x402 payments before making them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the chain, the unit, and the fact that the value is a live estimate rather than a fixed constant, but says nothing about staleness, caching, refresh cadence, or what limits apply — relevant for a fee oracle whose value moves block to block.
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?
One sentence, front-loaded with the resource and unit before the intended use. Every clause earns its place; there is no 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 zero-parameter read tool with no annotations and no output schema, the description supplies the essentials: what is measured, the unit, and the purpose. It stops short of saying whether the return is a single number or a breakdown by speed tier, which matters when costing a payment.
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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate on the input side, and it correctly spends no words doing so.
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 resource (Base L2 gas fee), a concrete unit (gwei), and the value it represents (current estimate). The description resolves the ambiguity of the bare name 'base_fee' and cannot be confused with any of the unrelated siblings (iss, earthquakes, weather, postcard, spend_status, risk_brief).
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?
"For costing x402 payments before making them" gives an explicit when-to-use trigger, which is exactly the decision an agent needs. No alternatives or exclusions are named, but no sibling tool plausibly competes for this job, so the omission is low-risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent earthquakes worldwide (USGS), magnitude-ordered, with place, time and coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window to summarise (default: day). | |
| min_magnitude | No | Drop quakes below this magnitude. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose useful traits beyond the schema: the upstream source (USGS), the result ordering (magnitude-ordered), and the returned fields (place, time, coordinates). It does not state result limits, pagination, or refresh/rate behavior, which are the main unanswered questions for a feed-style tool.
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?
A single dense sentence with the resource, source, ordering and returned fields front-loaded; every clause earns its place and there is no boilerplate.
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?
There is no output schema, so the description must convey the return shape, and it does list the key fields and ordering. It omits magnitude as a returned field (only implied) and says nothing about result count, which keeps it just short of fully complete for a feed tool.
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%, so both parameters (window, min_magnitude) are already documented with defaults and enum values. The description only loosely gestures at the time window via 'recent' and adds nothing about the magnitude filter, so the baseline 3 applies.
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?
Names a specific resource (recent earthquakes worldwide), its source (USGS), and its ordering, so an agent knows exactly what data comes back. The verb is implicit (list/retrieve) rather than stated, and there is no sibling that competes for the same data, so no differentiation is needed or provided.
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?
Usage is only implied by the scope words 'recent' and 'worldwide'; there is no explicit when-to-use statement, no prerequisites, and no alternatives named. Since no sibling tool covers seismic data, the lack of routing guidance is a minor gap rather than a misleading one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current position and altitude of the International Space Station.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 one behavioral trait, that the data reflects the present moment ('Current'), which tells the agent results are time-sensitive, but it says nothing about update frequency, rate limits, or response format.
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?
A single front-loaded sentence with no filler. Every word earns its place and the key noun (International Space Station) and payload (position and altitude) come first.
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?
With no output schema, the description must signal what comes back, and it does so by naming position and altitude. It stops short of describing the coordinate format or units, which is a minor gap for a zero-parameter read tool.
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 tool takes zero parameters, so per the baseline rule this scores 4. The description correctly adds no parameter detail, which is appropriate for a parameterless call.
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 names the resource (International Space Station) and the exact data returned (current position and altitude), which is far more informative than the opaque name 'iss'. It does not differentiate from siblings, but the sibling set (base_fee, earthquakes, weather, postcard) is so disjoint that no differentiation is needed.
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?
There is no explicit when-to-use or when-not-to-use guidance, but the tool's purpose is unambiguous and there are no competing siblings that could be confused with it, so usage is implied. The word 'Current' hints at time-sensitivity but no guidance is given about refresh or staleness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A few lines of live verse composed from the weather, the nearest recent earthquake and the ISS position at a coordinate. Human-legible; nice for demos.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that output is 'human-legible' verse and is a live composition, but says nothing about read-only nature, error handling for invalid coordinates, or rate limits. It adds some context but leaves gaps for a tool with zero annotation coverage.
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?
A single sentence plus a short qualifier, with the core capability front-loaded and no wasted words. Well sized for the tool's simplicity.
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 two-parameter demo tool with no output schema or annotations, the description conveys enough to call it correctly: what goes in (a coordinate) and what comes out (a few lines of verse). Only minor gaps around coordinate format and error behavior remain.
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 0% for both lat and lon, so the schema contributes no meaning. The description only says 'at a coordinate,' hinting that lat/lon are geographic but adding no format, range, or ordering detail; it partially compensates but not fully.
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 concrete output (a few lines of live verse) and the inputs it synthesizes from (weather, nearest recent earthquake, ISS position at a coordinate), so an agent can tell it is a generative/synthesis tool. It is clearly distinct from the granular siblings like weather, earthquakes, and iss, though it never explicitly says it aggregates them.
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 phrase 'nice for demos' implies a light, presentational context, which is weak usage guidance. There is no statement of when to prefer this over the raw weather/earthquakes/iss siblings, and no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID (x402, USDC on Base): a single fused brief for a coordinate — weather, nearest seismic activity and an exposure summary. Calling it returns the HTTP 402 challenge; pay with your x402 client and retry. This MCP server never touches your wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the x402/USDC-on-Base payment requirement, the exact behavior of the first call (HTTP 402 challenge), the required client-side retry, and a custody guarantee ('never touches your wallet'). It omits cost amount and any retry/rate-limit specifics.
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, front-loaded with the PAID warning, then the payload, then the payment mechanics. No filler; each sentence adds information.
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 paid, non-annotated tool with no output schema, it covers what matters most: what is returned (fused weather/seismic/exposure) and the 402-then-pay-then-retry flow. Missing cost magnitude and post-payment response shape are minor given the succinct scope.
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 0% for two required parameters, so the description must compensate. It only implies the pair is 'a coordinate' — no units, coordinate order, or valid range — which adds almost nothing beyond the self-evident lat/lon names.
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+resource: a single fused brief for a coordinate, explicitly enumerating its contents (weather, nearest seismic activity, exposure summary). This clearly distinguishes it from the raw `weather` and `earthquakes` siblings, though it never names them as alternatives.
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 payment/retry flow is spelled out, but there is no explicit when-to-use guidance versus the cheaper `weather`/`earthquakes` tools, nor when the fused brief is preferable. Usage is only implied by the composite contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show this MCP server's local x402 spend cap: cap, amount authorised so far, and remaining. Use it to decide before calling a paid tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does add genuine value by clarifying the cap is local to this MCP server (not an on-chain balance) and that it reports authorised-so-far vs. remaining, but it never states that the call itself is free/read-only, nor any permission or freshness caveats.
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 identity of the resource front-loaded and the usage cue placed second. Every clause earns its place.
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?
With no output schema, the description correctly compensates by naming the three returned values (cap, authorised, remaining). It is close to complete for a trivial no-arg tool, though it omits units/currency and any indication of whether the reading can be stale.
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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate beyond the absence of inputs.
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?
Specific verb ("Show") plus a precisely scoped resource ("this MCP server's local x402 spend cap"), and it enumerates the three values returned. None of the siblings (weather, earthquakes, iss, etc.) overlap, so there is no ambiguity about which tool handles spend status.
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 states the triggering context: "Use it to decide before calling a paid tool." That is clear when-to-use guidance, though it does not name which sibling tools are the paid ones or state any exclusion, so it falls short of a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live weather for a coordinate: temperature, wind, and a condition word.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | -90..90 | |
| lon | Yes | -180..180 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses the fields returned (temperature, wind, condition) and that data is live, but says nothing about units (Celsius vs Fahrenheit, km/h vs mph), data freshness/caching, or failure behavior for out-of-range or ocean coordinates — meaningful gaps for a data-fetch tool.
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?
A single front-loaded sentence with zero filler: it leads with the resource, scopes it with "Live," and enumerates return fields. Nothing is wasted and nothing important is buried.
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 two-parameter read tool with no output schema, the description steps in to name the return fields, which is exactly the right compensation. The only real omission is measurement units and freshness semantics.
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% and both parameters carry explicit range documentation (-90..90, -180..180), so the schema already does the heavy lifting. The description only reinforces that lat/lon form a "coordinate" and adds no format, precision, or ordering detail beyond the schema — baseline 3.
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-phrase and resource ("Live weather for a coordinate") and enumerates what comes back (temperature, wind, condition word). It is immediately distinguishable from the siblings (base_fee, iss, earthquakes, postcard, spend_status, risk_brief), though it doesn't explicitly name them or contrast — unnecessary here since none are weather tools.
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 word "Live" implicitly scopes this to current conditions rather than forecasts or historical data, which is the only usage distinction an agent needs. However, there is no explicit when-to-use statement, no note about alternatives for forecasts/history, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.0base_feeearthquakesisspostcardrisk_briefspend_statusweatherScored across 7 tools
Most tools map to a distinct data source (base_fee, iss, earthquakes, weather) or payment concern (spend_status). The only mild overlap is between postcard and risk_brief, which both fuse weather + seismic + ISS/coordinate data; descriptions differentiate them (free novelty verse vs. paid exposure brief), but an agent could still hesitate between the two fusion tools.
All names are lowercase snake_case (base_fee, spend_status, risk_brief) with no camelCase mixing, which is predictable. However, they are noun/endpoint style rather than a clear verb_noun convention, and the bare acronym 'iss' breaks the compound-word pattern slightly.
Seven tools is well-scoped for a read-only public-data server: four raw data sources, one composite demo tool, one paid fused brief, and one payment-cap status check. Each tool has a clear reason to exist and nothing feels padded.
For a read-only data domain the surface is solid: raw feeds, a fusion tool, and x402 payment-costing/status tools. Minor gap is the lack of any spend-cap management or authorization operation (spend_status is read-only), and no batch/coordinate-list variant, but core workflows are coverable.
Real-world data for agents: air quality, geocoding, quakes, holidays, web search
Real-time data feeds for AI agents with USDC micropayments on Base for premium tools.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
US weather & geo for AI agents: forecasts, alerts, earthquakes, elevation, geocoding. No keys.
