Zooq

companies_affiliated_pages

Read-onlyIdempotent

Affiliated / subsidiary / showcase pages of a company. Keyed by the numeric organization id: pass slug and Zooq resolves it for you at no extra credit cost, or pass id from companies_entity_id to skip the lookup. (Costs 10 Zooq credits.)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No	Numeric organization id from companies_entity_id; the urn:li:organization: form is accepted. An org_ id (dataset namespace, from companies_info) or a slug placed here is recognized and translated automatically. Provide `id` OR `slug`.
`slug`	No	Company public slug — the part after linkedin.com/company/ — or the full company URL. Resolved to `id` automatically at no extra credit cost. Any company identifier is accepted here and sorted by format (slug, URL, numeric id, org_ id). Provide `id` OR `slug`; `slug` is the simplest.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	No	Example value was a number
`affiliatedPages`	No	Array in the example

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable non-annotation behavioral context: the 10-credit cost, automatic slug resolution with no extra credit cost, and the dependence on companies_entity_id as a source for `id`. This goes beyond what structured fields reveal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-ordered: purpose first, parameter strategy second, cost last. Every sentence earns its place and there is no redundant or filler content.

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 simple read-only lookup with two optional parameters, a fully described schema, an output schema, and safety annotations, the description covers the essential invocation decisions: which identifier to use, how slug resolution works, and the credit cost. Nothing critical is missing for an agent to call this tool 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?

The input schema already fully documents both parameters with clear descriptions, so the baseline is 3. The description adds a useful selection workflow—slug is resolved automatically, id skips resolution—but does not introduce new semantic details beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource: affiliated/subsidiary/showcase pages of a company, which is specific enough to distinguish it from related siblings like companies_info or companies_insights. It lacks an explicit verb like 'list' or 'retrieve' and does not explicitly name sibling tools, so it falls just short of a top score.

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 gives useful guidance on choosing between `slug` and `id`, including credit-cost implications, which helps correct invocation. However, it does not say when to prefer this tool over alternative company tools or provide explicit when-not-to-use guidance; usage is mostly implied from the resource definition.

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

All Zooq tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation2/5

Many tools have strongly overlapping purposes: companies_name_lookup is explicitly equivalent to search_companies, companies_enrich/companies_info/companies_universal_name_to_id all return company-profile data, and profile_full overlaps with profile_employment_history and profile_enrich. The descriptions are detailed, but an agent would still frequently have to choose between near-duplicate endpoints.

Naming Consistency4/5

Tool names mostly follow a predictable resource-prefixed snake_case pattern, such as companies_*, jobs_*, posts_*, profile_*, and search_*, which makes the set readable and groupable. Minor inconsistencies like jobs_details_v2, g_title_skills_lookup, and mixed noun suffixes (info/details/full/lookup) keep it from a perfect score.

Tool Count2/5

44 tools is well beyond the heavy 25+ band, and several tools appear to be different lookup modes or near-duplicates of the same underlying capability. The broad LinkedIn-style data domain explains much of the size, but the set still feels bloated rather than well-scoped.

Completeness4/5

The API covers the core read-only professional-data workflows well: people, companies, jobs, posts, comments, likes, email discovery/verification, schools, skills, and targeted searches. Minor gaps exist, such as some job filters being unusable and no direct exposure of certain profile alias endpoints, but agents can generally complete end-to-end workflows.

Resources

Need Help?