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., "@Government Contract Award Monitor MCP Server Monitor US federal contracts over $500k awarded in the last 30 days"
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.
MCP server for the Mamba Labs Government Contract Award Monitor actor on Apify.
Pick a register and a time window. It returns the companies that won public work in that window, one flat row per winning company, with award count, total value, awarding body, award date, and a resolved company domain.
npx -y @mambalabsdev/mcp-public-award-monitor{
"mcpServers": {
"mamba-public-award-monitor": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-public-award-monitor"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}Get an Apify token at console.apify.com/account/integrations.
Related MCP server: EzBiz Government Contracting MCP Server
monitor_public_awardsRegister and window in, the companies that won public work out.
Input | Type | Required | Notes |
| enum | yes | Which award register to read. |
| string | no | How many days back from today to read awards for, 1 to 90. US federal data lags about two days, so do not use a one day window on the US registers. Default |
| string | no | Drops awards below this amount in the register's own currency. Set to 0 to keep everything. Default |
| string | no | Hard cap on billed rows, 1 to 1000. Winners are sorted by total award value, and the run log says how many were dropped. Default |
| boolean | no | Drops winners that are themselves government, universities, or public authorities. Leave this on for the grant registers or you get state departments of education instead of companies. Default |
| boolean | no | Looks up each winner's website. Turning it off makes the run roughly 20x faster and returns |
| enum | no |
|
One row per winning company, not one per award. total_award_value, largest_award_value and award_count_in_window size the opportunity. recipient_register_id is the UEI in the US and the Companies House number in the UK, which is what you match against a CRM. latest_award_url is the deep link to the source record.
You are charged per winning company returned, plus a small actor start fee. max_entities is therefore a hard cost cap.
Pricing is on the actor's Apify page. Running this server consumes Apify credits.
It is a thin client for the Apify actor. It passes your input through and returns the actor's output unchanged. Every behavior described above lives in the actor, not here.
This is not a tender feed and not a procurement pipeline tool. It does not tell you what is open to bid on. It reports awards that have already been made and names the company that won.
Errors are surfaced, never swallowed. An invalid input, an invalid token, an exhausted balance, a timeout, or a run that returns anything other than a dataset all come back as an explicit tool error rather than as an empty result.
The actor is on the Apify Store. This wrapper is MIT licensed.
Built by Mamba Labs
Pick a public award register and a time window and it returns the companies that won public work in it, one flat row per winning company rather than one per award, with award count, total value, largest award, awarding body, award date, a deep link to the source record, and a resolved company domain. Five registers are covered: US federal contracts and US federal grants from USASpending, NIH SBIR and STTR from NIH RePORTER, and UK Contracts Finder and UK Find a Tender. This reports awards that have already been made, so it is not a tender feed and will not tell you what is open to bid on. US federal data lags about two days, so a one day window on a US register returns little or nothing. Winners are sorted by total award value and max_entities is the hard cap on billed rows. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| register | Yes | Which award register to read. US federal contracts and grants come from USASpending, NIH SBIR and STTR from NIH RePORTER, and the two UK registers from Contracts Finder and Find a Tender. Default: "us_federal_contracts". | |
| window_days | No | How many days back from today to read awards for. 1 to 90. US federal data lags about two days, so do not use a one day window on the US registers. Sent as a string so it works from Clay. Default: "7". | |
| max_entities | No | Hard cap on billed rows. 1 to 1000. Winners are sorted by total award value, and the run log says how many were dropped. Sent as a string so it works from Clay. Default: "100". | |
| min_award_value | No | Drops awards below this amount in the register's own currency. Set to 0 to keep everything. Sent as a string so it works from Clay. Default: "100000". | |
| resolve_domains | No | Looks up each winner's website. Turning it off makes the run roughly 20x faster and returns recipient_domain as null with domain_status not_attempted. Default: true. | |
| domain_confidence_floor | No | How sure the actor has to be before it gives you a domain. Strict returns fewer domains and almost no wrong ones. Loose returns the most domains and about a third of them are wrong. Default: "standard". | |
| exclude_government_recipients | No | Drops winners that are themselves government, universities, or public authorities. Leave this on for the grant registers or you get state departments of education instead of companies. Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond those: row flattening semantics, sorting by total award value, max_entities as a hard billing cap, data lag behavior, and domain resolution effects on speed. This significantly helps an agent predict side effects and limits.
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 dense paragraph but every sentence carries useful information: output shape, register coverage, non-tender caveat, data lag, sorting/cap, auth, and read-only nature. It is front-loaded with the core behavior and then covers operational nuances. Slightly long but not wasteful; a 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema), the description is impressively complete. It explains the return row structure, register sources, data freshness, sorting, row limits, auth/credits, and domain resolution behavior. No major context is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds extra semantic value by clarifying that max_entities is a billed-row hard cap, that resolve_domains speeds up runs ~20x, and that exclude_government_recipients is important for grant registers. These insights go beyond the schema descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it picks a public award register and time window and returns winning companies as flat rows. It lists the covered registers explicitly, which fully disambiguates the tool's scope. It also distinguishes from a tender feed, clarifying it reports already-made awards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance, including that it is not a tender feed and will not show open bids. It provides practical timing advice (US data lags ~2 days, so avoid one-day windows) and warns about Apify credit consumption. It also notes the need for APIFY_TOKEN, which is essential operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0monitor_public_awardsOnly one tool exists, so there is no overlap or ambiguity between tool purposes.
The tool name 'monitor_public_awards' uses a clear verb-noun pattern that accurately describes its function.
A single tool is minimal, but the tool itself aggregates multiple award registers, making it a self-contained utility. Still, one tool feels thin for a server.
The tool fully covers the monitoring of public awards across multiple registers, providing award counts, values, dates, and source links. No obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Alerts on official data: US and EU tenders, federal awards and grants, permits, MAP violations.
Track US federal contract changes: what changed, deltas, competitor award watch, award search.
Federal contract exposure for listed companies, with subsidiary-to-issuer resolution.
Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-public-award-monitor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server