usaspending-mcp-server
Server Details
Access US federal award, recipient, agency, and spending analytics data from USAspending.gov.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/usaspending-mcp-server
- GitHub Stars
- 1
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.4/5 across 14 of 14 tools scored. Lowest: 3.8/5.
Each tool targets a distinct data type or action: autocomplete for code lookup, disaster spending for emergencies, agency profiles, award details, subawards, transactions, federal accounts, recipient profiles, agency listing, award search, recipient search, and various spending aggregations. There is no ambiguity about which tool to use for a given task.
All tools follow a consistent 'usaspending_' prefix followed by a descriptive verb_noun or verb_prep_noun pattern (e.g., list_agencies, get_award, spending_by_geography). The naming is predictable and clearly indicates the tool's function.
With 14 tools, the server covers core operations for exploring US federal spending data without being overwhelming or sparse. Each tool has a clear purpose and there are no redundant tools.
The tools provide comprehensive coverage for agency information, award details, recipient profiles, and spending aggregations by category, geography, and time. Minor gaps exist, such as no direct tool for budget functions or object class breakdowns, but the core workflows are well-supported.
Available Tools
14 toolsusaspending_autocompleteAutocomplete Codes and NamesARead-onlyIdempotentInspect
Look up valid code values for filter fields by searching free-text descriptions. Use the type parameter to select the lookup table: naics (NAICS industry codes), psc (product/service codes), cfda (CFDA/Assistance Listing program numbers), awarding_agency (agency names and IDs), or recipient (recipient names and IDs). Call this before filtering awards when you know a description but not the exact code. Returns matching codes and names for use in other tool filters.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Lookup table to search: naics (industry codes), psc (product/service codes), cfda (assistance programs), awarding_agency (agency names), recipient (recipient names) | |
| limit | No | Maximum number of results to return (1–50) | |
| search_text | Yes | Free-text search string — use a description, keyword, or partial code to find matches |
Output Schema
| Name | Required | Description |
|---|---|---|
| type | Yes | Lookup table searched |
| total | Yes | Number of results returned |
| results | Yes | Matching codes and names |
| search_text | Yes | Search text used |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context by stating the tool is for pre-filter lookup and returns codes for use in other filters, which is valuable beyond the 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 two concise sentences, front-loaded with the main action, and every word is purposeful without any fluff.
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 full schema coverage, annotations, and the presence of an output schema, the description sufficiently covers the tool's purpose, usage, and parameters, making it complete for the tool's simplicity.
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 restates the enum values for 'type' and mentions free-text search, but does not add significant meaning beyond what the schema already provides.
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 looks up valid code values for filter fields via free-text search, with the specific use case of finding codes when you know a description. It distinguishes itself from sibling tools by explicitly positioning it as a preliminary step before filtering awards.
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 tells when to use the tool ('Call this before filtering awards when you know a description but not the exact code'), but does not specify when not to use it or offer explicit alternatives. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_disaster_spendingDisaster and Emergency SpendingARead-onlyIdempotentInspect
Fetch disaster and emergency supplemental spending (COVID-19, hurricanes, infrastructure law, etc.) broken down by agency, CFDA assistance program, recipient, or geography. Use the dimension parameter to select the breakdown axis: overview (top-level totals), agency, cfda, recipient, or geography. Filter by DEF codes (Disaster/Emergency Funding codes) to isolate a specific emergency appropriation. DEF codes appear in usaspending_get_award account_obligations_by_defc and usaspending_get_agency def_codes fields.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| limit | No | Maximum results per page (1–100, not used for overview dimension) | |
| filters | No | Optional filters — def_codes narrows to a specific emergency appropriation | |
| dimension | Yes | Breakdown axis: overview (top-level totals and DEF code funding), agency (by awarding agency), cfda (by assistance program), recipient (by recipient), geography (by state/county) | |
| spending_type | No | Data type: award (award-level obligations and outlays) or total (includes direct non-award spending). Applies to agency and recipient dimensions only. | award |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Breakdown results (empty for overview dimension) |
| overview | No | Top-level overview totals (dimension=overview only) |
| dimension | Yes | Breakdown dimension returned |
| page_metadata | No | Pagination metadata (non-overview dimensions) |
| spending_type | Yes | Data type returned (award or total) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the agent knows this is a safe, idempotent read operation. The description adds no further behavioral traits beyond what the tool does (fetching data), which is adequate given the 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 (three main sentences plus one cross-reference) and front-loaded with the essential purpose and breakdown options. Every sentence adds value, and there is no redundant or missing 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 the complexity (nested filters, multiple dimensions, spending_type nuances) and the presence of a full output schema, the description covers the main points: dimensions, def_codes filter, spending_type applicability. It does not detail all filter subfields (e.g., geo_layer, award_type_codes) but those are documented in the schema. Overall, it is sufficiently complete for a tool with annotations and output schema.
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 narrative context beyond parameter descriptions: it explains dimension values in detail, notes that the limit parameter is not used for overview, and clarifies that spending_type applies only to agency and recipient dimensions. This adds meaningful guidance.
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 disaster and emergency supplemental spending, broken down by various dimensions (overview, agency, cfda, recipient, geography). It mentions specific examples like COVID-19 and hurricanes, and references sibling tools where DEF codes can be found, distinguishing its focus on disaster spending from other USASpending 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 description provides clear context on when to use the tool (for disaster/emergency spending) and how to parameterize it (dimension, def_codes). It explains the meaning of dimension values and the role of DEF codes, but does not explicitly state when not to use this tool versus alternatives like usaspending_search_awards or usaspending_spending_by_category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_get_agencyGet Agency OverviewARead-onlyIdempotentInspect
Fetch an agency's current fiscal year overview including mission, budget authority, obligation totals, sub-agency count, and DEF codes for disaster/emergency funding. Also returns sub-agency breakdown with transaction counts. Accepts either a 3-digit toptier_code (e.g., 097 for DoD, 012 for Agriculture) or an agency_slug (e.g., department-of-defense) — both appear in usaspending_list_agencies results and award search results.
| Name | Required | Description | Default |
|---|---|---|---|
| agency_slug | No | URL-friendly agency slug (e.g., department-of-defense) — from usaspending_list_agencies or award search results. Use either toptier_code or agency_slug, not both. | |
| toptier_code | No | 3-digit toptier agency code (e.g., 097, 012) — from usaspending_list_agencies. Use either toptier_code or agency_slug, not both. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | Agency full name |
| mission | No | Agency mission statement |
| website | No | Agency website URL |
| agency_id | No | Internal agency ID |
| def_codes | No | Disaster/Emergency Funding (DEF) codes applicable to this agency |
| abbreviation | No | Agency abbreviation |
| sub_agencies | No | Sub-agency breakdown within this toptier agency |
| toptier_code | No | 3-digit toptier agency code |
| obligated_amount | No | Total obligated amount in USD for current fiscal year |
| transactions_count | No | Total transaction count |
| subtier_agency_count | No | Number of sub-agencies within this toptier agency |
| budget_authority_amount | No | Total budget authority amount in USD for current fiscal year |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint, and the description adds value by detailing the returned data (mission, budget, DEF codes, sub-agency breakdown), thus fully informing the agent of the tool's 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?
The description is concise, with two sentences. The first lists key return fields, the second explains input options and cross-reference. No unnecessary 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 doesn't need to detail return format. It fully covers input requirements and behavioral context, making it complete for the tool's 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?
The input schema already describes the two parameters and their mutual exclusivity. The description adds context about where these IDs come from (usaspending_list_agencies and award search results), providing additional semantic value.
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 fetches an agency's current fiscal year overview with specific data fields (mission, budget authority, obligation totals, sub-agency count, DEF codes) and differentiates from siblings like usaspending_list_agencies by focusing on a single agency's details.
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 the tool accepts either a toptier_code or agency_slug from usaspending_list_agencies or award search results, implying when to use it. However, it lacks explicit guidance on when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_get_awardGet Award DetailsARead-onlyIdempotentInspect
Fetch full details of a federal award by its generated unique award ID. Returns contract or assistance award data including recipient info, agency hierarchy, period of performance, place of performance, funding account linkages (account_obligations_by_defc), parent IDV information, and subaward count. Use generated_internal_id values from usaspending_search_awards as input. Recipient hashes can be passed to usaspending_get_recipient; NAICS codes can be used in usaspending_search_awards filters.
| Name | Required | Description | Default |
|---|---|---|---|
| award_id | Yes | Generated unique award ID (e.g., CONT_AWD_FA862118F6251_9700_FA862115D6276_9700) — use generated_internal_id from usaspending_search_awards |
Output Schema
| Name | Required | Description |
|---|---|---|
| cfda | No | CFDA program (grants/assistance) |
| fain | No | Federal Award Identification Number (for assistance) |
| piid | No | Procurement Instrument Identifier (for contracts) |
| type | No | Award type code |
| naics | No | NAICS code (contracts) |
| category | No | Award category (contract, grant, direct_payment, loan, idv, other) |
| recipient | No | Recipient details |
| date_signed | No | Date award was signed (YYYY-MM-DD) |
| description | No | Award description |
| parent_award | No | Parent IDV information (contracts only) |
| total_outlays | No | Total outlay amount in USD |
| funding_agency | No | Funding agency hierarchy |
| subaward_count | No | Number of subawards; use with usaspending_get_award_subawards |
| awarding_agency | No | Awarding agency hierarchy |
| total_obligation | No | Total obligation amount in USD |
| type_description | No | Human-readable award type |
| transactions_count | No | Number of transactions; use with usaspending_get_award_transactions |
| place_of_performance | No | Place of performance |
| period_of_performance | No | Period of performance dates |
| product_or_service_code | No | Product or service code (contracts) |
| generated_unique_award_id | No | Generated unique award ID |
| base_and_all_options_value | No | Base and all options value in USD (contracts) |
| account_obligations_by_defc | No | Funding breakdown by Disaster/Emergency Funding (DEF) code — links to disaster appropriations |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm idempotent and read-only behavior, and the description aligns by describing data retrieval without side effects. It adds transparency by listing specific data fields returned, which goes 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?
The description is concise, front-loads the core purpose, and every sentence adds value—purpose, return data, input source, and cross-references to sibling tools. 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?
The description addresses the tool's purpose, input sourcing, returned data structure, and links to related tools. Given the presence of annotations (readOnly, idempotent) and a full output schema, the description provides sufficient context for correct invocation. It could be enhanced by noting potential absence of data or error handling, but for this complexity level, it's largely complete.
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 schema already describes the parameter, but the description adds a concrete example and clarifies it comes from usaspending_search_awards, which significantly aids correct usage. This is valuable context that schema alone does not provide.
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 full award details by unique award ID, lists included data fields, and references sibling tools for related functionality (e.g., usaspending_get_recipient, usaspending_search_awards). This effectively distinguishes it from similar tools like usaspending_get_award_subawards.
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 guidance that the award_id should come from usaspending_search_awards, and notes related tools for recipient and NAICS operations. However, it does not state scenarios where this tool should not be used or provide direct comparison with alternatives like usaspending_get_award_subawards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_get_award_subawardsGet Award SubawardsARead-onlyIdempotentInspect
List subaward contracts or grants under a prime federal award. Reveals the sub-contractor or sub-grantee layer — the organizations that actually perform the work. Each row shows the subaward number, amount, description, action date, and recipient. Check subaward_count on usaspending_get_award first to confirm subawards exist before calling this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| sort | No | Sort field for subawards | action_date |
| limit | No | Maximum subawards per page (1–100) | |
| order | No | Sort direction | desc |
| award_id | Yes | Generated unique award ID (generated_internal_id from usaspending_search_awards) |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | List of subawards under this prime award |
| award_id | Yes | Prime award ID queried |
| page_metadata | Yes | Pagination metadata |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral context: it reveals the subaward layer and lists output fields (number, amount, description, action date, recipient). It also warns about checking subaward count first, which aids understanding. Missing details like pagination behavior but schema covers parameters.
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 four sentences, each adding value: purpose, context, output fields, usage guidance. It is front-loaded and concise 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?
Given the tool's complexity (list of subawards), the description covers purpose, output fields, and a precondition check. Since an output schema exists, return values are not required. The description provides sufficient context for effective tool selection and invocation.
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 does not add parameter-specific semantics beyond what the schema provides. It gives general guidance about checking subaward_count but does not explain how parameters like sort or order affect results.
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 specific action 'list subaward contracts or grants under a prime federal award' and distinguishes it from siblings by mentioning the subaward layer and organizations that perform the work. It also references checking subaward_count on a sibling tool, reinforcing purpose differentiation.
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 to check subaward_count first before calling the tool, providing clear when-to-use guidance. It does not enumerate all alternatives (e.g., transactions vs subawards), but the context of sibling tools and the specific recommendation sufficiently guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_get_award_transactionsGet Award TransactionsARead-onlyIdempotentInspect
List individual transactions (contract modifications, grant amendments) on a federal award. Each transaction represents a change event — obligation modifications, performance period extensions, scope changes, etc. Use this to trace the spending history and obligation changes over the life of an award. Award IDs come from usaspending_search_awards (generated_internal_id field).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| sort | No | Sort field for transactions | action_date |
| limit | No | Maximum transactions per page (1–100) | |
| order | No | Sort direction | desc |
| award_id | Yes | Generated unique award ID (generated_internal_id from usaspending_search_awards) |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | List of transactions for this award |
| award_id | Yes | Award ID queried |
| page_metadata | Yes | Pagination metadata |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds behavioral context by explaining what each transaction represents (change events), which goes beyond the 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 two sentences, compact and informative, with no wasted words. 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 presence of an output schema, the description does not need to explain return values. It covers purpose, usage, and data source, making it complete for a query 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 each parameter has a description. The tool description does not add significant meaning beyond what the schema already provides, including the source of award_id. Baseline 3 is appropriate given high schema coverage.
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 lists individual transactions (contract modifications, grant amendments) on a federal award, explaining each transaction represents a change event. It distinguishes from siblings by specifying that award IDs come from usaspending_search_awards, providing specific verb+resource+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?
The description explicitly says to use this tool to trace spending history and obligation changes over an award's life, and where to get the award ID. While it does not explicitly mention when not to use it, the context is clear and sufficient for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_get_federal_accountGet Federal AccountARead-onlyIdempotentInspect
Fetch a federal account's budget data: total obligations, gross outlays, and budgetary resources. Federal accounts connect appropriations law to actual agency spending. Account codes appear in usaspending_get_award account_obligations_by_defc field and are formatted as AGENCY-MAIN (e.g., 097-0100 for DoD Operation and Maintenance). Returns account metadata and current fiscal year financial totals.
| Name | Required | Description | Default |
|---|---|---|---|
| account_code | Yes | Federal account code in AGENCY-MAIN format (e.g., 097-0100). Appears in award funding details from usaspending_get_award. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bureau_name | No | Bureau name within the agency |
| fiscal_year | No | Fiscal year of the financial data |
| account_title | No | Full account title |
| agency_identifier | No | Agency identifier code |
| main_account_code | No | Main account code |
| parent_agency_name | No | Managing parent agency name |
| federal_account_code | No | Federal account code |
| total_obligated_amount | No | Total obligated amount in USD |
| total_budgetary_resources | No | Total budgetary resources in USD |
| total_gross_outlay_amount | No | Total gross outlay amount in USD |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that the tool returns account metadata and current fiscal year financial totals, which is consistent and adds value. 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?
Two sentences plus a descriptive sentence, no wasted words. Front-loaded with purpose and return data. Efficient.
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?
Tool is moderate complexity with one parameter. Description explains what is returned (obligations, outlays, resources, metadata, totals) and the relationship to awards. Output schema exists, so no need to detail return structure.
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 covers 100% of the single parameter. Description adds meaning: format example, origin from usaspending_get_award, and field reference, going beyond schema description.
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 'Fetch a federal account's budget data' with specific fields (obligations, outlays, resources). It distinguishes from sibling tools by mentioning that account codes come from usaspending_get_award, avoiding tautology.
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?
Explains that federal accounts connect appropriations law to spending and that account codes are formatted as AGENCY-MAIN, providing context on when to use this tool. Does not explicitly state when not to use it, but gives clear guidance via examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_get_recipientGet Recipient ProfileARead-onlyIdempotentInspect
Fetch a recipient's full profile including address, business type classifications, parent organization, alternate names, and total award amounts by category. Recipient IDs are UUID hashes with a level suffix (-P parent, -C child, -R standalone) from usaspending_search_recipients or usaspending_get_award. Optionally scope the award totals to a specific fiscal year and award type. UEI and DUNS values can be used to cross-reference with SAM.gov and SEC EDGAR.
| Name | Required | Description | Default |
|---|---|---|---|
| award_type | No | Award type category to scope award totals | |
| fiscal_year | No | Fiscal year to scope award totals (e.g., 2024) | |
| recipient_id | Yes | Recipient hash ID (UUID with level suffix, e.g., b97d19b0-833c-8d8f-3a2c-157d04ea55ef-P) — from usaspending_search_recipients or usaspending_get_award |
Output Schema
| Name | Required | Description |
|---|---|---|
| uei | No | Unique Entity Identifier (SAM.gov) |
| duns | No | DUNS number (legacy) |
| name | No | Recipient legal business name |
| total | No | Total award amounts by type |
| location | No | Recipient address |
| parent_uei | No | Parent organization UEI |
| parent_name | No | Parent organization name |
| recipient_id | No | Recipient hash ID |
| business_types | No | Business type codes |
| alternate_names | No | Alternate business names |
| recipient_level | No | Hierarchy level: P = parent, C = child, R = standalone |
| business_types_description | No | Human-readable business type descriptions |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the agent knows it's a safe read operation. The description adds the ID format and cross-referencing context but doesn't disclose additional behavioral traits like error handling or rate limits. This is adequate but not rich, as annotations carry most of the burden.
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, no unnecessary words, front-loaded with the core purpose. Every sentence adds essential information: what the tool does, how to get the ID, and optional scoping. Excellent structure.
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 (3 parameters, output schema exists), the description covers all needed context: ID format, scoping, cross-references, and recipient levels. It is complete for an agent to correctly select and invoke the tool without additional documentation.
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 significant value for recipient_id by explaining its format (UUID with level suffix) and source (from other tools). For award_type and fiscal_year, the description largely restates the schema, but the overall addition crosses the threshold to 4.
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 a recipient's full profile with specific fields (address, business type, parent org, alternate names, total award amounts). It distinguishes from sibling tools like usaspending_search_recipients (search) and usaspending_get_award (award details), using specific verbs and resource.
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 when to use (fetch recipient profile), how to obtain the required recipient_id (from usaspending_search_recipients or usaspending_get_award), and explains the ID format (UUID with level suffix). It also mentions optional scoping (fiscal year, award type) and cross-referencing with SAM.gov and SEC EDGAR, providing complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_list_agenciesList Federal AgenciesARead-onlyIdempotentInspect
List all top-tier federal agencies with toptier codes, agency slugs, budget authority amounts, and obligation totals for the current fiscal year. Use this as the entry point for agency navigation — toptier codes and agency slugs are required inputs for usaspending_get_agency and agency-based filters on spending analysis tools.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort field: agency_name (alphabetical), budget_authority_amount, obligated_amount, or outlay_amount | agency_name |
| order | No | Sort direction: asc or desc | asc |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total number of agencies returned |
| results | Yes | List of top-tier federal agencies with budget and obligation data |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true. The description adds value by specifying the fiscal year scope ('current fiscal year') and the exact fields returned, providing more context for agent decision-making beyond the 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 consists of two concise, front-loaded sentences with no waste. The first sentence states the core functionality, and the second provides critical usage guidance. Every word 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?
The description covers the essential outputs and usage context. With annotations providing safety and idempotency information, and an output schema present, the description is nearly complete. It does not mention pagination or limits, but for a listing tool returning all items, this is a minor gap.
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 well-described enums and defaults. The description mentions fields that correspond to sort options but does not add new parameter-level information 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 explicitly states 'List all top-tier federal agencies' with specific data fields (toptier codes, agency slugs, budget authority amounts, obligation totals) and clearly distinguishes itself from siblings by positioning itself as the entry point for agency navigation, noting that its outputs are required inputs for usaspending_get_agency and other filters.
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 strong usage guidance: 'Use this as the entry point for agency navigation' and explains that toptier codes and agency slugs from this tool are prerequisites for usaspending_get_agency and agency-based filters. This gives a clear indication of when to use this tool before alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_search_awardsSearch Federal AwardsARead-onlyIdempotentInspect
Search federal awards by keyword, recipient, agency, award type, NAICS code, location, or date range. Returns ranked award summaries including recipient names, amounts, awarding agencies, and generated award IDs for use with usaspending_get_award. Award types: A/B/C/D = contracts, 02/03/04/05 = grants, 06/10 = direct payments, 07/08 = loans, IDV_A/IDV_B/IDV_C/IDV_D/IDV_E = IDVs. Dates must be ISO 8601 (YYYY-MM-DD). Earliest data: 2007-10-01 via search API. DoD contracts have a 90-day publication lag.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| sort | No | Sort field for results | Award Amount |
| limit | No | Maximum results per page (1–100) | |
| order | No | Sort direction | desc |
| keyword | No | Full-text search across award descriptions, recipient names, and place names | |
| naics_code | No | Filter by NAICS industry code (e.g., "541512"). Use usaspending_autocomplete type=naics to look up codes. | |
| agency_name | No | Filter to a specific awarding agency by name (e.g., "Department of Defense"). Use usaspending_autocomplete type=awarding_agency to find exact names. | |
| time_period | No | Filter awards by date range (action date) | |
| recipient_name | No | Filter by recipient name (partial match). Use usaspending_search_recipients for precise recipient_id filtering. | |
| location_filter | No | Filter by place of performance location. Uses FIPS codes and 2-letter state abbreviations, not place names — use a geocoding server to resolve names to codes first. | |
| award_type_codes | No | Filter by award type codes. All codes must belong to a single group: A/B/C/D (contracts), 02/03/04/05 (grants), 06/10 (direct payments), 07/08 (loans), IDV_A–IDV_E (IDVs). Defaults to contracts. Mixing groups across categories causes a 422 error. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | No | Recovery hint when results are empty — echoes applied filters and suggests how to broaden. Absent when results are present. |
| results | Yes | Matching award summaries |
| page_metadata | Yes | Pagination metadata |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds critical behavioral context: 90-day publication lag for DoD contracts, earliest data date (2007-10-01), and that mixing award type code groups causes a 422 error. 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 a single paragraph that efficiently covers purpose, parameters, and caveats. Slightly dense but all sentences serve a purpose. Could be broken into bullet points for readability, but not required.
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 11 parameters (all optional, many nested), rich schema, output schema, and annotations, the description covers all essential caveats: date range limits, publication lag, award type grouping, location code requirements, and cross-references to sibling tools. No gaps.
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 meaning: lists award type codes with their category mappings, emphasizes ISO 8601 date format, explains location filter codes vs. place names, and highlights the 90-day lag. Goes well 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?
The description clearly states it searches federal awards by multiple criteria, returns ranked summaries, and distinguishes from usaspending_get_award by specifying that returned award IDs can be used with that sibling tool.
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?
Provides explicit guidance: when to use (search), when not (individual award retrieval directs to usaspending_get_award), and prerequisites (use usaspending_autocomplete for NAICS/agency names, usaspending_search_recipients for recipient_id, geocoding for location codes). Warns about award type group mixing causing errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_search_recipientsSearch Award RecipientsARead-onlyIdempotentInspect
Search for organizations or individuals receiving federal funds by name or UEI (Unique Entity Identifier). Returns recipient IDs (UUID hashes), total award amounts, business type classifications, and location data. Recipient IDs from this tool can be passed to usaspending_get_recipient for full profiles. Recipient level: P = parent organization, C = child entity, R = standalone.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1–100) | |
| keyword | Yes | Name, UEI, DUNS, or keyword to search for — partial matches are supported | |
| award_type | No | Filter by award type category to scope the total amounts returned |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of results returned |
| message | No | Recovery hint when results are empty — suggests how to broaden the search. Absent when results are present. |
| results | Yes | Matching recipients |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent. The description adds value by specifying the return includes UUID hashes, total amounts, business types, and location, and explains the recipient level classification. 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 three sentences plus a recipient level note, all front-loaded with the core function. Every sentence adds distinct value—function, usage link, and classification detail—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?
Given the complexity of federal spending data and the presence of an output schema, the description sufficiently covers what is returned (IDs, amounts, classifications, location) and how to use the output with another tool. No major gaps identified.
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 all parameters have descriptions. The description repeats the schema's explanation for keyword (partial matches) and award_type (scoping total amounts) but does not add new semantic information beyond the schema. 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 the tool searches for recipients by name or UEI, and distinguishes from sibling tools like usaspending_get_recipient. The verb is 'search' and resource is 'recipients', 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 provides guidance on using the returned recipient IDs with usaspending_get_recipient, and explains the recipient level codes (P, C, R). It lacks explicit when-not-to-use instructions, but the context of sibling tools makes it clear this is the only recipient search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_spending_by_categorySpending by CategoryARead-onlyIdempotentInspect
Aggregate federal spending grouped by a specific dimension: NAICS industry code, PSC product/service code, awarding agency, funding agency, CFDA assistance program, or recipient. Returns top items with obligation amounts — useful for trend and breakdown analysis. Chain NAICS codes into usaspending_search_awards filters or usaspending_autocomplete lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based) | |
| limit | No | Maximum items to return (1–100) | |
| filters | No | Optional filters to scope the aggregation | |
| category | Yes | Breakdown dimension: naics (industry), psc (product/service code), awarding_agency, awarding_subagency, funding_agency, funding_subagency, cfda (assistance programs), recipient_duns, or recipient_parent_duns |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | No | Recovery hint when results are empty — suggests how to broaden filters. Absent when results are present. |
| results | Yes | Top items in this category by obligation amount |
| category | Yes | Breakdown dimension used |
| page_metadata | Yes | Pagination metadata |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds context about returning aggregated obligation amounts and top items, but does not introduce any contradictory behavior. It provides functional detail 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?
The description is three sentences with no wasted words. It front-loads the core function, then states usefulness, then cross-tool usage. Each sentence 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?
Given the tool's complexity (one required parameter with enum, optional filters, output schema exists), the description is complete. It covers what the tool does, what it returns, and how it integrates with other tools in the suite.
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%. The description adds value by explicitly listing the possible category dimensions (NAICS, PSC, agency, etc.) and explaining the tool's aggregate nature, which provides semantic context beyond the schema. However, it does not detail page, limit, or filters.
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 that the tool aggregates federal spending by a specific dimension and returns top items with obligation amounts. It lists the possible categories and indicates usefulness for trend and breakdown analysis, distinguishing it from sibling tools like search or geography 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 description provides guidance on when to use the tool ('useful for trend and breakdown analysis') and how to chain results with other tools (usaspending_search_awards, usaspending_autocomplete). However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_spending_by_geographySpending by GeographyARead-onlyIdempotentInspect
Aggregate federal spending by state, county, or congressional district. Useful for per-capita analysis, regional comparisons, and mapping federal investment patterns. Geographic filters accept FIPS codes and 2-letter state abbreviations — NOT place names. Resolve place names to FIPS codes using a geocoding server (Census or OpenStreetMap) before applying location filters. Chain per-capita results with Census population data for meaningful comparisons.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | Which location to aggregate by: place_of_performance (where work is done) or recipient_location (where the recipient is based) | |
| filters | No | Optional filters to scope the spending aggregation | |
| geo_layer | Yes | Geographic granularity: state (50 states), county (county-level), or district (congressional district) | |
| subawards | No | Include subaward data instead of prime award data |
Output Schema
| Name | Required | Description |
|---|---|---|
| scope | Yes | Location scope used for aggregation |
| total | Yes | Number of geographic areas returned |
| results | Yes | Spending totals by geographic area |
| geo_layer | Yes | Geographic granularity used |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true. The description adds valuable behavioral context beyond these, such as the fact that geographic filters require codes rather than names, and that chaining with Census data is needed for per-capita ratios. 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, consisting of about 5 sentences. It is front-loaded with the primary purpose, followed by relevant context and actionable instructions. Every sentence serves a clear purpose 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?
Given the tool's moderate complexity (4 parameters, 2 required, nested objects, and output schema), the description covers the core purpose, usage scenarios, and critical prerequisite (geocoding). While it does not explain the output format, the presence of an output schema mitigates that gap. The description is sufficiently complete for an agent to use the tool effectively.
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 meaningful value by explaining the requirement to use FIPS codes and state abbreviations for geographic filters, and hints at resolving place names externally. This compensates for any lack of detail in the schema descriptions and provides practical insight for parameter usage.
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 'Aggregate federal spending by state, county, or congressional district', providing a specific verb and resource. It distinguishes itself from sibling tools like spending_by_category and spending_over_time by focusing on geographic aggregation, and adds context for per-capita analysis and mapping.
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 states when to use this tool ('useful for per-capita analysis, regional comparisons...') and provides crucial prerequisite guidance: geographic filters accept FIPS codes and state abbreviations, not place names, and instructs to resolve place names via geocoding. However, it does not explicitly mention when to prefer alternative tools, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usaspending_spending_over_timeSpending Over TimeARead-onlyIdempotentInspect
Fetch aggregated federal obligation amounts grouped by fiscal year, fiscal quarter, or calendar month. Filter by award type, agency, recipient, keyword, or NAICS code to trace spending trends in a specific area. Returns per-period totals and optional breakdowns by award category (contracts, grants, direct payments, loans, other).
| Name | Required | Description | Default |
|---|---|---|---|
| group | Yes | Time grouping: fiscal_year (annual US govt FY: Oct–Sep), quarter (fiscal quarter), or month (calendar month) | |
| filters | No | Filters to scope the time-series aggregation. Defaults to contract awards when omitted. | |
| subawards | No | Aggregate subaward data instead of prime award data |
Output Schema
| Name | Required | Description |
|---|---|---|
| group | Yes | Time grouping used |
| results | Yes | Time-series of obligation totals |
| total_periods | Yes | Number of time periods returned |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, covering key behavioral traits. The description adds that it returns aggregated totals and optional breakdowns but does not elaborate on pagination, rate limits, or data source freshness. No contradiction 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?
Two sentences with no wasted words. The first sentence front-loads the action and grouping, the second sentence covers filters and return value. Efficient and scannable.
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 covers core functionality, filters, and return content. It does not explicitly mention the subawards parameter (present in schema) but this is minor given the output schema covers return structure. Overall well-rounded for a tool with high schema coverage and output schema.
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 schema already documents all parameters. The description reiterates the main filter options but adds no new semantic information beyond what the schema provides, yielding a baseline score.
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 aggregated federal obligation amounts grouped by time periods, listing specific grouping options and many filter types. It distinguishes itself from sibling tools like usaspending_spending_by_category by focusing on time-series trends and optional breakdowns by award category.
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 implies the tool is for tracing spending trends over time with various filters, but does not explicitly state when to use it over alternatives like usaspending_spending_by_geography or usaspending_spending_by_category. No when-not-to-use or alternative cues are provided.
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!