Skip to main content
Glama
mambalabsdev

Team Page People Extractor MCP Server

by mambalabsdev

Extract Team Page People

extract_team_page_people
Read-onlyIdempotent

Extract names, titles, and source page for people a company publishes on its team, leadership, or about page. Also reports which pages were reachable, distinguishing no people from an unreadable site.

Instructions

Extract the people a company publishes on its own team, leadership or about page, and return their names, titles and the page each one came from. It also reports which pages it actually reached, so an empty result tells you whether the company publishes nobody or whether the site could not be read, which are very different answers. output_grain person returns one row per person and is what most tables want; output_grain company returns one row per company with a people_json array plus the first five names and titles flattened into columns. seniority_filter narrows to founders and C level, or adds VPs, directors and heads. People are ordered by seniority before max_people applies, and anything dropped is logged with a count. include_emails is off by default and should usually stay off: across the domains tested, the addresses published on team pages were role mailboxes, placeholders and literal template strings rather than real people, so when it is on the emails come back on the company row only and are never attached to a named person. Results are cached for 14 days. Nothing here scrapes LinkedIn or any profile network; it reads only what the company published itself. Requires an APIFY_TOKEN and consumes Apify credits. Read only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesA single company domain, for example swishdata.com. Protocol and path are stripped.
skipCacheNofalse uses the 14 day result cache. true re-crawls the company from scratch. Default: "false".
max_peopleNoSent as a string so Clay can map a column into it. Clamped to 1 to 200. People are ordered by seniority before the cap applies, and anything dropped is logged with the count. Default: "50".
output_grainNoperson returns one row per person, which is the default and what most Clay tables want. company returns one row per company with a people_json array plus the first five names and titles flattened into columns. Default: "person".
include_emailsNoOff by default and you should probably leave it off. Across three domains that published an email on a team page we found one role mailbox, one placeholder in example content, and one literal user@domain.com template string. Not one was a real person's address. When on, emails come back on the COMPANY row only, never attached to a named person, because nothing on these pages proves which address belongs to whom. Default: false.
seniority_filterNoall keeps everyone the page published. executive keeps founders and C-level only. leadership adds VPs, directors and heads. Default: "all".
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses caching behavior (14 days, skipCache flag), result ordering and logging when items are dropped, email quality caveats with concrete evidence, and explicitly states it reads only company-published content. These details affirm the safety profile and add operational nuance.

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 description is long (twelve sentences) but each sentence conveys a distinct fact or guidance: output format, empty-result interpretation, grain behavior, filtering semantics, email caveats, caching, and scope boundary. It is well-structured and front-loaded with the primary purpose, with no filler.

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 compensates by explaining return values (names, titles, page, reached pages, people_json array), edge cases (empty results), parameter trade-offs (emails on company row only), and the operational context (cache, credits, exclusions). This is a fully self-contained explanation.

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% and each parameter already has detailed explanations. The description mostly reiterates schema content (e.g., output_grain flattening, seniority ordering) with minor additions like 'what most tables want'. Since it adds little beyond the schema, baseline 3 is appropriate.

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 starts with 'Extract the people a company publishes on its own team, leadership or about page, and return their names, titles and the page each one came from' – a specific verb and resource with a clear output. It also explicitly distinguishes itself from LinkedIn scraping, leaving no ambiguity about the tool's scope.

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?

Provides explicit recommendations: 'output_grain person ... is what most tables want', 'include_emails is off by default and should usually stay off', and 'Nothing here scrapes LinkedIn or any profile network'. It also clarifies prerequisites (APIFY_TOKEN, Apify credits) and how to interpret empty results, giving the agent a complete decision framework.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-team-page-people-extractor'

If you have feedback or need assistance with the MCP directory API, please join our Discord server