govrider-mcp-server
The GovRider MCP Server helps tech companies and consultants match their products or services against live government procurement opportunities (tenders, RFPs, grants, SBIR/STTR, frameworks) from 25+ official sources worldwide.
Free discovery search (
search_opportunities): Find up to 10 matching opportunities by describing your technology, product, or service. Filter by region (EU, US Federal, UK, Latin America, Asia Pacific, Africa), country, or funding type. Returns sector, region, funding type, estimated value, deadline, and status.AI-powered enriched search (
search_enriched, costs 1 credit): High-precision matching with AI match scores (0–100), strategic fit memos, political context analyses, translated titles, full descriptions, direct application URLs, agency details, keywords, deadlines, and estimated values.Check credit balance (
check_credits): View your GovRider credit balance and database status for free at any time.Live data: Opportunities are nightly-updated from 25+ official government portals, ensuring only open, active results are returned.
What is GovRider?
GovRider is for any tech company, consultancy, or individual with a technology product or service. You don't need to be a government specialist. If you build or sell technology, there are governments looking to buy it.
Thousands of live opportunities from 25+ official government portals and international organisations
Covers the US, EU, UK, Latin America, Africa, and Asia Pacific
Updated nightly - only live, open opportunities are returned
AI-enriched - every opportunity is verified, analysed, and semantically indexed
Describe what you sell or what you are building and get ranked matches in seconds
Related MCP server: LexSocket MCP Server
Quick Start
1. Get an API key
Sign up at govrider.ai and create an API key at govrider.ai/app/api-keys.
2. Install
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"govrider": {
"command": "npx",
"args": ["-y", "@govrider/mcp-server"],
"env": {
"GOVRIDER_API_KEY": "gr_live_your_key_here"
}
}
}
}Restart Claude Desktop after saving.
Add to .claude/settings.json in your project or ~/.claude/settings.json globally:
{
"mcpServers": {
"govrider": {
"command": "npx",
"args": ["-y", "@govrider/mcp-server"],
"env": {
"GOVRIDER_API_KEY": "gr_live_your_key_here"
}
}
}
}Add to your workspace .vscode/mcp.json:
{
"servers": {
"govrider": {
"command": "npx",
"args": ["-y", "@govrider/mcp-server"],
"env": {
"GOVRIDER_API_KEY": "gr_live_your_key_here"
}
}
}
}Tools
search_opportunities (FREE)
Discovery search across all sources. No credits required.
Parameter | Type | Required | Description |
| string | Yes | Description of your technology, product, or service (min 10 chars) |
| string | No | Filter: "EU", "US Federal", "UK", "Latin America", "Asia Pacific", "Africa" |
| string | No | Filter: "France", "Colombia", "Australia", etc. |
| string | No | Filter: "Tender", "Grant", "RFP", "SBIR/STTR", "Framework" |
| number | No | Results to return, 1-10 (default 10) |
Returns for each match:
Sector category
Region
Funding type
Estimated value
Deadline
Status
search_enriched (1 credit)
High precision matching via GovRider's proprietary AI architecture.
Parameter | Type | Required | Description |
| string | Yes | Detailed description of your technology, product, or service (min 20 chars). More detail = better matches. |
| string | No | Filter: "EU", "US Federal", "UK", "Latin America", "Asia Pacific", "Africa" |
| string | No | Filter: "France", "Colombia", "Australia", etc. |
| string | No | Filter: "Tender", "Grant", "RFP", "SBIR/STTR", "Framework" |
Returns for each match (10 results):
Match score (0-100)
GovRider's strategic fit memo assessing your tech solution or consulting offer suitability
GovRider's political context analysis of opportunities identified
Translated English title
Full description
Agency and country
Direct application URL
Document URLs
Keywords
Deadline and estimated value
check_credits
Check your GovRider credit balance and database status. No parameters required.
Configuration
Environment Variable | Required | Description |
| Yes | Your GovRider API key. Get one at govrider.ai/app/api-keys |
| No | Override API base URL (default: |
Examples
GovRider works by matching what you sell or build against live government opportunities. Describe your product or service, and GovRider finds where the demand is.
Tech product
"We build a cloud-based ERP platform for finance teams. Key modules include budget forecasting, procurement workflow automation, and real-time spend analytics. We integrate with SAP and any cloud provider via API."
Tech consulting
"Our firm provides cybersecurity advisory and implementation services: penetration testing, SOC setup, zero-trust architecture design, and GDPR/NIS2 compliance audits. We specialise in critical infrastructure and defence clients."
Coverage
Data from 25+ official government portals and international organisations
Regions: US, EU, UK, Latin America, Africa, Asia Pacific
All data is refreshed nightly
Only live, open opportunities are returned
Pricing
Tool | Cost |
| Free |
| 1 credit |
| Free |
Buy credits at govrider.ai/pricing.
Security
API keys are transmitted over HTTPS only
Keys are never stored in plaintext on GovRider's servers (SHA-256 hashed)
Rate limit: 60 requests per minute per API key
Report security issues to contact@govrider.ai
Development
# Clone
git clone https://github.com/carlosahumada89/govrider-mcp-server.git
cd govrider-mcp-server
# Install dependencies
npm install
# Build
npm run build
# Run locally
GOVRIDER_API_KEY=gr_live_... node build/index.jsLicense
MIT - see LICENSE.
Available Tools
4 toolscheck_creditsA
Check your GovRider credit balance. Each enriched search costs 1 credit. Discovery search and opportunity details are free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. Describes a read-only operation but does not disclose if authentication is needed, real-time nature, or potential side effects. Adequate but incomplete.
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 concise sentences, front-loaded with the core action being 'check your credit balance'. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters, but lacks output description. Given no output schema, description could mention what the balance return looks like (e.g., integer, message). Somewhat incomplete.
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?
No parameters exist (100% schema coverage), so baseline is 4. Description adds no parameter info, which is appropriate as there are none.
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 purpose as checking credit balance, with specific verb 'check' and resource 'credit balance'. It distinguishes from sibling tools which are search/get operations.
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 clear context about when credits are used (enriched searches) and that other actions are free, implying the tool should be used to check balance before enriched searches. Lacks explicit when-not-to-use but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_opportunityA
Get full details for a specific opportunity from the last enriched search. Returns the strategic fit memo, political context memo, full description, application URL, agency, keywords, and status. FREE - no extra credit cost. You must run search_enriched first.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The result number from the enriched search (1-10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses cost behavior but does not explicitly address idempotency, side effects, or error conditions. As a simple get, it is minimally adequate.
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 concise sentences: purpose, returns, and prerequisite/cost. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists all return fields (strategic fit memo, etc.) and states the data source (last enriched search). This provides sufficient context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema already describes the number parameter. The description adds no new detail beyond the schema, earning the 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 action ('Get full details for a specific opportunity') and the resource ('from the last enriched search'). It lists return fields, distinguishing it from siblings like search_enriched which performs the search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite ('You must run search_enriched first') and cost ('FREE - no extra credit cost'). However, it doesn't compare to search_opportunities or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_enrichedA
Full AI-powered government procurement search with Claude Sonnet intelligence. Returns a compact ranked summary of 10 matches showing title, match score, region, type, value, and deadline. Costs 1 credit. Always searches globally across all sources to find the best matches. After reviewing the summary, use get_opportunity with a result number (1-10) to see the full strategic fit memo, political context memo, description, and application URL for any match - at no extra cost.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Detailed description of the technology, product, or service (min 20 chars). Include any country, region, or sector context directly in the description. More detail = better matches. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses credit cost (1 credit), global scope, output format (10 matches with specific fields), and AI intelligence used. It lacks details on idempotency or error handling, but for a search tool these are not critical.
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 moderately sized, front-loaded with the tool's purpose, then lists output specifics, cost, scope, and follow-up instructions. Every sentence adds value and is well-structured without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately describes the output format (10 matches, fields). It also explains the next step (get_opportunity) and cost. It does not mention what happens if no matches are found, but overall is sufficiently complete for a search tool with one parameter.
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 single parameter 'query' has full schema description. The tool description adds semantic guidance: 'Include any country, region, or sector context directly in the description. More detail = better matches.' This adds value beyond the schema by advising on detail and context inclusion.
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 is a government procurement search tool that returns a ranked summary of 10 matches with specific fields. It names sibling 'get_opportunity' for follow-up, but does not explicitly distinguish from sibling 'search_opportunities', so it is somewhat clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using get_opportunity after reviewing the summary, but does not provide explicit guidance on when to use this tool versus the alternative 'search_opportunities', nor does it describe any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_opportunitiesA
Search government procurement opportunities worldwide. Returns sector category, region, funding type, estimated value, deadline, and status for up to 10 matches. FREE - no credits required. Always searches globally across all sources. Use this for initial discovery before committing credits to enriched search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Description of the technology, product, or service to match against government opportunities (min 10 chars). Include any country, region, or sector context directly in the description. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses result limit (10 matches), free cost, and global search. Does not explicitly state read-only behavior, but search operation implies no side effects.
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 with no wasted words. Front-loads purpose, then adds key usage guidance and differentiating details.
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?
Single parameter, no output schema, yet description covers what it returns, limits, cost, scope, and relationship to sibling tool. 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?
Schema coverage is 100% with a detailed description. The tool description does not add significant meaning beyond the schema; it reiterates context inclusion advice already in the 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?
Explicitly states it searches government procurement opportunities worldwide, lists returned fields, and distinguishes from sibling tool search_enriched by noting free usage and global search.
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?
Clearly advises use for initial discovery before committing credits to enriched search, implying when to switch to search_enriched. Provides context on free usage and global scope.
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.
3 tool updates
v1.1.3- Added
get_opportunity - Changed
search_enriched4 fields changed- removed
Input schema / properties / countryRemoved value: -{ - "description": "Filter by country (e.g. \"France\", \"Colombia\", \"Australia\")", - "type": "string" -} - removed
Input schema / properties / funding_typeRemoved value: -{ - "description": "Filter by funding type (e.g. \"Tender\", \"Grant\", \"RFP\", \"SBIR/STTR\", \"Framework\")", - "type": "string" -} - changed
Input schema / properties / query / descriptionPrevious value: -"Detailed description of the technology, product, or service (min 20 chars). More detail = better matches."New value: +"Detailed description of the technology, product, or service (min 20 chars). Include any country, region, or sector context directly in the description. More detail = better matches." - removed
Input schema / properties / regionRemoved value: -{ - "description": "Filter by region (e.g. \"EU\", \"US Federal\", \"UK\", \"Latin America\", \"Asia Pacific\", \"Africa\")", - "type": "string" -}
- Changed
search_opportunities5 fields changed- removed
Input schema / properties / countryRemoved value: -{ - "description": "Filter by country (e.g. \"France\", \"Colombia\", \"Australia\")", - "type": "string" -} - removed
Input schema / properties / funding_typeRemoved value: -{ - "description": "Filter by funding type (e.g. \"Tender\", \"Grant\", \"RFP\", \"SBIR/STTR\", \"Framework\")", - "type": "string" -} - removed
Input schema / properties / limitRemoved value: -{ - "description": "Number of results to return (1–10, default 10)", - "maximum": 10, - "minimum": 1, - "type": "number" -} - changed
Input schema / properties / query / descriptionPrevious value: -"Description of the technology, product, or service to match against government opportunities (min 10 chars)"New value: +"Description of the technology, product, or service to match against government opportunities (min 10 chars). Include any country, region, or sector context directly in the description." - removed
Input schema / properties / regionRemoved value: -{ - "description": "Filter by region (e.g. \"EU\", \"US Federal\", \"UK\", \"Latin America\", \"Asia Pacific\", \"Africa\")", - "type": "string" -}
3 tool updates
v1.1.0- First observed
check_credits - First observed
search_enriched - First observed
search_opportunities
TDQS
Each tool targets a distinct step in the procurement search workflow: credit checks, free discovery, paid enriched search, and detailed opportunity viewing. There is no overlap in purpose.
All tool names follow a consistent snake_case verb_noun pattern (check_credits, get_opportunity, search_enriched, search_opportunities), making them predictable and easy to understand.
With four tools, the server covers the essential user journey without unnecessary complexity. Each tool earns its place, and the count is appropriate for the domain.
The tool set provides a complete workflow: free discovery search, enriched search, detailed opportunity retrieval, and credit management. There are no obvious gaps for the stated purpose of government procurement search.
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
Search 200k+ public tenders from Europe and North America (87 official sources, 32 countries).
9.9M+ tenders, RFPs & grants. 60 countries with a national procurement source, 193 with any record.
Government tender search for AI agents. UK, EU and US procurement opportunities.
Search EU public tenders across TED and 8 national portals. Monitor, match, and analyse procurement.
Related MCP Servers
- AlicenseBqualityBmaintenanceProvides AI models with access to Ukrainian government procurement data from Prozorro, enabling search and retrieval of tender information by organization, date range, and other criteria.11211ISC
- AlicenseNot gradedqualityDmaintenanceEnables search and analysis of European public procurement tenders, including EU above-threshold (TED) and below-threshold from 11 national sources, with hybrid search and filtering.MIT

oro-intel-mcpofficial
AlicenseNot gradedqualityBmaintenanceUK public procurement data for AI agents. Tenders, contracts, buyer and supplier profiles over MCP and REST. 250 free credits.MIT- AlicenseNot gradedqualityCmaintenanceFind, analyze, and score Polish public tenders (BZP): parsed requirements, deadlines, certificates, and bid-fit scoring against your company profile.17MIT
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/carlosahumada89/govrider-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server