Skip to main content
Glama
Sign In
Panda Federation Tools

Panda Federation Tools

by pandadad0214
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Company Website Enricher: Tech Stack, Emails & Socials

company_website_enricher
Read-only

Enrich company domains from public sources into firmographic rows with published emails, phones, socials, address and tech stack. Filter by technology, email or phone before billing.

Instructions

Enrich company domains from public sources (the company's own site with robots.txt respected, DNS and RDAP): name, description, published emails and phones, LinkedIn and socials, address, tech stack by category, mail provider, SaaS tools seen in DNS and domain age. Unlike company_team_finder (named people and titles) and company_hiring_signals (open jobs), this returns one firmographic row per company. Use when you have domains and need contact points, technographics or a filter like sites running Shopify or HubSpot. Do not use to find people (use company_team_finder) or to grade email security (use email_domain_security_checker). Parameters: onlyWithTech, onlyWithEmail and onlyWithPhone filter before billing, so filtered-out domains are free. extraPages (0-4) reads contact/about/team pages: more found contacts, slower runs, same price. Only published contacts are returned; no guessed emails. Unreachable sites are free. Returns per item: agentSummary, companyName, description, primaryEmail, emails, phones, linkedinUrl, socials, address, cms, techStack, techByCategory, mailProvider, emailSendingTools, verifiedServices, domainCreated, domainAgeYears, domainExpires, registrar, copyrightYear, status.

Behavior: read-only; runs the Apify Actor pandadad0214/company-website-enricher (https://apify.com/pandadad0214/company-website-enricher) on your own Apify account. Price: $0.003 per domain enriched. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxDomains when you leave it unset, so it also limits what is billed; setting maxDomains higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

Input Schema

NameRequiredDescriptionDefault
domainsNoCompany domains, websites or emails. One per line: example.com, https://www.example.com/page or name@example.com all work (the domain is extracted, duplicates dropped). Leave empty for a 3-domain demo.
extraPagesNoExtra pages per site. Besides the home page, read up to this many contact / about / team pages to find emails, phones and the address. 0 to 4; default 2.
maxDomainsNoMaximum domains. You pay per domain returned, so this also caps the cost. 1 to 10,000; default 1,000.
onlyWithTechNoOnly return sites using any of these technologies. Optional. Keep only domains where at least one of these shows up in the tech stack, email tools or DNS-verified services, e.g. Shopify, HubSpot, Klaviyo, WordPress, Salesforce, Microsoft 365. Others are not returned and not charged.
onlyWithEmailNoOnly return domains with a public email. Domains without an email on their website are not returned and not charged.
onlyWithPhoneNoOnly return domains with a phone number. Domains without a phone link on their website are not returned and not charged.
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only and open-world, but the description adds pricing ($0.003/domain, unreachable sites and empty runs free), the spending cap mechanism, expected latency (5-15s typical, minutes for crawls), timeout escalation guidance, and the no-guessed-emails policy. These are material operational traits an agent cannot infer from annotations.

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?

Dense and front-loaded: purpose, sibling differentiation, usage, then parameters, then behavior/pricing. The enumerated return-field list is long but earns its place given there is no output schema. A few clauses (e.g. the actor URL restated alongside the name) could be trimmed without loss.

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 nine parameters, no output schema, and an open-world crawl, the description covers inputs, return shape, cost model, latency, and failure modes. Nearly nothing an agent needs to call this correctly and predict its bill is missing.

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

Parameters4/5

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

Schema coverage is 100%, so per-parameter documentation is already handled. The description still adds cross-parameter meaning the schema does not: filters are applied before billing so filtered-out domains are free, and run_max_items also caps billing while raising maxDomains can bill more than is returned. That billing interaction is genuine value-add beyond the fields themselves.

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 and resource ('Enrich company domains'), names the exact data sources (own site with robots.txt respected, DNS, RDAP), and enumerates the output categories. It explicitly distinguishes itself from company_team_finder and company_hiring_signals by saying it returns 'one firmographic row per company'.

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

Usage Guidelines5/5

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

Gives the positive trigger ('when you have domains and need contact points, technographics or a filter like sites running Shopify or HubSpot') and two explicit exclusions routing to company_team_finder for people and email_domain_security_checker for email security. That is as close to a routing table as a description gets.

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