Skip to main content
Glama
Sign In
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Enrich Company Firmographics

enrich_company_firmographics
Idempotent

Enrich a company domain into firmographics like employee band, industry, HQ, and revenue estimate, with source provenance. Reads public data, no writes.

Instructions

Enrich a company domain into structured firmographics: employee band, industry, HQ, founded year, revenue estimate, logo, and description, with source provenance. Parsed from the company's schema.org/Organization JSON-LD and HTML meta tags and returned as a flat, Clay-ready JSON row with a source_signals array and a data_completeness score. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
domainNoBare company domain to enrich, e.g. stripe.com. Provide this or domains.
domainsNoList of bare domains for batch processing. Takes precedence over domain.
batchSizeNoDomains enriched concurrently per wave in batch mode. Default 5, maximum 10.
skipCacheNoForce a fresh enrichment and ignore the 7 day result cache.
company_nameNoOptional company name, used as a fallback label when the page does not expose one.
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. Addedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: auth requirement (APIFY_TOKEN), per-call credit consumption, a 7-day result cache with a skipCache escape, a source_signals provenance array, and a data_completeness score. Minor tension with readOnlyHint=false given the claim 'writes nothing' — defensible since the call still consumes credits and creates a cached run, but the description could reconcile that explicitly.

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?

Two dense sentences, front-loaded with the operation and output before the operational caveats. Efficient, though the first sentence is a long run-on that could be split for faster scanning.

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 carries the return-shape burden and does so (flat Clay-ready JSON row, source_signals, data_completeness). Combined with auth, cost, caching, and non-destructiveness notes, an agent has everything needed to invoke it correctly.

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 six parameters (domain/domains precedence, batchSize caps, skipCache, max_charge_usd) are already documented in the schema. The description adds the return-row shape but no extra parameter semantics, 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 (enrich) and resource (company domain into firmographics) and enumerates the exact output fields (employee band, industry, HQ, founded year, revenue, logo, description). This is unmistakably distinct from siblings like detect_gtm_tech_stack or resolve_linkedin_url, so an agent can select it without opening the schema.

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?

The description supplies operating context (public data only, requires APIFY_TOKEN, consumes Apify credits, 7-day cache) but never states when to reach for this tool versus alternatives such as resolve_company_identity or score_icp_fit. Usage is implied by the resource name rather than explicitly routed.

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