Skip to main content
Glama
Sign In
Panda Leads Tools

Panda Leads Tools

by pandadad0214
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Company Team & Decision-Maker Finder: Names, Titles, Emails

company_team_finder
Read-only

Find named staff and decision makers at a company by extracting people, titles, departments, emails, and LinkedIn links from public team, leadership, and about pages.

Instructions

Find the named people at a company from its own public website (team, leadership, about and staff pages): name, title, seniority, department, decision-maker flag, published email, LinkedIn link and the company's email pattern. Unlike company_website_enricher (one firmographic row per company) and researcher_expert_finder (academics ranked by publications), this returns one row per person; it never scrapes LinkedIn. Use when you need decision makers or staff contacts at known companies. Do not use for academic experts (use researcher_expert_finder), for company-level contacts or tech stack (use company_website_enricher), or when the site has no team page. Parameters: billing is per person, not per company, so maxPeoplePerCompany (most senior first) and decisionMakersOnly are the main cost levers; run_max_items sets maxCompanies only. Pasting the exact team page URL is faster and more reliable than a bare domain. maxPagesPerCompany trades coverage for speed. emailGuess is inferred (pattern from published emails, else unverified first.last) and comes with emailConfidence; verify before sending. Companies with no readable team page are free. Returns per item: agentSummary, company, domain, name, firstName, lastName, title, seniority, department, isDecisionMaker, email, emailGuess, emailConfidence, linkedinUrl, profileUrl, sourceUrl, foundVia.

Behavior: read-only; runs the Apify Actor pandadad0214/company-team-finder (https://apify.com/pandadad0214/company-team-finder) on your own Apify account. Price: $0.002 per person found. 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 but does not limit what the Actor bills; use the tool's own limits and run_max_charge_usd. 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
companiesNoCompany websites. One per line: a domain (acme.com), a website URL, or a work email (the domain is used). Paste the exact team page URL when you know it. Leave empty for a 2-company demo.
departmentsNoDepartments. Optional. Keep only these departments (guessed from the title).
maxCompaniesNoMaximum companies. You pay per person found; companies with nobody found are free.
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.
titleKeywordsNoTitle contains (any of). Optional. Keep people whose title contains one of these words.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
decisionMakersOnlyNoDecision makers only. Keep only C-level, founders/owners, presidents, partners, VPs and directors/heads. Everyone else is skipped and not charged.
maxPagesPerCompanyNoMax pages per company. Home page plus team, leadership, about and staff pages. Default 6.
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).
maxPeoplePerCompanyNoMax people per company. Most senior people first. Caps cost on companies with huge staff pages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive/non-idempotent; the description goes well beyond them by disclosing billing mechanics ($0.002 per person, per person not per company), the hard spend cap via run_max_charge_usd and its default, the fact that companies with no readable team page are free, typical 5-15 s latency versus multi-minute crawls, and the 300 s timeout ceiling. It also flags that emailGuess is inferred rather than verified and carries emailConfidence, which is exactly the kind of caveat annotations cannot express.

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?

Structure is strong and front-loaded: purpose, then sibling differentiation, then use/do-not-use, then parameter economics, then return fields, then runtime behavior. It is on the long side and the middle parameter paragraph is a dense run-on that merges cost, URL, and email-inference topics, costing it the top score, but nearly every clause carries actionable information.

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 10 optional parameters, no output schema, and a paid third-party Actor behind it, the description covers everything an agent needs: what each cost control does, what a run returns, timeout and cap behavior, and how to size inputs after a failure. The explicit return-field list compensates for the absent output schema.

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

Parameters5/5

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

Although schema coverage is 100% (so 3 would be the baseline), the description adds semantics the schema does not: it identifies maxPeoplePerCompany and decisionMakersOnly as the real cost levers, explicitly explains that run_max_items limits returned items but not Actor billing, and explains that maxPagesPerCompany trades coverage for speed. It also clarifies that decisionMakersOnly results are not charged, which changes how an agent should configure the call.

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 description opens with a specific verb and resource ('Find the named people at a company from its own public website') and enumerates exactly what is returned (name, title, seniority, department, decision-maker flag, email, LinkedIn, email pattern). It then explicitly disambiguates from two named alternatives by their unit of return ('one firmographic row per company' vs 'one row per person' vs 'academics ranked by publications').

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?

Usage is spelled out on both sides: 'Use when you need decision makers or staff contacts at known companies' followed by three explicit exclusions routing to researcher_expert_finder, company_website_enricher, and the 'no team page' case. It also gives an operational preference ('Pasting the exact team page URL is faster and more reliable than a bare domain'), which is guidance an agent can act on immediately.

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