Capture MCP Server
Capture MCP Server lets you query and analyze U.S. federal procurement, entity, and spending data via natural language through MCP-compatible clients like Claude Desktop, returning human-readable text plus structured JSON.
Reference lookups: Decode FPDS codes for set-aside, extent-competed, award type, solicitation procedure, and competition (no API key needed).
USASpending.gov queries: Get agency awards, spending by category, budgetary resources, recipient-based award searches, and full FPDS award details.
Contract aggregation: Group awards by agency, sub-agency, recipient, NAICS, PSC, month, or set-aside with obligation totals or counts.
SAM.gov tools: Search federal entities, discover contract opportunities, retrieve company profiles, and check exclusions (requires SAM.gov API key).
Data joining: Combine SAM entity data with spending history, and link opportunities with market context.
Tango API tools: Search contracts, grants, opportunities, IDVs, vehicles, OTAs, protests, vendor profiles, and entity spending metrics (requires Tango API key).
HigherGov tools: Search forecasts, opportunities, contracts, people/POCs, and pull solicitation documents (requires HigherGov API key).
Flexible deployment: Runs locally via stdio, as a hosted AWS serverless service, or on Railway with optional OAuth and API-key passthrough.
Consistent response conventions: Filter echo, honest totals, labeled units/dates, cursor pagination, validated codes, and rejection of unknown parameters.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Capture MCP ServerShow me recent federal contracts over $1 million"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Capture MCP Server
An MIT-licensed, AI-native Model Context Protocol (MCP) server that integrates SAM.gov, USASpending.gov, Tango, and HigherGov APIs to capture and analyze federal procurement and spending data through natural language queries. Responses include both human-readable text and structured JSON so MCP-compatible clients can consume the data programmatically.
Overview
Capture MCP empowers users to capture and query federal entity, opportunity, and spending data through LLM applications like Claude Desktop. It provides 34 specialized tools that can search, analyze, aggregate, and join data from multiple government APIs.
Compatible with: Claude Desktop, ChatGPT Desktop (Pro+), and any MCP-compatible client
Related MCP server: USASpending MCP Server
Table of Contents
Features
Structured outputs – Every tool call returns JSON alongside descriptive text for best-in-class client compatibility.
Safe rate limiting – Queue-based throttling prevents accidental quota overruns on SAM.gov, USASpending.gov, and Tango APIs.
Input hygiene – Argument sanitization strips control characters while keeping meaningful punctuation intact.
Reference Data (1 tool - No API key required)
lookup_reference_code- Official FPDS descriptions for set-aside, extent-competed, award-type, solicitation-procedure, and competition codes (e.g.8A= 8(a) Competed vs8AN= 8(a) Sole Source)
USASpending.gov Integration (6 tools - No API key required)
get_usaspending_awards- Agency award summariesget_usaspending_spending_by_category- Spending breakdownsget_usaspending_budgetary_resources- Budget informationsearch_usaspending_awards_by_recipient- Find awards by companyget_award_detail- Full FPDS record for one award (set-aside, extent competed, offers received) — the verification primitiveaggregate_contracts- Group awards by agency, sub-agency, recipient, NAICS, PSC, month, or set-aside with count/obligations metrics
SAM.gov Integration (4 tools - Requires SAM.gov API key)
search_sam_entities- Find federal contractors and businessesget_sam_opportunities- Discover contract opportunitiesget_sam_entity_details- Get comprehensive company profilescheck_sam_exclusions- Verify contractor eligibility
Data Joining (2 tools - Requires SAM.gov API key)
get_entity_and_awards- Combine SAM entity data with spending historyget_opportunity_spending_context- Link opportunities with market context
Tango API Integration (12 tools - Requires Tango API key)
search_tango_contracts- Search federal contracts through unified APIsearch_tango_grants- Search federal grants and financial assistanceget_tango_vendor_profile- Get comprehensive vendor profiles with historysearch_tango_opportunities- Search contract opportunities with forecastsget_tango_spending_summary- Get spending summaries and analytics (page-scoped; useaggregate_contractsfor population figures)search_tango_protests- Search GAO bid protests (agency, protester, outcome, dates)get_tango_protest- Get full bid protest record by ID or case numbersearch_tango_idvs- Search IDIQs / BPAs / FSS that issue task ordersget_tango_idv_children- Get child IDVs, task orders, and transactions under one IDVsearch_tango_vehicles- Search the federal contract-vehicle catalog (GWACs, MAS, BPAs)search_tango_otas- Search Other Transaction Authority (OTA) awardsget_tango_entity_metrics- Time-series obligations for one UEI (month/quarter/year)
HigherGov Integration (9 tools - Requires HigherGov API key)
search_highergov_forecasts- Forecasts from a HigherGov saved searchsearch_highergov_opportunities- Active opportunities by set-aside bundle, NAICS, PSC, agency, and datesget_highergov_opportunity- One opportunity by ID, SAM notice ID, or URLget_opportunity_documents- Solicitation documents and amendments with fetchable URLslist_highergov_saved_searches- Saved searches available to the API keysearch_highergov_contracts- Awarded contracts for recompete targeting (agency, NAICS, PSC, set-aside, PoP end, value)get_highergov_contract- Full record for one contract by ID or PIIDsearch_highergov_people- Federal POCs by agency and role keywordsget_highergov_person- Full POC profile including verified email
Response conventions
Every list tool follows the same contract, so an agent can always tell what actually ran:
Filter echo —
filters.upstreamvsfilters.client_side: exactly which filters the upstream API applied and which the server enforced on the returned page.Honest totals —
totalis only populated when trustworthy. Client-side filtering moves it tototal_upstream_unfiltered; known-loose upstream matching moves it tototal_upstream_unverified. Both come withwarnings.Labeled units and dates —
count_unitsays what is being counted (awards vs transactions vs notices) anddate_fieldsays which date a date filter compared.One cursor shape —
next_cursoron every list response; pass it back ascursorto page.nullmeans last page.Codes with descriptions — set-aside codes are returned as
{code, description}, validated against the FPDS table.Unknown parameters are rejected with a
bad_requestnaming the accepted list — never accepted-and-ignored.
Tool Availability Matrix
The server automatically enables tools based on which API keys you provide:
API Keys Provided | Tool Sets Enabled | Total Tools |
None (works out of the box) | Reference + USASpending.gov | 7 tools |
| + SAM.gov + Join tools | +6 tools |
| + Tango API | +12 tools |
| + HigherGov | +9 tools |
All three keys | All tool sets | 34 tools |
Quick Start
Prerequisites
Node.js 18+ (included with Claude Desktop for .mcpb installation)
Claude Desktop or ChatGPT Desktop (Pro/Plus/Business/Enterprise/Education)
API Keys (Optional - see API Keys section):
None required: 7 tools (reference + USASpending.gov) work immediately
SAM.gov API key: adds 6 more tools
Tango API key: adds 12 more tools
HigherGov API key: adds 9 more tools
All three keys: all 34 tools
Choose Your Installation Method
For Claude Desktop users: Use Method 1: One-Click Installation for the easiest setup with a graphical API key configuration interface.
For ChatGPT Desktop or other MCP clients: Use Method 2: Standard MCP Configuration which works universally across all MCP-compatible applications.
For hosting your own service: Use Method 3: Hosted Version (AWS Serverless) to deploy a shared Capture MCP service for your organization on AWS.
Installation Methods
Method 1: One-Click Installation (Claude Desktop)
Desktop Extensions (.mcpb files) provide the easiest installation experience for Claude Desktop users. No terminal, no configuration files, no dependency conflicts.
What is a Desktop Extension?
A .mcpb file is a bundled MCP server package (similar to a Chrome extension or VS Code extension) that contains:
The complete MCP server code
All dependencies pre-installed
Configuration metadata and branding
Installation prompts for API keys
Installation Steps
Step 1: Build the Extension Package
# Clone the repository
git clone https://github.com/blencorp/capture-mcp-server.git
cd capture-mcp-server
# Install dependencies
npm install
# Create the .mcpb package
npm run packageThis creates capture-mcp-server.mcpb (~4.2MB) in the current directory.
Step 2: Install in Claude Desktop
Option A: Double-click Installation
Locate the
capture-mcp-server.mcpbfileDouble-click the file to open with Claude Desktop
Click "Install" in the installation dialog
Option B: Settings Installation
Open Claude Desktop
Go to Settings → Extensions (or Developer → Edit Config)
Click "Install Extension..." or drag the
.mcpbfile into the settings windowClick "Install" when prompted
Step 3: Configure API Keys (Optional)
During or after installation, Claude Desktop will prompt you to configure API keys:
Skip all keys: Click "Continue" without entering keys → 7 keyless tools available immediately
Enter one key: Provide a SAM.gov, Tango, or HigherGov key → that provider's tools are added
Enter all keys: All 34 tools available
You can add or update API keys later via Settings → Extensions → Capture MCP Server → Configure.
Step 4: Verify Installation
Restart Claude Desktop
Open Settings → Extensions (or Developer → MCP Servers)
Verify "Capture MCP Server" shows as "Connected"
Start a new conversation and ask: "What tools are available from Capture MCP Server?"
Important Notes for .mcpb Installation
Compatibility Warning: The .mcpb format requires Claude Desktop v1.0.0 or later. If you see errors like "This extension requires an update to Claude Desktop" or "Unrecognized key(s)", please:
Update Claude Desktop to the latest version, OR
Use Method 2: Standard MCP Configuration instead
Why Node.js? This server is built in Node.js because Claude Desktop bundles Node.js on macOS and Windows, meaning the extension works immediately without requiring users to install Python or other runtimes.
Method 2: Standard MCP Configuration (Recommended)
Standard MCP configuration is the most reliable method and works universally across all MCP clients including Claude Desktop, ChatGPT Desktop, and custom implementations.
Step 1: Clone and Build
# Clone the repository
git clone https://github.com/blencorp/capture-mcp-server.git
cd capture-mcp-server
# Install dependencies
npm install
# Build TypeScript to JavaScript
npm run buildThis creates compiled JavaScript files in the dist/ directory.
Step 2: Locate Your MCP Configuration File
Claude Desktop (macOS):
~/Library/Application Support/Claude/claude_desktop_config.jsonClaude Desktop (Windows):
%APPDATA%\Claude\claude_desktop_config.jsonChatGPT Desktop (macOS):
~/Library/Application Support/ChatGPT/mcp_config.jsonChatGPT Desktop (Windows):
%APPDATA%\ChatGPT\mcp_config.jsonNote: For ChatGPT Desktop, you need a Pro, Plus, Business, Enterprise, or Education subscription. Check Settings → Beta Features → Developer Mode to enable MCP support.
Step 3: Add Server Configuration
Open your MCP configuration file and add the Capture MCP Server configuration. Choose the appropriate configuration based on which API keys you have:
Configuration A: No API Keys (7 keyless tools)
{
"mcpServers": {
"capture-mcp-server": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/capture-mcp-server/dist/server.js"]
}
}
}Configuration B: SAM.gov API Key Only (13 tools)
{
"mcpServers": {
"capture-mcp-server": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/capture-mcp-server/dist/server.js"],
"env": {
"SAM_GOV_API_KEY": "your-sam-api-key-here"
}
}
}
}Configuration C: Tango API Key Only (16 tools)
{
"mcpServers": {
"capture-mcp-server": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/capture-mcp-server/dist/server.js"],
"env": {
"TANGO_API_KEY": "your-tango-api-key-here"
}
}
}
}Configuration D: HigherGov API Key Only (16 tools)
{
"mcpServers": {
"capture-mcp-server": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/capture-mcp-server/dist/server.js"],
"env": {
"HIGHERGOV_API_KEY": "your-highergov-api-key-here"
}
}
}
}Configuration E: All API Keys (All 34 tools)
{
"mcpServers": {
"capture-mcp-server": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/capture-mcp-server/dist/server.js"],
"env": {
"SAM_GOV_API_KEY": "your-sam-api-key-here",
"TANGO_API_KEY": "your-tango-api-key-here",
"HIGHERGOV_API_KEY": "your-highergov-api-key-here"
}
}
}
}Critical: Replace /ABSOLUTE/PATH/TO/capture-mcp-server with the actual absolute path to where you cloned the repository.
Examples:
macOS:
/Users/yourname/projects/capture-mcp-serverWindows:
C:\Users\yourname\projects\capture-mcp-server
Step 4: Restart Your MCP Client
Claude Desktop: Quit completely (Cmd+Q on macOS) and reopen
ChatGPT Desktop: Quit completely and reopen
Step 5: Verify Installation
In Claude Desktop:
Open Settings → Developer → MCP Servers
Look for "capture-mcp-server" with status "Connected"
In ChatGPT Desktop:
Open Settings → Beta Features → Developer Mode
Check MCP Servers section shows "capture-mcp-server" as "Connected"
Test the connection: Ask in a new conversation: "List all available tools from the Capture MCP Server"
You should see 7-34 tools listed depending on your API key configuration.
Method 3: Hosted Version (AWS Serverless)
Deploy a shared Capture MCP service on AWS for your organization. You deploy once, then create API keys (cap_xxx...) to distribute to your users. The serverless architecture costs ~$1-11/month and scales automatically.
Architecture
┌──────────────┐ ┌─────────────────┐ ┌──────────────┐
│ MCP Client │────▶│ API Gateway │────▶│ Lambda │
│ │ │ (HTTP API) │ │ (MCP Handler)│
└──────────────┘ └─────────────────┘ └──────┬───────┘
│
┌─────────────────┐ │
│ S3 Bucket │◀───────────┘
│ (API Keys) │ (HeadObject for auth)
└─────────────────┘Prerequisites
AWS Account with permissions for Lambda, API Gateway, S3, CloudFormation, and IAM
AWS CLI installed and configured (installation guide)
Node.js 20.x or later
AWS CDK CLI:
npm install -g aws-cdk
AWS Credentials Setup
Before deploying, ensure your AWS credentials are configured. The CDK uses the same credential resolution as the AWS CLI.
Option 1: Default Profile
aws configure
# Enter your Access Key ID, Secret Access Key, and default region (e.g., us-east-1)Option 2: Named Profile
aws configure --profile my-profile
export AWS_PROFILE=my-profileOption 3: Environment Variables
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
export AWS_REGION=us-east-1Verify your credentials are working:
aws sts get-caller-identityStep 1: Deploy to AWS
# Install CDK dependencies
cd infrastructure
npm install
cd ..
# Bootstrap CDK (first time only per account/region)
npm run cdk:bootstrap
# Build and deploy (requires manual approval for security-sensitive changes)
npm run cdk:deploy
# Or skip approval prompts entirely (use with caution)
npm run cdk:deploy:yoloDeploy Options:
npm run cdk:deploy— Prompts for manual approval before creating/updating IAM roles, security groups, or other sensitive resources. Recommended for production.npm run cdk:deploy:yolo— Skips all approval prompts (--require-approval never). Faster for development/testing, but use with caution in production.
What is CDK Bootstrap? The first time you deploy a CDK app to an AWS account/region, you need to provision initial resources that CDK uses (S3 bucket for assets, IAM roles, etc.). This is a one-time setup. Learn more: CDK Bootstrapping
# Verify deployment succeeded - check the health endpoint
curl https://<your-api-url>/healthStep 2: Sync Configuration
After deployment, run sync-config to read the CloudFormation stack outputs and save them locally:
npm run sync-configThis creates .capture-mcp.json (gitignored) containing your deployment's bucket name, endpoint URL, and region. This is required before you can manage API keys or build the hosted extension package.
Step 3: Create API Keys for Users
Now create API keys for each user who needs access:
# Create a key that never expires
npm run manage-keys -- create --owner "John Doe"
# Create a key with an expiration date
npm run manage-keys -- create --owner "Jane Smith" --expires "2025-12-31"Important: Save the generated key immediately! It's displayed only once and cannot be retrieved later. Keys are stored as SHA-256 hashes in S3 for security.
Key Management Commands:
npm run manage-keys -- list # List all keys with owner and status
npm run manage-keys -- verify <key> # Check if a specific key is valid
npm run manage-keys -- revoke <key> # Revoke a key (by key or hash prefix)Step 4: Build the Hosted Extension Package
Create a .mcpb file pre-configured with your endpoint URL that users can install with one click:
npm run package:hostedThis creates capture-mcp-server-hosted.mcpb containing:
Your MCP endpoint URL (from sync-config)
Prompts for API keys during installation
All metadata and branding
Step 5: Distribute to Users
Option A: Provide the .mcpb File (Recommended)
Send users the capture-mcp-server-hosted.mcpb file along with their API key. They install by:
Double-clicking the
.mcpbfile to open in Claude DesktopEntering their API key (
cap_xxx...) when promptedOptionally entering their own SAM.gov or Tango API keys for additional tools
Clicking Install
Option B: Manual Configuration
For users who prefer manual setup, provide them:
Your MCP endpoint URL (from deployment output)
Their personal API key (
cap_xxx...)
They add this to their Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"capture-hosted": {
"command": "npx",
"args": [
"-y",
"mcp-remote@0.1.31",
"https://YOUR-MCP-ENDPOINT/mcp",
"--header",
"X-Api-Key:cap_xxx..."
]
}
}
}Users can add their own SAM.gov/Tango keys with additional --header arguments.
Cost Estimation
Usage Level | Requests/Month | Estimated Cost |
Low | 100k | ~$1.11/month |
Moderate | 1M | ~$11/month |
Test Your Deployment
# List available tools via curl
curl -X POST https://<your-mcp-endpoint>/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "X-Api-Key: cap_your_api_key_here" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Custom Domain (Optional)
If your domain is managed as a Route53 Hosted Zone, the CDK will automatically:
Create an ACM certificate
Validate it via DNS (Route53)
Create a custom domain in API Gateway
Create an A record pointing to the API Gateway custom domain
Setup:
Create a
.envfile in the project root (copy from.env.example):# .env AWS_REGION=us-east-1 AWS_ACCOUNT=123456789012 DOMAIN_NAME=mcp.example.comDeploy with the custom domain:
npm run cdk:deploy
Requirement: The domain must exist as a hosted zone in Route53. For
mcp.example.com, Route53 must have a hosted zone formcp.example.com.
Updating the Deployment
To update after code changes:
npm run cdk:deploy # Rebuilds and deploys automaticallyTesting Infrastructure
The CDK stack includes comprehensive tests to verify resource configuration:
npm run cdk:testTests cover S3 bucket security settings, Lambda configuration, API Gateway routes and CORS, IAM permissions, CloudWatch log retention, stack outputs, and environment-specific behavior (dev vs prod).
Destroying the Stack
To remove all AWS resources:
# Prompts for confirmation before destroying
npm run cdk:destroy
# Or skip confirmation prompt entirely
npm run cdk:destroy:yoloDestroy Options:
npm run cdk:destroy— Prompts for confirmation before deleting resources. Recommended to prevent accidental deletion.npm run cdk:destroy:yolo— Skips confirmation (--force). Useful for automated teardown or when you're certain.
Note: The S3 bucket is retained by default to preserve API keys. Delete it manually if needed.
Monitoring
CloudWatch Logs:
/aws/lambda/capture-mcp-server(1 month retention)Key Metrics:
AWS/Lambda/Invocations,AWS/Lambda/Duration,AWS/Lambda/ErrorsCustom Metrics:
CaptureMCP/MCPRequestLatency
Security Notes
API Keys: Stored as SHA-256 hashes—raw keys never persisted
S3 Bucket: All public access blocked, SSL enforced
Lambda IAM: Least privilege (S3 read only)
HTTPS Only: All traffic encrypted via API Gateway
Troubleshooting
Problem | Solution |
CDK deploy fails with bootstrap error | Run |
"API key required" (401) | Include |
"Invalid API key" (401) | Verify key with |
AWS credential errors | Run |
Lambda timeout | Check CloudWatch logs; some external APIs may be slow |
API Keys
Why Are API Keys Optional?
This server is designed with flexibility in mind:
USASpending.gov provides a public API that requires no authentication
SAM.gov and Tango require API keys for access to their data
You can start using the server immediately with 4 USASpending.gov tools, then add API keys later to unlock additional capabilities.
How to Get API Keys
SAM.gov API Key (Enables 6 additional tools)
Time to obtain: ~24 hours for activation
Create SAM.gov Account:
Click "Sign In" → "Create Account"
Complete registration and email verification
Request API Access:
Log in to SAM.gov
Navigate to https://sam.gov/data-services/API
Click "Request Public API Key"
Accept terms and conditions
Retrieve Your API Key:
API key will be sent to your registered email
Key may take up to 24 hours to activate
Key is linked to your SAM.gov account
API Key Details:
Format: 64-character alphanumeric string
Rate Limits: Varies by endpoint (typically 1,000-10,000 requests/day)
Cost: Free
Documentation: https://open.gsa.gov/api/entity-api/
Enables these tools:
4 SAM.gov tools (entities, opportunities, details, exclusions)
2 Join tools (entity+awards, opportunity+context)
Tango API Key (Enables 12 additional tools)
Time to obtain: Immediate upon approval
Visit Tango Website:
Request Access:
Click "Get API Access" or "Sign Up"
Fill out the request form
Provide use case details
Receive API Key:
API key provided after account approval
Typically immediate for approved users
API Key Details:
Format: Variable-length string
Rate Limits: Check your account dashboard
Cost: Check pricing at https://tango.makegov.com/pricing
Documentation: https://tango.makegov.com/docs/
Enables these tools:
12 Tango tools (contracts, grants, vendor profiles, opportunities, spending summaries, protests, IDVs, vehicles, OTAs, entity metrics)
Managing API Keys
Standard MCP Configuration
Edit your MCP config file and update the env section with your keys. Restart your client after updating.
Desktop Extension (.mcpb)
Open Claude Desktop → Settings → Extensions
Click on "Capture MCP Server"
Click "Configure"
Update API key fields
Click "Save"
Claude Desktop will automatically restart the server
Security Note: Both methods store API keys securely:
Standard config: Stored in your local config file (accessible only to you)
Desktop extension: Stored in OS keychain (macOS/Windows credential manager)
Testing & Verification
Quick Test Queries
After installation, test that your server is working by asking these questions:
Test Without API Keys (USASpending.gov tools)
Using the Capture MCP Server, get the spending breakdown by category
for agency code 075 (Department of Health and Human Services) for
fiscal year 2024Test SAM.gov Tools (Requires SAM_GOV_API_KEY)
Using the SAM tools, search for entities in California that work
in NAICS code 541512 (computer systems design services)Test Tango Tools (Requires TANGO_API_KEY)
Using Tango, search for recent federal grants in renewable energyTest Join Tools (Requires SAM_GOV_API_KEY)
Using the join tools, get both SAM entity details and award history
for UEI: KAR6JDB1HJ16Using MCP Inspector
The MCP Inspector provides a web-based debugging interface for testing tools without Claude Desktop or ChatGPT.
Step 1: Install MCP Inspector
npm install -g @modelcontextprotocol/inspectorStep 2: Start Server with Inspector
npx @modelcontextprotocol/inspector node dist/server.jsStep 3: Open Web Interface
Navigate to http://localhost:5173 in your browser.
Step 4: Configure API Keys (Optional)
Click the "Environment" tab
Add environment variables:
SAM_GOV_API_KEY: your-key-hereTANGO_API_KEY: your-key-here
Restart the inspector
Step 5: Test Tools
View available tools (7-34 depending on API keys)
Click a tool to see its schema
Fill in parameters and click "Execute"
View responses and debug any issues
The Inspector is especially useful for:
Testing new tool implementations
Debugging API integration issues
Understanding tool parameters and responses
Demonstrating capabilities without Claude Desktop
Troubleshooting
Server Won't Start
Symptom: Server doesn't appear in client or shows as "Disconnected"
Solutions:
Verify Build:
cd /path/to/capture-mcp-server npm run buildEnsure build completes without errors.
Check Node.js Version:
node --versionMust be ≥18.0.0. Update Node.js if needed.
Verify Absolute Path:
Open your MCP config file
Ensure the path starts with
/(macOS/Linux) orC:\(Windows)Path should NOT use
~or environment variablesPath should NOT be relative (e.g.,
./dist/server.js)
Check for Typos:
Verify
dist/server.jsexists at the specified pathCheck JSON syntax (no trailing commas, matching braces)
Restart Client Completely:
Quit the application entirely (not just close window)
Reopen and check connection status
Check Client Logs:
Claude Desktop: Settings → Developer → View Logs
ChatGPT Desktop: Check application logs
Look for error messages related to "capture-mcp-server"
No Tools Appearing
Symptom: Server connects but no tools are visible
Solutions:
Verify API Keys (if using them):
Check for typos in API key values
Ensure no extra spaces or quotes
Verify keys are active (SAM.gov keys take 24 hours to activate)
Confirm Minimum Tool Set:
Without ANY keys, you should see 4 USASpending.gov tools
If you see 0 tools, the server isn't loading correctly
Test with Inspector:
npx @modelcontextprotocol/inspector node dist/server.jsThis will show exactly which tools are loading and any errors.
Enable Debug Mode: Add to your env configuration:
"env": { "DEBUG": "true" }Check logs for detailed error messages.
Desktop Extension (.mcpb) Installation Issues
Symptom: "This extension requires an update to Claude Desktop" or "Unrecognized key(s)"
Explanation: The .mcpb format specification has evolved. Some versions of Claude Desktop may support different manifest versions.
Solutions:
Update Claude Desktop (Recommended):
Check for updates: Settings → About
Update to the latest version
Try installing the .mcpb again
Use Standard MCP Configuration (Always Works):
Skip the .mcpb installation
Standard configuration is more reliable and works with all clients
Verify Manifest Version: If you're building from source, check
manifest.json:"manifest_version": "0.2"Some Claude Desktop versions require
"0.2"instead of"0.3"Rebuild Package:
npm run build npm run packageTry installing the freshly built .mcpb file.
Check Icon File: Ensure
icon.pngexists in the root directory (not in subdirectories).
API Key Issues
Symptom: Tools requiring API keys return errors like "Unauthorized" or "Invalid API key"
Solutions:
Verify Key Validity: Test your SAM.gov API key:
curl "https://api.sam.gov/entity-information/v3/entities?api_key=YOUR_KEY&limit=1"Should return JSON data, not an error.
Check SAM.gov Key Activation:
SAM.gov keys can take up to 24 hours to activate after creation
Wait and try again later if key is newly created
Remove Extra Characters:
API keys should have no spaces, quotes, or newlines
Copy key carefully from source
In JSON config, key should be inside quotes:
"SAM_GOV_API_KEY": "abc123..."
Verify Key Permissions:
Log in to SAM.gov to check API key status
Ensure key has necessary permissions enabled
Test with MCP Inspector:
Use Inspector to test API calls directly
View exact error messages from API
ChatGPT Desktop Issues
Symptom: "MCP not available" in ChatGPT Desktop
Solutions:
Verify Subscription:
Requires Pro, Plus, Business, Enterprise, or Education subscription
Free tier does NOT support MCP
Enable Developer Mode:
Settings → Beta Features
Toggle on "Developer Mode"
Check ChatGPT Version:
Requires ChatGPT Desktop ≥1.2025.x (September 2025+)
Update if needed: Help → Check for Updates
Use Correct Config File:
Must be
mcp_config.json(NOTclaude_desktop_config.json)Location:
~/Library/Application Support/ChatGPT/mcp_config.json
Verify JSON Structure: ChatGPT uses the same MCP config format as Claude Desktop:
{ "mcpServers": { "capture-mcp-server": { ... } } }
Rate Limiting Issues
Symptom: Tools return errors like "Too Many Requests" or "Rate limit exceeded"
Solutions:
Built-in Rate Limiting: This server includes automatic rate limiting:
SAM.gov: 100ms delay between requests
USASpending.gov: 3.6s delay (respects ~1000/hour limit)
Tango: 100ms delay between requests
Reduce Query Frequency:
Avoid rapid-fire queries
Use
limitparameters to reduce result sizesCombine queries where possible
Check API Quotas:
SAM.gov: Check your key's daily limit
Tango: Check your account dashboard
Wait and Retry:
Rate limits typically reset hourly or daily
Wait 1 hour and try again
Example Queries
Once installed, you can ask natural language questions. The LLM will automatically select and use the appropriate tools.
General Business Intelligence
Find janitorial service contracts awarded to service-disabled
veteran-owned businesses in the past 6 monthsWhat's the total federal spending on cybersecurity contracts
in fiscal year 2023?List all 8(a) set-aside opportunities from federal agencies
posted in the last 30 daysAgency-Specific Queries
What was the total obligated spending by HHS (Department of Health
and Human Services) on cloud computing last fiscal year?Show me recent contract awards for 'penetration testing'
under $250,000 by the Department of DefenseContractor Research
Find the complete profile and award history for contractor with
UEI: ZQGGHJH74DW7Search for all IT consulting companies registered in Virginia,
then analyze their federal contract historyMarket Analysis
What are the active landscaping maintenance contracts in Florida?Show me building maintenance and repair contracts over $100,000
awarded this year across all agenciesMulti-Tool Queries
The LLM can chain multiple tools together automatically:
Find all small business contractors in NAICS 541330 (engineering
services) in Texas, then get their spending history for 2023,
and identify the top 5 by total contract valueSearch for HVAC maintenance opportunities posted this month,
then analyze historical spending patterns for those agencies
to identify the most active buyersAPI Documentation
Tool Reference
For complete API documentation including all parameters, schemas, and examples, see the full tool descriptions:
USASpending.gov Tools (No API key required)
get_usaspending_awards - Get federal awards data for specific agencies
get_usaspending_spending_by_category - Spending breakdowns by category
get_usaspending_budgetary_resources - Budget/obligation information
search_usaspending_awards_by_recipient - Find awards by recipient name
SAM.gov Tools (Requires SAM_GOV_API_KEY)
search_sam_entities - Search for registered federal contractors
get_sam_opportunities - Find contract opportunities
get_sam_entity_details - Get comprehensive entity profiles
check_sam_exclusions - Verify contractor eligibility status
Join Tools (Requires SAM_GOV_API_KEY)
get_entity_and_awards - Combine SAM entity with USASpending history
get_opportunity_spending_context - Link opportunities with spending data
Tango API Tools (Requires TANGO_API_KEY)
search_tango_contracts - Search federal contracts (unified API)
search_tango_grants - Search federal grants
get_tango_vendor_profile - Get vendor profiles with full history
search_tango_opportunities - Search opportunities with forecasts
get_tango_spending_summary - Get spending analytics
search_tango_protests - Search GAO bid protests with outcome filters
get_tango_protest - Get a single protest's full record
search_tango_idvs - Search IDIQs / BPAs / FSS vehicles that issue task orders
get_tango_idv_children - Drill into one IDV's child IDVs, task orders, and transactions
search_tango_vehicles - Search the federal contract-vehicle catalog (GWACs, MAS, BPAs)
search_tango_otas - Search Other Transaction Authority (OTA) awards
get_tango_entity_metrics - Time-series obligations for one UEI
Rate Limits
This server implements automatic rate limiting to respect API quotas:
API | Delay Between Requests | Daily Limit | Notes |
USASpending.gov | 3.6 seconds | ~1000 requests/hour | Public API |
SAM.gov | 100ms | Varies by key | Check SAM.gov dashboard |
Tango | 100ms | Varies by plan | Check Tango dashboard |
Error Handling
All tools return structured error responses:
{
"error": "Error message description",
"details": "Additional context if available"
}Common error types:
Authentication errors: Invalid or missing API key
Rate limit errors: Too many requests
Validation errors: Invalid parameters
Not found errors: Resource doesn't exist
Server errors: API temporarily unavailable
Deploying to Railway
The server runs in HTTP mode (StreamableHTTP transport) when MCP_TRANSPORT=http. Railway is the simplest host.
Create a new Railway service from this repo (Nixpacks auto-detects Node).
Set environment variables in the Railway dashboard:
MCP_TRANSPORT=http(required — switches from stdio)NODE_ENV=productionNPM_CONFIG_PRODUCTION=false(required sonpm ciinstalls devDependencies; the build step needstsc)MCP_REQUIRE_OAUTH=true(enables the per-user authorization flow for Claude remote-connector users)MCP_PUBLIC_BASE_URL=https://<your-domain>(for example,https://capture.mcp.blencorp.com)OAUTH_TOKEN_SECRET=<random secret>(protects encrypted per-user provider credentials — generate withopenssl rand -base64 48)SAM_GOV_API_KEY,TANGO_API_KEY, and/orHIGHERGOV_API_KEYonly if you want server-wide access to those tools as a fallback. Usually unset for shared deployments; each user supplies their own keys during OAuth authorization.Do not set
PORT— Railway injects it.
Deploy. Nixpacks installs dependencies,
railway.tomlrunsnpm run build, and the service starts vianode dist/server.js, with healthcheck onGET /health.Add a custom domain in Settings → Domains (e.g.
capture.mcp.blencorp.com) and point a CNAME at the value Railway shows.
CI deploys via GitHub Actions
.github/workflows/deploy-railway.yml deploys to Railway on every push to main (and is also runnable manually from the Actions tab). One-time setup:
In Railway, generate a project token: Account → Tokens → Create New Token (or
railway login --browserlessfrom a workstation). Copy the token value.In GitHub, add it as a repo secret: Settings → Secrets and variables → Actions → New repository secret named
RAILWAY_TOKEN.If Railway's built-in GitHub integration is also enabled (Service → Settings → Source), disable auto-deploys there to avoid two parallel builds racing on every push. The Action becomes the single source of truth.
The workflow installs the Railway CLI, runs railway up --service capture-mcp-server --ci, and then polls /health for up to 5 minutes to confirm the new build is serving traffic.
Auth posture
The hosted server accepts two parallel auth modes when MCP_REQUIRE_OAUTH=true:
1. OAuth (for Claude and other interactive MCP clients). POST /mcp requires a bearer token and advertises protected-resource metadata. The client redirects the user to /oauth/authorize, where the user picks which providers they have keys for (SAM.gov, Tango, HigherGov) via checkboxes and pastes the keys for those providers. The server seals all selected keys into one access token; only tools whose keys were authorized appear in the client's tool list. Keys are never exposed as tool arguments.
2. Header passthrough (for programmatic API callers). Requests that include X-Sam-Api-Key, X-Tango-Api-Key, and/or X-Highergov-Api-Key headers bypass the bearer-token gate. Only the tools whose keys are present get registered for that request. The provider key itself is the trust anchor — same model as the OAuth flow, just without the browser dance.
If MCP_REQUIRE_OAUTH is not set, HTTP mode runs unauthenticated: public USASpending tools are visible without any credential, and keyed tools light up from server env vars or request headers.
Smoke test after deploy
curl -sf https://<your-domain>/health
# 1) Unauthenticated MCP requests return 401 with a WWW-Authenticate header
# pointing to OAuth protected-resource metadata.
curl -i https://<your-domain>/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# 2) Header passthrough — list HigherGov tools without going through OAuth.
curl -X POST https://<your-domain>/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H "X-Highergov-Api-Key: $HIGHERGOV_API_KEY" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# 3) Header passthrough — call a tool directly.
curl -X POST https://<your-domain>/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H "X-Highergov-Api-Key: $HIGHERGOV_API_KEY" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search_highergov_forecasts","arguments":{"keyword":"cyber"}}}'After a Claude user completes OAuth authorization, tools/list returns the USASpending tools plus the provider tools enabled by that user's keys.
Development
Development Setup
# Install dependencies
npm install
# Development mode with auto-reload (uses ts-node)
npm run dev
# Build TypeScript to JavaScript
npm run build
# Run the built server
npm startdist/ contains the compiled JavaScript output and is generated by the build step. It is intentionally gitignored—delete it before committing or packaging (rm -rf dist or rebuild) to keep the repository clean.
Building Desktop Extensions
# Build .dxt (lightweight - no node_modules, for dev/testing)
npm run package:dxt
# Build .mcpb (full bundle - includes node_modules, for distribution)
npm run packageFile sizes:
.dxt: ~19KB (just code and manifest).mcpb: ~4.2MB (includes all dependencies)
Testing Tools
# Test with MCP Inspector
npm install -g @modelcontextprotocol/inspector
npx @modelcontextprotocol/inspector node dist/server.jsProject Structure
capture-mcp-server/
├── src/
│ ├── server.ts # MCP server entry point
│ ├── tools/
│ │ ├── index.ts # Tool registry (conditional loading)
│ │ ├── sam-tools.ts # SAM.gov integration (4 tools)
│ │ ├── usaspending-tools.ts # USASpending integration (4 tools)
│ │ ├── tango-tools.ts # Tango API integration (12 tools)
│ │ └── join-tools.ts # Cross-API tools (2 tools)
│ └── utils/
│ └── api-client.ts # HTTP client with rate limiting
├── dist/ # Compiled JavaScript (generated, gitignored)
├── manifest.json # Desktop Extension metadata
├── icon.png # Extension icon
├── package.json
└── tsconfig.jsonArchitecture
Server Core (src/server.ts):
Uses
@modelcontextprotocol/sdkfor MCP protocolStdio transport for desktop integration
Centralized tool registration and routing
Tool Registry (src/tools/index.ts):
Dynamically loads tool sets based on available API keys
Enables graceful degradation when keys are missing
Provides 7-34 tools depending on configuration
API Client (src/utils/api-client.ts):
Centralized HTTP client with rate limiting
Input sanitization and validation
Consistent error handling across all APIs
Supports GET and POST with timeouts
Contributing
Contributions are welcome! Please follow these steps:
Fork the repository
Create a feature branch:
git checkout -b feature/my-featureMake your changes
Test thoroughly with MCP Inspector
Update documentation if needed
Submit a pull request
Development guidelines:
Follow existing code style (TypeScript, ES modules)
Add JSDoc comments for new functions
Test all tools with Inspector before submitting
Update README for new features
Keep dependencies minimal
License
This project is open source under the MIT License.
Copyright (c) 2024 BLEN, Inc.
See LICENSE file for full license text.
Support
Get Help
Issues: https://github.com/blencorp/capture-mcp-server/issues
Discussions: https://github.com/blencorp/capture-mcp-server/discussions
Email: Contact via https://www.blencorp.com
Useful Resources
MCP Documentation: https://modelcontextprotocol.io/
Claude Desktop: https://claude.ai/download
SAM.gov API: https://open.gsa.gov/api/entity-api/
USASpending.gov API: https://api.usaspending.gov/
Tango API: https://tango.makegov.com/docs/
Built with ❤️ by BLEN, Inc.
About BLEN
BLEN, Inc is a digital services company that provides Emerging Technology (ML/AI, RPA), Digital Modernization (Legacy to Cloud), and Human-Centered Web/Mobile Design and Development.
Happy hunting! 🎯
Available Tools
7 toolsaggregate_contractsA
Aggregate federal contract awards from USASpending without pulling rows: group by awarding_agency, awarding_subagency, recipient, naics, psc, month, or set_aside, with metric 'obligations' (dollars) or 'count' (prime awards). This is the tool for questions like 'how many 8(a) sole source awards per agency in Aug-Sep 2025'. Counts state their unit and the date filter states its date_type. group_by=set_aside issues one upstream query per code (~4s each due to rate pacing); metric 'count' is supported for group_by set_aside only (USASpending exposes counts per filter, not per category).
| Name | Required | Description | Default |
|---|---|---|---|
| psc | No | PSC codes | |
| limit | No | Max groups to return for category group_bys (default 25, max 100) | |
| naics | No | NAICS codes | |
| agency | No | Awarding toptier agency NAME as USASpending knows it (e.g. 'Department of Veterans Affairs') | |
| metric | No | 'obligations' (default; aggregated dollars) or 'count' (prime award count; only with group_by=set_aside) | |
| date_to | Yes | End date YYYY-MM-DD (required) | |
| group_by | Yes | One of: awarding_agency, awarding_subagency, recipient, naics, psc, month, set_aside | |
| date_from | Yes | Start date YYYY-MM-DD (required) | |
| date_type | No | Which award date the window filters on: 'action_date' (default), 'date_signed', or 'new_awards_only'. Different choices produce materially different totals — the response echoes this as date_field. | |
| set_aside | No | FPDS set-aside code(s), validated (e.g. ['8AN','SDVOSBS']). Required when group_by=set_aside. | |
| sub_agency | No | Awarding subtier agency name (requires agency) | |
| award_type_codes | No | Award type codes (default ['A','B','C','D'] = contract prime awards; see lookup_reference_code domain award_type) | |
| recipient_search | No | Recipient name or UEI text filter |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full behavioral-disclosure burden. It exceeds that burden by disclosing upstream rate/performance implications ('one upstream query per code, ~4s each'), the date_type echo behavior, and the restrictions on metric 'count'. These are behavior traits an agent cannot infer from the schema alone.
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 front-loads the core behavior, then gives a concrete example, then notes key behavioral caveats. Every sentence earns its place, and there is no filler, fluff, or duplicated schema content.
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 13-parameter tool with no annotations and no output schema, this description is quite complete: it explains when to use it, what the aggregation semantics are, and what performance/rate implications to expect. It could still be improved by explicitly describing the response/result shape, which the current description only partly implies.
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 baseline is 3. The description adds real semantic depth above the schema by explaining why group_by=set_aside has unique cost behavior, why count is only supported there, and that counts state their unit. It doesn't repeat every parameter, but it gives the context that makes parameters more usable.
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 opening sentence names the action ('Aggregate federal contract award...') and the resource (USASpending), and explicitly distinguishes this tool from row-returning tools with 'without pulling rows'. It also enumerates the supported group_by dimensions and metrics, making the tool's scope 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 explicitly says 'This is the tool for questions like...' and gives a concrete query shape, which tells the agent exactly when to select it. It also clearly communicates the boundary for when not to use it: 'without pulling rows', which contrasts with the row-returning siblings, and restricts metric=count to set_aside group_bys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_award_detailA
Get the full FPDS record for a single procurement award from USASpending — the verification primitive: type_set_aside with description, extent_competed, number_of_offers_received, other_than_full_and_open competition authority, and current vs ultimate completion dates. Use it to confirm that a filtered search actually returned what it claimed before a number goes in a memo. Accepts a procurement generated award ID (CONT_AWD_... or CONT_IDV_...) or a bare PIID (resolved via award search first). Assistance IDs (ASST_...) are rejected because they do not carry FPDS competition fields.
| Name | Required | Description | Default |
|---|---|---|---|
| award_id | Yes | USASpending procurement generated_unique_award_id (e.g. 'CONT_AWD_36C10B26F0223_3600_47QRCA24DV006_4732') or a bare PIID (e.g. '36C10B26F0223') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses concrete behaviors: acceptable ID formats (CONT_AWD_, CONT_IDV_, bare PIID), resolution of bare PIIDs via award search, and rejection of ASST_ IDs with rationale. It also names the specific FPDS competition fields returned, giving agents a clear expectation of the response.
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 dense sentences front-load the purpose, then usage, then constraints; no filler or repetition of schema content. The ID examples are embedded in the schema example, and the description complements rather than repeats.
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 one-parameter tool with no output schema, it specifies the main returned fields, accepted/rejected input forms, and the intended verification workflow. It doesn't describe an output format, but the enumerated fields and ID handling make it sufficient for an agent to call and interpret results.
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 documents award_id with examples, so baseline is 3. The description adds meaning by explaining the two accepted ID forms and which IDs are rejected, going beyond the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single procurement award's full FPDS record from USASpending and enumerates the verification-specific fields it contains. The phrase 'verification primitive' plus field list distinguishes it from search and aggregation sibling 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?
It explicitly tells agents to use this tool to confirm a filtered search result before relying on a number, and it states when not to use it by rejecting ASST_ IDs. It doesn't name sibling tools explicitly, but the search-confirmation context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usaspending_awardsB
Get federal awards data for a specific agency and fiscal year. Returns award counts, obligations, and top awards.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of top awards to return (default: 10) | |
| agency_code | Yes | 3-digit agency code (e.g., '075' for HHS, '097' for DOD) | |
| fiscal_year | No | Fiscal year (e.g., 2024) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds value by specifying the return contents (award counts, obligations, top awards), which goes beyond a generic 'get data'. However, it omits details such as default limit handling, behavior when fiscal_year is omitted, or any potential limitations, leaving some ambiguity.
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 purpose and followed by the key outputs. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only three scalar parameters and no output schema, the description covers the core purpose and returns. However, it does not explain what happens if optional parameters like fiscal_year or limit are omitted, nor does it describe the structure of the returned awards data beyond a high-level list. There is no guidance on edge cases or integration with sibling tools.
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 has 100% description coverage for all three parameters, so the baseline is 3. The description does not add new meaning beyond what the schema already provides; it merely restates the agency and fiscal year context. No extra clarification on defaults or parameter interactions is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves federal awards data for a specific agency and fiscal year, with a verb ('Get') and resource ('federal awards data'). It lists the main outputs, but does not explicitly differentiate from sibling tools like spending_by_category or search by recipient, so it stops short of a 5.
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 agency-level awards data but provides no explicit guidance on when to choose it over the sibling tools (e.g., spending_by_category, budgetary_resources). No alternatives or exclusions are mentioned, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usaspending_budgetary_resourcesA
Get budgetary resources and obligations for an agency in a fiscal year.
| Name | Required | Description | Default |
|---|---|---|---|
| agency_code | Yes | 3-digit agency code (e.g., '075' for HHS) | |
| fiscal_year | No | Fiscal year (e.g., 2024) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation ('Get') but does not disclose output format, whether it returns aggregate or detailed records, data source specifics, or any access limitations. This leaves significant behavioral ambiguity.
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 concise sentence, front-loaded with the verb and resource. It is efficient with no wasted words and immediately conveys the tool's purpose.
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 low parameter count and no output schema, the description covers the essential intent but omits any details about the return structure or typical usage context. It is minimally sufficient but not enriched with additional contextual guidance that would help an agent select it confidently over siblings.
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 both parameters have clear descriptions with examples. The tool description does not add any extra meaning beyond the schema, so the baseline score of 3 applies. It neither clarifies parameter relationships nor provides additional format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('budgetary resources and obligations') and the scope ('for an agency in a fiscal year'). It is distinct from sibling tools like get_usaspending_awards and get_usaspending_spending_by_category, which focus on different aspects of spending data.
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 clearly implies this tool is for retrieving agency-level budget/obligation data for a given fiscal year, which differentiates it from the award- and category-focused sibling tools. However, it does not explicitly state when not to use it or name alternatives, falling short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usaspending_spending_by_categoryB
Get spending breakdown by award category (contracts, grants, loans, etc.) for an agency and fiscal year.
| Name | Required | Description | Default |
|---|---|---|---|
| agency_code | Yes | 3-digit agency code (e.g., '075' for HHS) | |
| fiscal_year | No | Fiscal year (e.g., 2024) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core function and omits important details such as whether the response is a list of categories with totals, whether fiscal_year is required despite being optional in the schema, and any limitations on which award categories are included. No return format or aggregation behavior is described.
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 concise sentence that directly states the tool's purpose. No unnecessary words or repetition, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the returned spending breakdown looks like (e.g., category names and totals). It does not, nor does it clarify the optionality of fiscal_year. The tool is simple, but the description leaves significant gaps for an agent attempting to invoke it correctly without additional context.
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% for both parameters, so the schema already explains agency_code and fiscal_year. The description adds context by mentioning 'for an agency and fiscal year' but does not clarify that fiscal_year is optional, which could confuse an agent. Since the schema is strong, a 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 a specific verb and resource: 'Get spending breakdown by award category' for an agency and fiscal year. It distinguishes itself from sibling tools like get_usaspending_awards (which likely lists individual awards) and get_usaspending_budgetary_resources (budget-level data) by focusing on category aggregation.
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 used when you need spending totals per category for an agency and fiscal year, but it provides no explicit guidance on when to use this tool versus alternatives like get_usaspending_awards or search_usaspending_awards_by_recipient. There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_reference_codeA
Look up the official FPDS description for a procurement reference code, or list a whole domain. Domains: set_aside, extent_competed, award_type, solicitation_procedure, competition. Use this BEFORE filtering or reporting on any code — e.g. set_aside 8A is '8(a) Competed' while 8AN is '8(a) Sole Source'. Static lookup: no API key, no network.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | The code to look up (e.g. '8AN'). Omit to list every code in the domain. | |
| domain | Yes | Code domain: one of set_aside, extent_competed, award_type, solicitation_procedure, competition |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses that this is a static lookup, requires no network and no API key. This is meaningful behavioral information, but it does not mention error handling or behavior for invalid/unknown codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded purpose, then domains, then a pragmatic usage directive. There is no filler and every 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?
For a simple, static lookup tool with no output schema, the description adequately covers what the tool does, the accepted domains, typical usage timing, and its local nature. The main omission is not describing the exact return format; however, the output scope feels obvious and the description still is 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 covers 100% of parameters, so the baseline is 3. The description adds semantic value by contrasting 8A ('8(a) Competed') with 8AN ('8(a) Sole Source'), which helps the agent understand the meaning of the lookup before filtering or reporting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (look up / list) with a clear resource (official FPDS descriptions for procurement reference codes) and enumerates the five accepted domains. It differentiates well from the sibling USASpending data-query tools, which are named around 'get'/'search' rather than local code lookup.
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 tells agents to use this tool before filtering or reporting on codes, and provides a concrete 8A vs 8AN example to illustrate why. It does not explicitly name sibling tools as alternatives or state when not to use it, so it falls just short of the highest benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_usaspending_awards_by_recipientB
Search for federal awards by recipient name, with optional filters for time period and amount ranges. Great for investigating specific companies or organizations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (default: 10, max: 100) | |
| cursor | No | Page number from the prior response's next_cursor. Reuse the same filters and limit when paging. | |
| max_amount | No | Maximum award amount filter | |
| min_amount | No | Minimum award amount filter | |
| award_types | No | Award type codes from one USASpending group only (default ['A','B','C','D'] for contract prime awards). Search contracts, IDVs, grants, loans, and other assistance groups separately. | |
| fiscal_year | No | Fiscal year to search by award action date (e.g., 2024) | |
| recipient_name | Yes | Name of recipient to search (e.g., 'Boeing', 'Johns Hopkins') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Search for federal awards,' which implies a read operation, but it does not disclose meaningful behavior such as cursor-based pagination, the one-group restriction on award_types, the default limit, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no wasted words. The use-case sentence earns its place by helping with tool selection.
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 7-parameter tool with no output schema and no annotations, the description is adequate but incomplete. It does not explain pagination, award-type grouping constraints, or how this search relates to sibling tools, although the rich schema descriptions compensate for some of the 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?
The input schema has 100% coverage, so the baseline is 3. The description adds only a high-level mapping of 'time period and amount ranges' to filters, which provides marginal value but does not go beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: searching federal awards by recipient name, and it names the key filters (time period and amount ranges). It is clear, but it does not explicitly distinguish itself from sibling tools like get_usaspending_awards or get_award_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Great for investigating specific companies or organizations' gives an implied use case but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. Sibling tools exist but are never referenced or differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.2- Changed
get_award_detail1 field changed- changed
Input schema / properties / award_id / descriptionPrevious value: -"USASpending generated_unique_award_id (e.g. 'CONT_AWD_36C10B21D0042_3600_-NONE-_-NONE-') or a bare PIID (e.g. '36C10B21D0042')"New value: +"USASpending procurement generated_unique_award_id (e.g. 'CONT_AWD_36C10B26F0223_3600_47QRCA24DV006_4732') or a bare PIID (e.g. '36C10B26F0223')"
- Changed
search_usaspending_awards_by_recipient3 fields changed- changed
Input schema / properties / award_types / descriptionPrevious value: -"Award type codes to filter (e.g., ['10'] for contracts)"New value: +"Award type codes from one USASpending group only (default ['A','B','C','D'] for contract prime awards). Search contracts, IDVs, grants, loans, and other assistance groups separately." - added
Input schema / properties / cursorAdded value: +{ + "description": "Page number from the prior response's next_cursor. Reuse the same filters and limit when paging.", + "type": "string" +} - changed
Input schema / properties / fiscal_year / descriptionPrevious value: -"Fiscal year to search (e.g., 2024)"New value: +"Fiscal year to search by award action date (e.g., 2024)"
3 tool updates
v1.0.1- Added
aggregate_contracts - Added
get_award_detail - Added
lookup_reference_code
4 tool updates
v1.0.0- First observed
get_usaspending_awards - First observed
get_usaspending_budgetary_resources - First observed
get_usaspending_spending_by_category - First observed
search_usaspending_awards_by_recipient
TDQS
Most tools map to clearly different operations—reference lookup, recipient search, award detail, aggregation, and budget summaries. However, get_usaspending_awards, get_usaspending_spending_by_category, and get_usaspending_budgetary_resources are similarly named summary endpoints, and get_usaspending_awards overlaps somewhat with aggregate_contracts in producing counts and obligations.
All names are snake_case and action-oriented, so the general pattern is readable. There is a minor inconsistency: get_usaspending_* and search_usaspending_* use a domain prefix, while get_award_detail, aggregate_contracts, and lookup_reference_code omit it.
Seven tools is a well-scoped size for this server's purpose. Each tool addresses a distinct querying, lookup, or aggregation need without padding or unnecessary duplication.
The server covers award summaries, spending categories, budgetary resources, recipient search, award detail verification, reference code lookups, and flexible contract aggregation. Minor gaps include no assistance-award detail endpoint and no general award search by arbitrary fields, but the core workflows are well supported.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
SAM.gov contract opportunities and entity lookup (BYOK) plus USASpending federal award data.
Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
Access US federal award, recipient, agency, and spending analytics data from USAspending.gov.
Search US grants + federal contracts (Grants.gov + SAM.gov) from any LLM.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables research of federal contract awards and competitive landscape analysis using the USASpending.gov API. Supports searching for contracts, analyzing recipients, tracking spending trends, and identifying market opportunities in government contracting.2MIT
- AlicenseNot gradedqualityDmaintenanceEnables research of federal contract awards, market opportunities, and competitive landscapes using the USASpending.gov API. It provides specialized tools for AI agents to analyze government spending trends, identify incumbents, and search contractor details.MIT
- AlicenseAqualityBmaintenanceSearch and analyze U.S. federal government contracts and opportunities from SAM.gov. Tools for keyword search, contract details, competitive analysis, and capability statement drafting — built for AI agents via x402 USDC micropayments.32MIT
- AlicenseNot gradedqualityFmaintenanceEnables AI agents to search and analyze federal government contract opportunities and awards from SAM.gov and USASpending.gov, with tools for contract search, detail, agency spending, and trending sectors.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/blencorp/capture-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server