Skip to main content
Glama

List Contact Segment

list_contact_segment
Read-only

Return a filtered contact segment using the same criteria as the web search page. Consumes the account's shared subscription balance (the same balance used by subscribed Excel exports and REST API usage: included monthly contacts first, then prepaid top-up contacts). A completed call always costs at least 1 unit. Costs 1 contact unit per returned contact row. Results are deterministically ordered and support limit/offset pagination. Response meta includes companyCount (number of distinct companies represented by matching contacts). Returned contact rows include person fields (name, title, email, phone, responsibility areas), compact employer context (companyId, companyName, countryName, region, city, wwwpage, industryName), and source classification attributes (hasWebshop, webshopPlatform, targetMarket). Full company descriptions, financials, and address details are omitted; use find_companies or list_company_segment for full company details. Supports webshopStatus, webshopPlatforms, and targetMarket filters. webshopPlatforms is only valid when webshopStatus is "identified" or omitted. Supports company keyword taxonomy filtering through keywordCategoryFilter. Use list_keyword_categories for broad main categories and search_keyword_subcategories for specific business activities. Pass only canonical returned name values; never pass localized labels or raw keywords. Your account exclusion list always applies automatically and cannot be disabled. Optional customerListMode: "exclude" removes companies on your customer list (net-new prospecting), "limit" returns only customer-list companies, "ignore" or omitted ignores the customer list. Exclude/limit require an active customer list managed in the web app (Company lists). For count-only questions, prefer count_contact_segment. Example: list_contact_segment({ countryId: -2460, contactInfoFilter: "both", organizationLevels: ["Top Management"], limit: 50, offset: 0 }).

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of contacts to return. Defaults to 100; cannot exceed 100. Use a small value such as 3 when only sample rows are needed.
offsetNoZero-based offset for paginating deterministic results. Use with limit.
companyIdNoOptional company ID filter. Restricts results to one company when provided.
countryIdYesCountry ID. Use list_countries to discover valid values. Note: IDs are negative integers as stored in the database (e.g. Finland = -2460, Sweden = -7520, Estonia = -2330).
profitMaxNoIn thousands of euros (EUR thousands). Maximum annual profit; negative values are allowed and represent net loss.
profitMinNoIn thousands of euros (EUR thousands). Minimum annual profit; negative values are allowed and represent net loss.
businessIdNoOptional company business ID filter. Normalizes dashes/spaces when matching (e.g. "1234567-8").
regionNameNoRegion/province name (case-insensitive substring match). Use the local-language name as shown in company records, e.g. "Uusimaa", "Stockholm".
turnoverMaxNoIn thousands of euros (EUR thousands). Maximum annual turnover. Example: 5000 = EUR 5M turnover.
turnoverMinNoIn thousands of euros (EUR thousands). Minimum annual turnover. Example: 5000 = EUR 5M turnover.
personnelMaxNoMaximum number of employees (headcount) as reported in company records.
personnelMinNoMinimum number of employees (headcount) as reported in company records.
targetMarketNoTarget market classification: "b2b" = B2B only (1), "b2c" = B2C only (2), "both" = both B2B and B2C (12), "unknown" = crawled but unknown (0), "not_crawled" = not yet crawled (NULL). Omitted includes every state.
industryCodesNoIndustry codes (NACE/TOL) for filtering companies and contacts. Codes match by prefix: a full code like "62010" matches one industry, while a shorter prefix like "62" matches every industry whose code starts with it. Call list_industries first to discover valid codes, then pass the returned id values here. IDs from list_industries are string-typed numeric codes, not integers — pass them as strings.
webshopStatusNoWebshop classification filter: "identified" = a webshop was found, "not_identified" = crawled and no webshop found, "not_crawled" = not yet crawled. Omitted includes all states including 0 and NULL.
foundedYearMaxNoLatest founding year to include (e.g. 2020).
foundedYearMinNoEarliest founding year to include (e.g. 2010).
jobFunctionIdsNoJob function IDs for multi-select filters. Use list_job_functions to discover valid values. Finer-grained than mainResponsibilityAreaIds.
customerListModeNoOptional customer-list mode: "exclude" removes companies on your customer list (net-new prospecting), "limit" returns only customer-list companies that match the other filters, "ignore" or omitted ignores the customer list. "exclude"/"limit" require an active customer list managed in the web app under Company lists; fails with CUSTOMER_LIST_REQUIRED otherwise. The account exclusion list always applies regardless of this setting.
industryGroupIdsNoIndustry group IDs for multi-select filters. Use list_industry_groups to discover valid values.
webshopPlatformsNoWebshop platform names (e.g. "shopify", "woocommerce"). Must be combined with webshopStatus "identified" or omitted; combining with "not_identified" or "not_crawled" is invalid. Values are normalized to lowercase/trimmed. Up to 20 values, each up to 50 characters.
contactInfoFilterNoContact-level required info filter: "email" (default) = each returned contact must have valid email, "phone" = must have phone number, "both" = must have both, "either" = must have a valid email, a phone number, or both. Use companyContactFilter on company-segment tools when filtering companies by whether they have at least one matching contact.
organizationLevelsNoHierarchy level filter; orthogonal to mainResponsibilityAreaIds/jobFunctionIds. Combine with responsibility filters for e.g. Sales + Top Management.
keywordCategoryFilterNoCompany keyword taxonomy filter. Use level "main" only with canonical name values returned by list_keyword_categories and level "sub" only with canonical name values returned by search_keyword_subcategories. Copy the returned name, not a localized labels value. any matches at least one item, all requires every item, and none excludes every item; non-empty buckets combine with AND. This filters classified company categories and subcategories, not raw keyword text.
newContactsWithinDaysNoReturns contacts created within the last N days (max 3650).
mainResponsibilityAreaIdsNoBroad functional responsibility area IDs (e.g. IT, Marketing). Use list_main_responsibility_areas to discover valid values. IDs are negative integers as stored in the database (e.g. Sales = -70, IT = -40, Marketing = -60, HR = -30, Finances = -50, Managing Director = -20). Combine with jobFunctionIds or organizationLevels to narrow further.
newResponsibilityAssignmentsWithinDaysNoReturns contacts with an assignment created within the last N days (max 3650).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / contactInfoFilter / description
      Previous value: -"Contact-level required info filter: \"email\" (default) = each returned contact must have valid email, \"phone\" = must have phone number, \"both\" = must have both. Use companyContactFilter on company-segment tools when filtering companies by whether they have at least one matching contact."New value: +"Contact-level required info filter: \"email\" (default) = each returned contact must have valid email, \"phone\" = must have phone number, \"both\" = must have both, \"either\" = must have a valid email, a phone number, or both. Use companyContactFilter on company-segment tools when filtering companies by whether they have at least one matching contact."
    • changedInput schema / properties / contactInfoFilter / enum
      Previous value: -[
      -  "email",
      -  "phone",
      -  "both"
      -]New value: +[
      +  "email",
      +  "phone",
      +  "both",
      +  "either"
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/non-destructive annotations by disclosing billing behavior (consumes shared subscription balance, minimum 1 unit per call, 1 unit per returned row), determinism, pagination support, the always-on account exclusion list, and the CUSTOMER_LIST_REQUIRED failure mode. These are material operational facts an agent cannot infer from structured fields.

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 but well-ordered: purpose first, then cost/return semantics, then filter constraints, then routing to siblings, closing with a concrete example. A few statements (customerListMode, webshopPlatforms validity) restate schema text verbatim and could be trimmed, so it is efficient rather than lean.

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?

For a 27-parameter tool with no output schema, the description supplies the missing pieces: what each returned row contains, what response meta includes (companyCount), cost model, and how to reach sibling discovery tools for enum values. Nothing essential for a correct call is left unstated.

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 baseline is 3, but the description adds cross-parameter semantics and discovery routing not fully spelled out in the schema (taxonomy level usage, canonical-vs-localized name rule, customer-list mode trade-offs) plus a worked example call. Some of this duplicates schema text, keeping it below a 5.

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 ('Return a filtered contact segment'), scopes it as contact-level output, and explicitly contrasts with siblings: find_companies/list_company_segment for full company details and count_contact_segment for count-only questions. It also enumerates the returned row shape (person fields, employer context, classification attributes), so an agent knows exactly what this returns.

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?

Names alternatives and the conditions that select them: count_contact_segment for count-only questions, find_companies/list_company_segment for full company details, list_keyword_categories vs search_keyword_subcategories for taxonomy level. It also states hard validity constraints (webshopPlatforms only with webshopStatus 'identified' or omitted; exclude/limit require an active customer list).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources