Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Monitor Public Awards

monitor_public_awards
Idempotent

Find companies that won public contracts or grants by register and time window, with award counts, total value, dates, and resolved domains.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
registerYesWhich 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_daysNoHow 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_entitiesNoHard 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".
max_charge_usdNoOptional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
min_award_valueNoDrops 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_domainsNoLooks 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_floorNoHow 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_recipientsNoDrops 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / max_charge_usd
      Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}
  2. Addedv1.1.1

TDQS

A3.5/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description closes with 'Read only,' but the annotations declare readOnlyHint=false, which asserts the tool is not read-only. That is a direct contradiction of the structured safety signal an agent relies on to decide whether a call is side-effect free. The otherwise useful behavioral detail (APIFY_TOKEN requirement, Apify credit consumption, ~two-day US data lag, sort order, hard row cap) cannot compensate for a contradictory safety claim.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The output shape and register list are front-loaded, and the paragraph packs a lot of decision-relevant facts into roughly 150 words without filler. There is some redundancy, notably the US two-day lag stated here and again in the window_days schema description, and the long single paragraph makes the cost and access constraints easy to skim past.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned columns (award count, total value, largest award, awarding body, award date, deep link, resolved domain) and names all five registers, so an agent knows what comes back. It also covers cost and credential prerequisites, though it does not address pagination, run-log access, or what happens when a window yields nothing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all eight parameters, including the string-typed numerics for Clay compatibility, the enum values, and the max_charge_usd semantics. The description reinforces register coverage and the sorting rationale behind max_entities, but largely restates the schema ('max_entities is the hard cap on billed rows', the two-day lag on window_days), adding little beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause gives a specific verb and resource (returns companies that won public work, given a register and time window) and immediately specifies the grain ('one flat row per winning company rather than one per award'). It also pre-empts confusion with adjacent tool categories by stating it is not a tender feed, which no sibling tool covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states clear conditions for use (pick a register plus a time window) and an explicit when-not ('not a tender feed and will not tell you what is open to bid on'), plus a concrete operational caveat that a one-day window on US registers returns little or nothing. It stops short of naming an alternative tool or route for the tender-feed use case, so the exclusion is stated but not redirected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools