treasury-fiscaldata-mcp-server
Server Details
MCP server for US Treasury Fiscal Data — debt, interest rates, exchange rates, and spending.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: dataframe management, specific data retrievals, catalog browsing, and generic querying. No overlap or ambiguity, making it easy for an agent to select the correct tool.
All tools start with 'treasury_' followed by a verb_noun pattern (e.g., get_debt, list_datasets, query_dataset). While 'treasury_dataframe_describe' breaks the verb-first convention slightly, the overall pattern is consistent and readable.
Seven tools is an ideal scope for this domain: it covers catalog exploration, specific data fetching for three common datasets, generic querying, and dataframe integration. No tool is redundant or missing.
The tool surface covers the full lifecycle of data access: discovery (list_datasets), flexible querying (query_dataset), dedicated high-value endpoints (debt, interest, exchange rates), and post-processing via dataframes (describe, query). No obvious gaps for a read-only data API.
Available Tools
7 toolstreasury_dataframe_describeDescribe Treasury DataframesARead-onlyIdempotentInspect
List DataCanvas dataframes materialized by treasury_query_dataset, treasury_get_debt, treasury_get_interest_rates, and treasury_get_exchange_rates. Each entry surfaces source tool, query parameters, creation/expiry timestamps, row count, and column schema. Use this tool before treasury_dataframe_query to discover table names and column types. Requires CANVAS_PROVIDER_TYPE=duckdb.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional dataframe table name (df_XXXXX_XXXXX) to describe a single dataframe. Omit to list all active dataframes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dataframes | Yes | Active dataframes for this tenant, newest first. Empty when none are registered. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the source tools, the schema of returned entries, and the requirement for CANVAS_PROVIDER_TYPE=duckdb. No contradictions with annotations.
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 concise with three sentences, each adding important information. It is front-loaded with the main action and wastes no words.
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 presence of an output schema, the description adequately covers purpose, usage, prerequisites, and relationship to siblings. It is complete for a simple list 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 coverage is 100% and the description adds minimal new information beyond the schema's existing description of the 'name' parameter. The baseline of 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 clearly states the tool lists DataCanvas dataframes from specific source tools, and details what each entry contains. It distinguishes itself from sibling tools by mentioning it should be used before treasury_dataframe_query.
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 explicitly advises using this tool before treasury_dataframe_query and notes a required environment variable. However, it does not explicitly state when not to use it, though the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_dataframe_queryQuery Treasury DataframesARead-onlyIdempotentInspect
Run a single-statement SELECT against DataCanvas dataframes registered by treasury_query_dataset, treasury_get_debt, treasury_get_interest_rates, and treasury_get_exchange_rates. Read-only: writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file table functions are rejected. System catalogs (information_schema, pg_catalog, sqlite_master, duckdb_*) are denied at the bridge layer. All Treasury dataframe columns are VARCHAR — CAST to DECIMAL or DATE for arithmetic and date comparisons. Use treasury_dataframe_describe to list available table names and column schemas before querying.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Single-statement SELECT against df_<id> tables. All values in Treasury dataframes are VARCHAR (strings) per the API contract — CAST to DECIMAL or DATE for arithmetic and date comparisons. Example: SELECT record_date, CAST(tot_pub_debt_out_amt AS DECIMAL) AS debt FROM df_xxxxx ORDER BY record_date DESC LIMIT 10. | |
| preview | No | Rows in the immediate response. Defaults to row_limit. Set lower when using register_as. | |
| row_limit | No | Hard cap on rows in the response. Default 1000, max 10000. | |
| register_as | No | Persist result as a new dataframe. Use to chain analyses. The name must match df_XXXXX_XXXXX format or be a fresh df_<id>. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Materialized rows, bounded by preview / row_limit. |
| notice | No | Guidance when the query returned no rows, or when results were capped by row_limit. |
| columns | Yes | Column names in projection order. |
| row_count | Yes | Total rows the query produced (may exceed rows.length when capped). |
| expires_at | No | ISO 8601 expiry timestamp for the newly registered dataframe, when applicable. |
| registered_as | No | Set when register_as was supplied and the new dataframe was materialized. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond annotations: rejecting DDL, DROP, COPY, PRAGMA, ATTACH, external-file functions, and denying system catalogs. It also explains VARCHAR type casting requirements. No contradiction with annotations (readOnlyHint, idempotentHint) is present.
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 well-structured, starting with purpose, then restrictions, type information, and guidance. It is slightly verbose but every sentence adds value. Could be slightly more trimmed.
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 (4 parameters, output schema exists), the description covers critical aspects: read-only behavior, type casting, and prerequisite tool usage. The output schema is not detailed but that is acceptable since it is included separately.
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?
Though schema coverage is 100%, the description adds meaningful context for the 'sql' parameter (single-statement SELECT, example, type casting) and explains 'preview', 'row_limit', and 'register_as' usage, enhancing the schema 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 clearly states the tool runs a single-statement SELECT against DataCanvas dataframes registered by named sibling tools, distinguishing it from others. It uses a specific verb and resource, making the purpose unambiguous.
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 advises using treasury_dataframe_describe before querying and provides an example. It implicitly contrasts with other tools but does not explicitly state when not to use this tool or list alternatives for non-SELECT operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_get_debtGet National DebtARead-onlyIdempotentInspect
Fetch national debt (Debt to the Penny) — total public debt outstanding broken into publicly-held debt and intragovernmental holdings. Three modes: "latest" returns the most recent business day's record; "date" returns the record for a specific date (must be a business day — the API only records debt on days markets are open); "series" returns a date range and optionally spills results to DataCanvas for SQL analysis via treasury_dataframe_query. Records go back to 1993-01-04. As of 2026-05-28 the total debt is approximately $39.18T.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date (YYYY-MM-DD) for mode=date. Must be a business day; the API only records debt on days the market is open. | |
| mode | No | "latest" returns the most recent day's record. "date" returns the record for a specific date. "series" returns a date range — use with start_date and end_date. | latest |
| end_date | No | ISO 8601 end date for mode=series (inclusive). Defaults to today. | |
| canvas_id | No | DataCanvas table name (df_XXXXX_XXXXX) to register series results into for SQL analysis. When provided, or when the series exceeds 500 rows, the full result is registered and the name is returned in canvas_id. Use treasury_dataframe_query to run SQL against it. Requires CANVAS_PROVIDER_TYPE=duckdb. | |
| start_date | No | ISO 8601 start date for mode=series (inclusive). Fiscal Data has daily debt records back to 1993-01-04. |
Output Schema
| Name | Required | Description |
|---|---|---|
| series | No | All records for mode=series (may be truncated when spilled to canvas). |
| canvas_id | No | DataCanvas table name when series was spilled. Use treasury_dataframe_query to run SQL. |
| total_debt | Yes | Total public debt outstanding in USD (string — convert as needed). Example: "39176301795549.40". |
| record_date | Yes | Date of this debt record (YYYY-MM-DD). For series mode, the most recent date. |
| total_records | No | Total matching records for mode=series. |
| debt_held_public | Yes | Debt held by the public (external creditors, Fed, foreign governments) in USD. |
| canvas_expires_at | No | ISO 8601 expiry for the canvas dataframe. |
| intragovernmental_holdings | Yes | Intragovernmental holdings (debt owed to federal trust funds, Social Security, etc.) in USD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds critical behaviors: business-day-only recording, three return fields, canvas_id requirements, and data history. Fully transparent.
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?
Concise paragraph with well-organized sentences; no redundancy. Every sentence provides essential information without waste.
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 output schema exists, return values need no explanation. Description covers all key aspects: modes, constraints, canvas integration, data history. Complete for a 5-param 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 coverage is 100%, so baseline is 3. The description adds value by clarifying mode meanings, business day constraint for date, canvas_id usage, and data range for start_date.
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 explicitly states it fetches national debt data, explains the three modes (latest, date, series), and provides context like data history and current total. This clearly distinguishes it from siblings like treasury_get_exchange_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 details when to use each mode and mentions optional DataCanvas spill for series. It implicitly distinguishes from siblings by focusing on debt data, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_get_exchange_ratesGet Treasury Exchange RatesARead-onlyIdempotentInspect
Official Treasury reporting exchange rates for ~130 countries — the rates US federal agencies are required to use when converting foreign currency to USD for official reporting. Published quarterly (March 31, June 30, Sep 30, Dec 31). Rate is expressed as foreign currency units per 1 USD (e.g., Japan-Yen: 159.41 means 1 USD = 159.41 JPY). These are NOT market exchange rates and are not suitable for financial transaction pricing. The latest quarter available is 2026-03-31 (Q1 2026).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | "latest" returns the most recently published quarter's rates. "series" returns a date range of quarterly reports. | latest |
| end_date | No | ISO 8601 end date for mode=series. | |
| canvas_id | No | DataCanvas table name (df_XXXXX_XXXXX) to register series results into for SQL analysis. Useful when pulling multi-year history for many countries (~18,800 rows total). When provided, or when mode=series and results exceed 500 rows, the result is registered and canvas_id is returned. Use treasury_dataframe_query to query it. Requires CANVAS_PROVIDER_TYPE=duckdb. | |
| countries | No | Filter to specific countries by exact country name (e.g., ["Japan", "Germany", "France"]). Case-sensitive, matches the "country" field. Omit for all ~130 countries in the quarter. | |
| start_date | No | ISO 8601 start date for mode=series. Rates are published end-of-quarter (March 31, June 30, Sep 30, Dec 31). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Contextual note reminding that these are official reporting rates, not market rates. |
| rates | Yes | Exchange rates for the requested countries/quarter. |
| notice | No | Guidance when a requested country was not found or returned no records. |
| canvas_id | No | DataCanvas table name for series results. Use treasury_dataframe_query to run SQL. |
| as_of_date | Yes | Quarter-end date of the most recent rates (YYYY-MM-DD). |
| total_records | Yes | Total records returned. |
| effective_date | Yes | Effective date of the rates (same as record_date). |
| canvas_expires_at | No | ISO 8601 expiry for the canvas dataframe. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context: rates are published quarterly, expressed as foreign currency per USD, and includes an example (Japan-Yen: 159.41 means 1 USD = 159.41 JPY). It also states the latest quarter available. No contradictions.
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 concise, with four sentences that each add distinct value: purpose, frequency, rate format with example, and a caveat. No unnecessary 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?
Given that there is an output schema (not shown but noted in context signals), the description does not need to explain return values. It covers purpose, usage context, behavioral traits, and parameters are well-documented in schema. Complete for a data retrieval 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 baseline is 3. The description adds a helpful example for rate interpretation but does not significantly augment parameter meanings beyond the schema's 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 clearly states it retrieves official Treasury reporting exchange rates for ~130 countries, specifying their use by US federal agencies. It distinguishes this tool from siblings like treasury_get_interest_rates by focusing specifically on exchange 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 that these rates are not market exchange rates and are not suitable for financial transaction pricing, providing clear when-not-to-use guidance. It also notes the quarterly publication and latest available quarter, but does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_get_interest_ratesGet Treasury Interest RatesARead-onlyIdempotentInspect
Average interest rates Treasury pays on its outstanding securities by security type. Answers "what is the government's cost of borrowing?" Covers Bills, Notes, Bonds, TIPS, Floating Rate Notes, and aggregate marketable/non-marketable totals. Updated monthly (end-of-month records). Mode "latest" returns the most recent month's rates for all or one security type; "series" returns a time history. As of 2026-04-30: Bills 3.696%, Notes 3.230%, Bonds 3.403%, TIPS 1.068%, FRN 3.764%, Total Interest-bearing Debt 3.340%.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | "latest" returns the most recent month's rates. "series" returns a time range. | latest |
| end_date | No | ISO 8601 end date for mode=series. Defaults to today. | |
| canvas_id | No | DataCanvas table name (df_XXXXX_XXXXX) to register series results into for SQL analysis. When provided, or when mode=series and results exceed 200 rows, the result is registered and canvas_id is returned. Use treasury_dataframe_query to query it. Requires CANVAS_PROVIDER_TYPE=duckdb. | |
| start_date | No | ISO 8601 start date for mode=series (YYYY-MM-DD, must be end-of-month for meaningful results). | |
| security_type | No | Filter to one security type. Omit for all types. Use the exact string — the API does exact-match filtering on security_desc. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rates | Yes | Interest rate records. |
| notice | No | Guidance when no records match — lists valid security types or notes the empty date range. |
| canvas_id | No | DataCanvas table name for series results. Use treasury_dataframe_query to run SQL. |
| as_of_date | Yes | Most recent record date returned (YYYY-MM-DD). |
| total_records | Yes | Total matching records. |
| canvas_expires_at | No | ISO 8601 expiry for the canvas dataframe. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, so the agent knows it's safe. The description adds valuable context: update frequency (monthly), mode behavior, date constraints (end-of-month for series), and canvas registration details for large results.
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 a single paragraph that packs in purpose, an example query, covered types, mode explanation, and current example values—all without fluff. Every sentence adds value.
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 (5 params, two modes, canvas integration) and that an output schema exists, the description covers all essential aspects: purpose, usage, security types, update frequency, and registration behavior. Nothing critical is missing.
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% and schema descriptions are already detailed for all 5 parameters. The tool description does not add significant extra meaning beyond what the schema provides, so 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 clearly states it returns average interest rates on Treasury securities by type, answering 'what is the government's cost of borrowing?' It distinguishes from sibling tools like treasury_get_debt or treasury_get_exchange_rates by focusing on 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 the two modes 'latest' and 'series' with clear use cases and provides example values. It implicitly differentiates from siblings by focusing solely on interest rates, though it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_list_datasetsList Treasury Fiscal Data DatasetsARead-onlyIdempotentInspect
Browse the curated catalog of US Treasury Fiscal Data API endpoints. Returns endpoint paths, field names, descriptions, and update cadence for each dataset. Use this tool before treasury_query_dataset to discover the correct endpoint path and field names — a typo in either causes a 400 error from the API. The catalog is a curated subset of the full API — pass any endpoint path directly to treasury_query_dataset to query datasets not listed here. The catalog covers debt, interest rates, exchange rates, revenue/spending, savings bonds, and securities datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Keyword filter against dataset name and description (case-insensitive substring match). Useful for narrowing results when the category is uncertain. | |
| category | No | Filter by category. Omit to list all datasets. Options: debt, interest_rates, exchange_rates, revenue_spending, savings_bonds, securities, other. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total matching datasets. |
| datasets | Yes | Matching datasets. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds value by stating it is a curated subset of the full API, providing behavioral context beyond annotations. No contradictions.
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?
Single paragraph with dense, valuable information. Could be slightly more structured, but no wasted words.
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 simplicity, output schema, and annotations, description fully covers purpose, usage guidelines, and limitations. Complete for effective tool use.
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% with good descriptions. Description adds minor context for search ('useful when category uncertain') but does not significantly enhance understanding beyond schema.
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?
Clearly states it lists Treasury Fiscal Data API endpoints, providing paths, field names, descriptions, and update cadence. Distinguishes from siblings by referencing treasury_query_dataset.
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 advises use before treasury_query_dataset to avoid typos, explains the curated nature, and mentions alternative of passing any endpoint path directly. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_query_datasetQuery Treasury Fiscal Data DatasetARead-onlyIdempotentInspect
Query any Treasury Fiscal Data endpoint by path, field list, filters, sort, and page. Call treasury_list_datasets first to get the correct endpoint path and exact field names — a typo in either causes a 400. Filter syntax: each condition is { field, operator, value } where operator is eq/gt/gte/lt/lte/in (e.g., record_date:gte:2024-01-01). Multiple conditions are ANDed together. All response values are strings per the API contract, including numbers and dates; "null" (string) means no value. Supply canvas_id to register the page result into a named DataCanvas dataframe and query it later with treasury_dataframe_query (requires CANVAS_PROVIDER_TYPE=duckdb on the server).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort expression: field name optionally prefixed with "-" for descending (e.g., "-record_date" for newest-first). | |
| fields | No | Fields to return. Omit to return all fields. Specify field names exactly as listed by treasury_list_datasets — a typo causes a 400. | |
| filters | No | Filter conditions (ANDed together). Multiple filters on different fields are combined in one filter= parameter. | |
| endpoint | Yes | Endpoint path returned by treasury_list_datasets (e.g., "/v2/accounting/od/debt_to_penny"). Include the leading slash. | |
| canvas_id | No | DataCanvas ID to spill results into for SQL analysis. Omit to receive results inline. Requires CANVAS_PROVIDER_TYPE=duckdb on the server. When provided, the full page result is registered as a dataframe and a canvas_id is returned for use with treasury_dataframe_query. | |
| page_size | No | Rows per page. Default 100. Raise to 10000 to minimize round trips for small datasets. For large time-series pulls, use canvas_id with treasury_dataframe_query instead. | |
| page_number | No | Page to fetch (1-indexed). Check total_pages in the response to know if more pages exist. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Rows returned. All values are strings per API contract — including numeric and date fields. Convert in the calling context. Null values appear as the string "null". |
| notice | No | Guidance when results are empty, a field typo is suspected, or the endpoint was not found in the catalog. |
| endpoint | Yes | Endpoint that was queried. |
| canvas_id | No | DataCanvas ID where this page is registered. Use with treasury_dataframe_query to run SQL. |
| page_size | Yes | Rows per page. |
| page_number | Yes | Current page (1-indexed). |
| total_count | Yes | Total rows matching the query (across all pages). |
| total_pages | Yes | Total pages at the current page_size. |
| field_labels | Yes | Human-readable label for each returned field. |
| applied_filters | No | Filter expression sent to the API, for verification. |
| canvas_expires_at | No | ISO 8601 expiry for the canvas dataframe. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true, and the description confirms a read-only, idempotent operation. It warns about 400 errors from typos, clarifies that all response values are strings including 'null', and explains canvas_id behavior with server prerequisites. This adds significant behavioral context beyond annotations.
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?
Description is a single paragraph covering all key aspects. While not broken into structured sections, it front-loads the core purpose and includes necessary details without excessive verbosity. Could be slightly more structured for easier scanning, but highly concise given the complexity.
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 7 parameters, 1 required, and an output schema, the description is thorough: it covers prerequisites, filter syntax, response value types, canvas_id integration, pagination, and edge cases (null string). No missing critical information.
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%, but the description adds substantial meaning: explains filter syntax with operator examples, notes that multiple filters are ANDed, describes canvas_id registration and its dependency on server config, and provides page_size recommendations. This goes well beyond schema 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?
Description clearly states it queries Treasury Fiscal Data endpoints with specific parameters (path, fields, filters, sort, page). It distinguishes itself by requiring treasury_list_datasets first to obtain correct endpoint and field names, avoiding sibling confusion.
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 instructs to call treasury_list_datasets before using this tool. Provides filter syntax details and guidance on when to use canvas_id (large time-series pulls) versus inline results. Does not explicitly list situations where this tool should not be used, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!