Full content of one post (returned under data.post). For comments use /posts/comments. (Costs 10 Zooq credits.)
| Name | Required | Description | Default |
|---|---|---|---|
| entityId | Yes | Activity id — bare numeric or urn:li:activity: form, both accepted. Get it from companies_posts — read data.activities[].entityId (person feeds are currently unavailable). |
| Name | Required | Description | Default |
|---|---|---|---|
| post | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond the annotations: it discloses a 10-credit cost, the return location under data.post, accepted entityId formats, and a current limitation around person feeds. These are non-obvious operational details that the readOnly/idempotent annotations do not cover. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each with a distinct job: define the result, redirect comments, and warn about cost. It is front-loaded with the core behavior and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, complete schema coverage, an output schema, and readOnly/idempotent annotations, the description is fully sufficient. It covers cost, output location, source, limitation, and the key sibling alternative without needing extra length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the entityId parameter is already well documented, including accepted formats and its source. The description does not need to repeat parameter syntax and does not meaningfully add to it. The baseline of 3 is appropriate because the schema carries the parameter-semantics burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this tool returns the full content of a single post and even names the output path (data.post). It is clearly differentiated from the sibling comments tool with 'For comments use /posts/comments', and the 'one post' wording separates it from posts_all. The annotation title 'Get post details' reinforces the intended purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes comment-related work to /posts/comments, which is a clear when-not/alternative instruction. The parameter schema adds workflow guidance by instructing the agent to obtain entityId from companies_posts and notes that person feeds are unavailable. The credit cost also signals to use it deliberately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.