Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Funding and Press Signals

get_funding_press_signals
Idempotent

Scan Google News and PR wires for funding, exec moves, product launches, and acquisitions at a company domain. Returns deduplicated, dated events in JSON for outbound sales triggers.

Instructions

Scan Google News and PR wires for funding rounds, executive moves, product launches, and acquisitions at any company domain. Returns deduplicated, dated events in flat Clay-ready JSON. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
domainYesCompany domain to scan, without https or www, e.g. stripe.com.
company_nameNoOptional company name hint, used when the domain does not match the brand name, e.g. Deel for deel.com.
signal_typesNoReport only these event types. Omit for every type. Narrowing also narrows the search: a funding only run issues one news query instead of four.
lookback_daysNoHow far back to search, in days. Default 365.
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.

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. Changed2 schema fields changedv1.1.1
    • addedInput schema / properties / lookback_days
      Added value: +{
+  "description": "How far back to search, in days. Default 365.",
+  "maximum": 1825,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / signal_types
      Added value: +{
+  "description": "Report only these event types. Omit for every type. Narrowing also narrows the search: a funding only run issues one news query instead of four.",
+  "items": {
+    "enum": [
+      "funding_round",
+      "ipo",
+      "acquisition",
+      "exec_move",
+      "product_launch",
+      "partnership"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
  3. Addedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Adds real context beyond the annotations: it requires an APIFY_TOKEN and consumes Apify credits per call, and it returns deduplicated, dated events in flat Clay-ready JSON. The 'writes nothing' claim sits in mild tension with readOnlyHint=false, though the disclosed per-call credit consumption plausibly accounts for the non-read-only flag.

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

Conciseness5/5

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

Three tight sentences: purpose and sources first, then return format, then behavioral/auth/cost constraints. No filler, and the most decision-relevant information is front-loaded.

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

Completeness5/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 still characterizes the return value (deduplicated, dated, flat Clay-ready JSON), and it discloses the auth requirement and cost model. Nothing needed to invoke this correctly appears to be missing.

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 all five parameters are already documented, including the signal_types narrowing behavior and the max_charge_usd cap. The description echoes the event types and output shape but adds no syntax or format detail the schema lacks, so the baseline 3 applies.

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?

States a specific verb (Scan) and resource (Google News and PR wires) plus the exact event classes retrieved (funding rounds, exec moves, product launches, acquisitions). This clearly separates it from siblings like scan_gtm_hiring_signals or detect_gtm_tech_stack, which cover different signal families.

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

Usage Guidelines3/5

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

Usage is implied by the named sources and event types, and 'at any company domain' signals broad applicability, but there is no explicit when-to-use statement, no when-not, and no routing to alternative or complementary tools such as aggregate_gtm_signals. The reader must infer the fit from the content.

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