Skip to main content
Glama
cliwant

mcp-sam-gov

bea_regional_data

Read-only

Retrieve county, state, or MSA GDP by industry and personal income from BEA Regional Economic Accounts. Requires a free BEA API key.

Instructions

Regional (county / state / MSA) GDP by industry and personal income from the BEA Regional Economic Accounts (apps.bea.gov/api/data, dataset 'Regional'). ★REQUIRES a free BEA_API_KEY — NO keyless tier; without the key this tool THROWS an honest config error (get one at https://apps.bea.gov/API/signup/; call api_key_status to check). Input: tableName (required, e.g. 'CAGDP2' county GDP, 'SAGDP2N' state GDP, 'CAINC1'/'SAINC1' personal income), geoFips (required — 'STATE', county FIPS like '06075', or MSA code), lineCode (required — integer industry line or 'ALL'), optional year ('LAST5' default, 4-digit year, or 'ALL'), frequency ('A'/'Q'). Returns { rows:[{ geoFips, geoName, timePeriod, lineCode, dataValue, unitOfMeasure, unitMult, noteRef }], notes:[{ noteRef, noteText }] } + honest _meta. ★HONESTY: a missing/invalid key OR ANY bad parameter returns HTTP 200 carrying an Error object — detected and surfaced as invalid_input carrying BEA's APIErrorDescription, NEVER a fake empty. dataValue parsed from BEA's comma-formatted string ('1,234,567' → 1234567). BEA suppression codes (NA)/(D)/(NM)/(L)/* → null (NEVER 0; genuine 0 stays 0). unitMult and unitOfMeasure reported ALONGSIDE raw dataValue — NOT pre-multiplied in. BEA returns the COMPLETE filter result (no pagination) → complete:true. Genuine empty Data:[] → honest empty; 5xx → THROWS; 200 non-JSON → schema_drift. Key rides ONLY in the UserID= query param.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoThe data year: a 4-digit year (e.g. '2022'), 'LAST5' (the latest 5 years, default), or 'ALL'. Validated ^(\d{4}|LAST5|ALL)$.
geoFipsYesThe BEA GeoFips selector: 'STATE' (all states), a county FIPS like '06075', or an MSA code. Validated ^[A-Za-z0-9]{2,10}$. Required.
lineCodeYesThe industry/statistic line code — an integer (1–4 digits), e.g. '1', or 'ALL' for every line in the table. Validated ^([0-9]{1,4}|ALL)$. Required.
frequencyNoData frequency: 'A' (annual, default) or 'Q' (quarterly).
tableNameYesA BEA Regional table code (2–20 alphanumerics), e.g. 'CAGDP2' (county GDP by industry), 'SAGDP2N' (state GDP by industry), 'CAINC1'/'SAINC1' (personal income). Validated ^[A-Za-z0-9]{2,20}$. Required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral detail: key requirement and error behavior (honest config error, HTTP 200 with Error object surfaced as invalid_input), parsing of comma-formatted dataValue, mapping of suppression codes to null, non-pre-multiplied unitMult/unitOfMeasure, complete results without pagination, and handling of empty data, 5xx, and non-JSON responses. This far exceeds what annotations alone provide.

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

Conciseness4/5

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

The description is long but every section earns its place. It starts with the core purpose, then critical key requirement, then parameter details, and finally return and error handling. The use of ★ markers highlights key points. It's structured with labels (Input, Returns, HONESTY) and is comprehensive, though it could be tightened without losing information.

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?

For a tool with 5 parameters, an external API key requirement, and complex error handling, the description covers all essential aspects: parameter formats with examples, return schema (rows and notes), data parsing behavior, suppression codes, pagination absence, and error scenarios. There is no output schema, so the description correctly carries the full burden of explaining return values. It is complete for an agent to call correctly.

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 parameters are already documented. The description adds valuable context by giving example table names (CAGDP2, SAGDP2N, CAINC1/SAINC1), explaining lineCode as integer or 'ALL', year options (LAST5, 4-digit, ALL), and frequency choices. It also clarifies the return format, which is not in the schema. This adds meaning beyond the schema.

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?

The description clearly states the tool provides regional GDP by industry and personal income from BEA Regional Economic Accounts, specifying the dataset and scope (county/state/MSA). It names example tables, making the purpose unambiguous. Though it doesn't name a sibling, it is distinct in this toolset as the only BEA regional data source.

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?

It explicitly states the tool requires a free BEA_API_KEY, explains there is no keyless tier, and directs users to api_key_status for checking. It also describes the input parameters and options, giving clear guidance on how to invoke it. It doesn't discuss alternatives because none exist for BEA regional data, but it covers prerequisites and invocation fully.

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

Deploy Server

Other Tools