Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Synergic APIs MCP Server What is US inflation right now, headline and core?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official Model Context Protocol server for Synergic APIs: official US economic data for AI agents. It gives Claude, Cursor, and any MCP-capable client direct access to:
US Inflation API — the official CPI-U from the Bureau of Labor Statistics: 11 categories, YoY/MoM rates computed like the BLS, monthly history back to 1913, official annual averages.
Famous prices — US average price of eggs, gasoline, milk, bread, ground beef, coffee and electricity, monthly since 1976.
US National Debt API — the U.S. Treasury debt to the penny, every business day since 1993, annual debt outstanding since 1790, and the average interest rates the Treasury pays.
All amounts are JSON numbers, periods are YYYY-MM / YYYY-MM-DD, and missing
months in the official record are served as null — never invented.
Node.js 18.17+ (npx included).
A Synergic APIs key. Get one free (no credit card) at synergicapis.com/signup.html — 500 requests/month, both APIs, full history. Paid plans at synergicapis.com/pricing.html.
Related MCP server: econstats-mcp
The server runs over stdio via npx — no clone, no build.
Add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"synergic-apis": {
"command": "npx",
"args": ["-y", "@synergic-apis/mcp"],
"env": {
"SYNERGIC_API_KEY": "YOUR_API_KEY"
}
}
}
}claude mcp add synergic-apis --env SYNERGIC_API_KEY=YOUR_API_KEY -- npx -y @synergic-apis/mcpAdd to ~/.cursor/mcp.json (or .cursor/mcp.json in your project):
{
"mcpServers": {
"synergic-apis": {
"command": "npx",
"args": ["-y", "@synergic-apis/mcp"],
"env": {
"SYNERGIC_API_KEY": "YOUR_API_KEY"
}
}
}
}Variable | Required | Default | Description |
| yes | — | Your API key. Sent as |
| no |
| Gateway base URL (override for testing). |
Tool | What it does | Key arguments |
| Latest month of CPI for all 11 categories with YoY/MoM rates. |
|
| Monthly CPI history of one category (headline since 1913). |
|
| Official annual average CPI (M13, NSA). |
|
| Latest basket of famous US prices, or one item's monthly history. |
|
| The US national debt today, to the penny. | — |
| Daily debt (1993+, limit ≤100) or annual fiscal-year-end debt (1790+, |
|
| Latest Treasury avg interest rate per security class, or one class's monthly history (2001+). |
|
| Plan, requests used, monthly limit and reset date of your key. | — |
History tools paginate by period range: when a response's meta.next_end is not
null, call the tool again with end set to that value to get older data.
Ask your assistant things like:
"What is US inflation right now, headline and core?"
"Plot the price of eggs since 2020."
"How much did the US national debt grow in the last 12 months?"
"What rate does the Treasury pay on T-bills today vs 2021?"
"SYNERGIC_API_KEY is not set" — the server exits at startup if the key is
missing. Add it to the env block of your MCP client config (see above) and
restart the client.
"Invalid API key" — the gateway rejected the key (typo or revoked). Keys
look like sk_.... Get a fresh one at
synergicapis.com/signup.html.
"Rate limit exceeded … retry after Xs" — you hit your plan's per-minute limit (free: 10 req/min). Wait and retry.
"Monthly quota exhausted" — you used the month's requests (free: 500).
Ask the agent to call get_my_usage for details, wait for the 1st (UTC), or
upgrade at synergicapis.com/pricing.html.
Tools don't appear in the client — check the client's MCP logs; the most
common causes are an old Node (needs 18.17+) or npx not on the PATH used by
the client. Running npx -y @synergic-apis/mcp in a terminal should print
ready on stdio to stderr and then wait for input.
Corporate proxy / self-hosted testing — point SYNERGIC_GATEWAY_URL at
your gateway; the server only ever issues GET requests with X-Api-Key.
npm install
npm run typecheck # tsc --noEmit (strict)
npm test # vitest — tool→request mapping + error mapping, fetch mocked
npm run build # emits dist/ and the synergic-apis-mcp binData: U.S. Bureau of Labor Statistics and U.S. Treasury Fiscal Data (public domain; this product is not endorsed by or affiliated with either agency). Code: MIT.
Get famous US average consumer prices in dollars from the BLS: eggs (per dozen), gasoline (per gallon), milk (per gallon), bread (per lb), ground-beef (per lb), coffee (per lb) and electricity (per kWh). Without "item" it returns the latest price of the whole basket. With "item" it returns that item's monthly history (gasoline since 1976), paginated by period range (use meta.next_end as the next "end").
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Inclusive end month (YYYY-MM). Only used with "item"; pass meta.next_end to paginate. | |
| item | No | One item for monthly history. Omit to get the latest price of every item. | |
| limit | No | Max points per page (1-100, default 30). Only used with "item". | |
| start | No | Inclusive start month (YYYY-MM). Only used with "item". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides behavioral details: the distinction between basket vs. item modes, the historical depth for gasoline since 1976, and the pagination mechanism. It does not mention rate limits or error behavior, but it covers the key behavioral nuances.
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?
The description is two sentences, front-loaded with the core purpose, then provides mode-specific usage. Every clause adds value without redundancy.
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?
Despite lacking an output schema and having no annotations, the description adequately explains the two usage modes, parameter constraints, item list, pagination, and data source. It could mention the exact return format, but the information provided is sufficient for an agent to invoke correctly.
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 coverage is 100%, so baseline is 3. The description adds extra meaning by clarifying that start/end/limit are only used with 'item', and specifically instructs to pass meta.next_end as the next 'end' for pagination, which the schema does not convey.
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 clearly states the tool fetches famous US average consumer prices from BLS for a specific list of items, and distinguishes two modes (whole basket vs. single item history). It is distinct from sibling tools focused on inflation, debt, and interest rates.
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 description explains when to omit 'item' (get latest basket) and when to provide it (get monthly history), and includes pagination instructions via meta.next_end. It does not explicitly name alternatives, but the context of siblings makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the monthly usage and remaining quota of the configured Synergic APIs key: plan name, requests used, monthly limit and when the quota resets. Call this when a request fails with a quota error or the user asks how much of their plan is left.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it performs a read-only check, returns specific quota details, and is associated with the configured API key. There is no mention of side effects or required permissions, which is appropriate for a simple usage query. The description adds context about the quota reset timing, going beyond a bare 'check usage' statement.
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?
The description is two sentences long and front-loaded with the action and result. The first sentence states the purpose and output; the second advises when to call it. Every clause adds value, with no redundant or fluffy phrasing.
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?
The tool is simple (no params, no output schema), and the description adequately explains the return content and usage context. There are no nested objects or complex behaviors that need further elaboration. The sibling tools are entirely different in domain, so no confusion arises. The information provided is sufficient for an agent to select and invoke the tool correctly.
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 has zero parameters, so the baseline is 4. The description does not need to explain parameters, but it does clarify what the tool measures (monthly usage and remaining quota), which enriches the overall understanding of the tool's input-less operation.
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 specific verb ('Check') and a clear resource ('monthly usage and remaining quota of the configured Synergic APIs key'). It enumerates the exact information returned (plan name, requests used, monthly limit, quota reset), which unambiguously distinguishes it from the sibling tools that retrieve economic indicators.
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?
It provides explicit usage criteria: 'Call this when a request fails with a quota error or the user asks how much of their plan is left.' This tells the agent exactly when to invoke the tool and implicitly when not to, making the decision process straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get US national debt history from the U.S. Treasury. frequency="daily" returns the Debt to the Penny series (every business day since 1993-04-01, components null before 2005-03-31; limit up to 100). frequency="annual" returns debt outstanding at each fiscal year end since 1790 — with limit=250 the complete 235-year series fits in one call. Most recent first; paginate by passing meta.next_end as the next "end".
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Inclusive end date (YYYY-MM-DD). Pass meta.next_end here to get the next page. | |
| limit | No | Max records per page. Daily: 1-100 (default 30). Annual: 1-250 (default 100; 250 = whole series). | |
| start | No | Inclusive start date (YYYY-MM-DD). | |
| frequency | Yes | "daily" = business-day Debt to the Penny (1993+); "annual" = fiscal-year-end series (1790+). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses data source, date ranges, ordering (most recent first), pagination mechanism, and notable data quirks (components null before 2005-03-31, limit=250 covers the full annual series). This goes beyond generic read-only behavior.
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, each packed with distinct information. The most important purpose statement is front-loaded, and subsequent sentences deliver frequency-specific details and pagination without redundancy or 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?
Given the tool's complexity (two frequencies, pagination, no output schema), the description covers the essentials: frequency selection, date ranges, limits, ordering, and pagination. Minor gaps exist (e.g., what 'components' means, response shape), but the description is sufficient for an agent to invoke the tool correctly.
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 coverage is 100%, so baseline is 3. The description adds value by explaining the practical effect of limit for each frequency (e.g., 'limit=250 the complete 235-year series fits in one call') and clarifying pagination semantics for the end parameter. This enriches the schema's already-detailed descriptions.
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 opens with a clear, specific verb+resource statement: 'Get US national debt history from the U.S. Treasury.' It then distinguishes between daily and annual frequencies, which differentiates this tool from siblings like get_us_debt_latest and get_us_inflation_history.
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 description provides clear context for when to use each frequency (daily for Debt to the Penny, annual for fiscal-year-end series) and mentions pagination via meta.next_end. It does not explicitly state exclusions or compare to alternatives, but the scope is well implied by 'history' vs. siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current US national debt to the penny — the most recent official U.S. Treasury "Debt to the Penny" record: total public debt outstanding plus its two components (debt held by the public and intragovernmental holdings), in US dollars exact to the cent. Use this to answer "what is the US national debt right now?".
| 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 adds behavioral context by specifying the source ('official U.S. Treasury "Debt to the Penny" record'), recency ('most recent'), and precision ('exact to the cent'). However, it does not disclose potential limitations like data delays, rate limits, or authentication needs, leaving some gaps for a tool with zero annotation support.
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?
The description is two concise sentences. The first sentence front-loads the primary action and key details (components, precision), while the second gives a direct usage example. Every word earns its place with no redundancy.
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?
Given the tool's simplicity (no params, no annotations, no output schema), the description is fully self-contained. It explains exactly what data is returned (total debt plus components, exact to the cent) and when to use it, which sufficiently covers all necessary context for an agent.
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 has zero parameters, so the input schema is empty and the description doesn't need to explain parameter usage. The baseline for 0 params is 4, and the description adds meaningful context about the output structure, which indirectly clarifies that no input is required.
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 clearly states the tool's purpose with a specific verb and resource: 'Get the current US national debt to the penny'. It also distinguishes from siblings like get_us_debt_history by emphasizing 'most recent' and 'right now', making the scope explicit.
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 description provides clear usage context: 'Use this to answer "what is the US national debt right now?"'. While it doesn't explicitly mention alternatives or exclusions, the phrasing strongly implies this is for current data, contrasting with historical tools. This meets the 'clear context' standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the official annual average CPI of one category (the BLS M13 rows, published NSA only). Headline "all-items" covers every year since 1913 — with limit=150 the complete series fits in one call. Ideal for long-run inflation comparisons and "how much has $X in year Y grown" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Inclusive end year (YYYY). Pass meta.next_end here to get the next page. | |
| limit | No | Max points per page (1-150, default 50; 150 = the whole headline series). | |
| start | No | Inclusive start year (YYYY), e.g. "1913". | |
| category | Yes | CPI category. "all-items" is headline inflation; "core" excludes food and energy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the data source (BLS M13), seasonality (NSA only), and pagination behavior (limit=150 covers the full headline series). It does not mention return format or error conditions, but for a read-only data retrieval tool this is substantial context.
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 core function, and every sentence adds value. No redundancy or filler. It packs source, scope, use cases, and pagination hints into a compact paragraph.
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?
The description is strong overall but omits any explanation of the response/return format. Since there is no output schema, the description should compensate by describing what the agent can expect (e.g., a list of year-value pairs). Without that, the tool is usable but not fully self-contained. The complexity is low, which tempers the penalty.
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 coverage is 100%, so the baseline is 3. The description adds practical meaning by explaining that limit=150 retrieves the complete 'all-items' series in one call, and clarifies that 'headline' refers to the all-items category. This goes beyond the schema's generic descriptions and helps the agent choose appropriate parameter values.
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 specific verb ('Get') and resource ('official annual average CPI of one category'), and explicitly notes the BLS M13 rows and NSA-only publication. It clearly distinguishes itself from sibling tools like get_us_inflation_latest and get_us_inflation_history by focusing on annual averages and the full historical series.
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 description provides explicit recommended use cases: 'long-run inflation comparisons' and 'how much has $X in year Y grown' questions. It implies an alternative (get_us_inflation_latest) by contrast, though it does not explicitly name when not to use it, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get monthly CPI history for one category (headline "all-items" goes back to 1913). Returns index level and YoY/MoM percent per month, most recent first. Paginated by period range: if meta.next_end is not null, call again with end = meta.next_end for older data. Note: October 2025 was never published by the BLS (federal shutdown) and is absent.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Inclusive end month (YYYY-MM). Pass meta.next_end here to get the next page. | |
| limit | No | Max points per page (1-100, default 30). | |
| start | No | Inclusive start month (YYYY-MM), e.g. "2020-01". | |
| adjusted | No | false (default) = not seasonally adjusted (NSA, the year-over-year convention the press quotes); true = seasonally adjusted (SA, the month-over-month convention). | |
| category | Yes | CPI category. "all-items" is headline inflation; "core" excludes food and energy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry transparency. It discloses return content, ordering (most recent first), pagination via meta.next_end, and even a specific data gap (October 2025 missing). This is strong behavioral disclosure beyond the minimum.
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, each earning its place: purpose, return format/order, pagination, and a critical data caveat. No fluff or repetition.
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?
Despite no output schema, the description sufficiently tells what will be returned (index and YoY/MoM percentages) and how to paginate. It also addresses a likely data-completeness concern (October 2025), making it complete for a tool of moderate complexity.
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 baseline is 3. The description adds a bit of context (paginated by period range, headline depth), but most parameter meaning already exists in the schema, including the adjusted convention and pagination usage on the end parameter.
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 clearly states its verb ('Get monthly CPI history') and resource ('CPI history for one category'), and the title 'US inflation monthly history' distinguishes it from siblings like annual/latest. It specifies the historical scope and a key legacy date (1913).
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?
It gives clear context for when to use (monthly history vs. annual or latest) but does not explicitly name alternatives or state when NOT to use it. The pagination instruction provides solid usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent month of official US inflation (CPI-U, Bureau of Labor Statistics) for all 11 categories at once: headline all-items, core, energy, food, housing, apparel, transportation, medical, recreation, education-communication and other. Each point has the index level plus year-over-year and month-over-month percent change computed exactly like the BLS. Use this to answer "what is US inflation right now?".
| Name | Required | Description | Default |
|---|---|---|---|
| adjusted | No | false (default) = not seasonally adjusted (NSA, the year-over-year convention the press quotes); true = seasonally adjusted (SA, the month-over-month convention). |
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 return payload (index level plus YoY and MoM percent changes, computed like BLS) and implies a read-only operation. It does not mention potential rate limits or side effects, but for a data-retrieval tool this is sufficient.
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, front-loaded with the core purpose and categories, followed by a practical usage note. Every word adds value, with no redundancy or 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?
Despite no output schema, the description explains exactly what return values to expect (index level, YoY, MoM) and which categories are included. For a single-parameter latest-data tool, this is complete and self-contained.
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 the parameter 'adjusted' is fully documented in the schema. The description adds context about the data categories but does not enhance parameter understanding beyond what the schema already provides; baseline 3 is appropriate.
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 uses a specific verb ('Get') and resource ('most recent month of official US inflation (CPI-U, Bureau of Labor Statistics)'), clearly distinguishing this from siblings like history or annual. It also enumerates all 11 categories and the metrics returned, leaving no ambiguity about scope.
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 use case: 'Use this to answer "what is US inflation right now?"'. This tells the agent when to select this tool over the historical or annual variants. It lacks an explicit 'when not to use' clause but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the average interest rates the U.S. Treasury pays on the national debt (monthly, 2001+). Without "security_class" it returns the latest rate of all eight classes: total, marketable, non-marketable, bills, notes, bonds, tips and frn. With "security_class" it returns that class's monthly history, paginated by period range (periods are month-end dates; use meta.next_end as the next "end").
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Inclusive end date (YYYY-MM-DD). Only used with "security_class"; pass meta.next_end to paginate. | |
| limit | No | Max records per page (1-100, default 30). Only used with "security_class". | |
| start | No | Inclusive start date (YYYY-MM-DD). Only used with "security_class". | |
| security_class | No | One security class for monthly history. Omit to get the latest rate of every class. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the monthly frequency, data starting from 2001+, the pagination mechanism via meta.next_end, and that periods are month-end dates. This gives an agent important behavioral expectations without over-specifying.
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 dense sentences convey the full payload: the resource, scope, two modes, and pagination. Every word earns its place, and the most important information is front-loaded.
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 tool with four optional params, no output schema, and dual mode behavior, the description covers the essential usage patterns. It lacks details about the exact response structure beyond meta.next_end, but the behavior is sufficiently specified for an agent to invoke correctly.
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 coverage is 100%, yet the description adds real value by explaining that start/end/limit are only used with security_class and how pagination works using meta.next_end. This goes beyond the schema's individual property descriptions and clarifies parameter interplay.
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 clearly states the tool retrieves average interest rates paid by the U.S. Treasury, distinguishing it from sibling tools focused on inflation or debt. It also explicitly covers the two modes (latest rates vs. monthly history), leaving no ambiguity about the resource and action.
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 description gives clear guidance on when to omit or include the security_class parameter, effectively explaining how to choose between the two use cases. It does not explicitly discuss alternative tools, but sibling names are self-explanatory, so context is sufficient.
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.
v0.1.2get_famous_pricesget_my_usageget_us_debt_historyget_us_debt_latestget_us_inflation_annualget_us_inflation_historyget_us_inflation_latestget_us_interest_ratesScored across 8 tools
Each tool targets a distinct dataset and granularity: usage vs inflation (latest/history/annual) vs debt (latest/history) vs interest rates vs famous prices. No two tools serve the same purpose, and the descriptions make the boundaries crystal clear.
All tools use a consistent 'get_' prefix and most follow 'get_us_<topic>_<suffix>' (e.g., get_us_inflation_latest, get_us_debt_history). However, 'get_famous_prices' and 'get_us_interest_rates' deviate slightly from the full pattern, making it mildly less predictable.
With 8 tools, the server is well-scoped for a specialized economic data API. Each tool provides a distinct read-only query, and the count feels neither sparse nor bloated.
The server covers the core domain comprehensively: latest snapshots, historical series, and annual aggregates for inflation and debt, plus interest rates, consumer prices, and an API usage check. No obvious missing operations for a read-only data retrieval server.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Hosted MCP server for live public-data APIs and Skills for AI agents.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…