LinkedIn: The LinkedIn Data API offers access to detailed information on individuals, companies.
Provide either slug or companyId. If neither is given, the request fails with
400 VALIDATION_ERROR.
Take the slug from a /company/search result rather than guessing it from the
company name — a company's slug often differs from its display name. Group: Companies. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | The company's short name, as it appears in its LinkedIn URL. Required unless `companyId` is provided. | |
| companyId | No | The company's numeric identifier. Required unless `slug` is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses the failure behavior (400 VALIDATION_ERROR when both params are missing) and the billing cost (1 credit per call). It also hints at the read-only nature via 'Get', though it does not describe the response format or mention rate limits. This is meaningful behavioral disclosure beyond the schema.
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 concise sentences, front-loaded with the parameter requirement, followed by a practical tip and structured metadata (Group, Billing). Every sentence contributes value and no redundant text is present.
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?
For a simple read operation with no output schema or annotations, the description covers the essential prerequisites, error condition, and an important sourcing tip. The return value is intuitive for a 'get profile' tool, so the lack of explicit return format is a minor gap. Overall it is fairly complete.
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?
The schema already documents both parameters with descriptions and examples, so the baseline is 3. The description adds critical semantics: the slug must be taken from a `/company/search` result and may differ from the display name, which prevents a common misuse. This goes beyond basic parameter documentation, justifying a 4.
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 title 'Get a company profile' states a clear verb and resource, and the description adds that it requires either `slug` or `companyId`. While it doesn't explicitly distinguish from sibling tools like get_post or get_person_profile, the resource type 'company' is unambiguous. A score of 4 reflects the clear purpose without explicit sibling differentiation.
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?
The description gives clear usage context: it explicitly says to provide either `slug` or `companyId`, warns that omitting both causes a 400 error, and advises taking the slug from `/company/search` rather than guessing it. This is strong contextual guidance, though it doesn't explicitly state when to choose this tool over alternatives or mention exclusions. Hence a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns people who list this company as their employer.
Results may include private or out-of-network profiles, which appear with the name
LinkedIn Member. Full profiles cannot be retrieved for those records, so check
the name before calling /person-profile with the returned memberId. Group: Companies. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| companyId | Yes | The company's numeric identifier, from `/company/search` or `/company`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It meaningfully discloses that results may include private/out-of-network profiles shown as 'LinkedIn Member' and that full profiles cannot be retrieved for those records. This goes beyond the schema and helps the agent behave correctly downstream.
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 compact and front-loaded: the first line states the core purpose, the second line covers an important edge case, and the remaining metadata (group, billing) is minimal. Every sentence earns its place with no repetition of the title or schema.
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?
For a simple list tool with fully documented parameters and no output schema, the description is largely complete. It names the key result field (`memberId`), warns about non-retrievable profiles, and the schema covers pagination. It does not describe the full output shape, but that is not essential for selection and initial invocation.
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%, so the baseline applies: the description does not need to re-explain parameters. It adds no parameter-level detail, but it does reference the returned `memberId` in a behavioral caveat. This is acceptable given the schema already documents `companyId`, `count`, and `start`.
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 uses a specific verb and resource: 'Returns people who list this company as their employer.' This clearly identifies the purpose as listing a company's employees and distinguishes it from sibling tools like get_company_companyId_jobs or get_company_posts, even without naming them.
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?
The description gives clear context for use and even provides a follow-up instruction: check whether the name is 'LinkedIn Member' before calling `/person-profile`. It does not explicitly name alternatives or state when not to use this tool, but the intended use is clear enough given the company-specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns an empty list if the company has no open postings.
Use the jobId from a result with /jobs/detail/{jobId}. Group: Companies. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| companyId | Yes | The company's numeric identifier, from `/company/search` or `/company`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does add useful context: the empty-list edge case, per-call billing cost, and the presence of jobId in results. It does not discuss authentication, sorting, or full response shape, but for a read-only list endpoint the main behavioral surprises are covered.
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 compact and front-loaded, with the empty-list behavior first, then follow-up routing, then cost. The 'Group: Companies' metadata is somewhat redundant, but no sentence is wasted overall.
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?
For a simple list endpoint with no annotations and no output schema, the description covers the important edge case, the downstream detail endpoint, and cost. However, it leaves pagination behavior to the schema and does not describe response items beyond jobId, making it adequate but not fully complete.
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?
All three parameters already have complete schema descriptions, including defaults for count and start and the origin of companyId from /company/search or /company. The description adds no parameter-specific detail beyond the schema, so the baseline score of 3 is appropriate.
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 title and description clearly identify the tool as listing a specific company's open jobs, and the empty-list note reinforces the exact scope. It is easily distinguished from the search and detail siblings, though it does not explicitly name a sibling comparison.
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?
No guidance is provided on when to use this tool instead of alternatives like get_jobs_search or get_company_companyId_posts. The only directional note, using a returned jobId with /jobs/detail/{jobId}, describes a follow-up action rather than a selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the same post structure as /person-profile/posts.
This endpoint is addressed by slug only. Group: Companies. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The company's short name, as it appears in its LinkedIn URL. | |
| count | No | Number of posts per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the burden of disclosing behavioral traits. It does mention billing per call (1 Credit) and that it returns the same post structure as another endpoint, which is useful, but it does not disclose mutation/safety properties, rate limits, auth needs, or what happens with missing/invalid slugs. The `slug`-only constraint is helpful but minimal.
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 compact and front-loads the key behavioral fact (same post structure as another known endpoint), then explains addressing and group/billing. It is efficient and avoids unnecessary padding, though the billing detail is marginal for tool invocation.
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 schema covers all parameters and provides pagination hints, the description is mostly adequate for a filtered read-style endpoint. However, without annotations, the description does not state whether this operation is read-only or whether any authorization is required, and it does not explain the `cursor` pagination flow, which is partly in the schema. The sibling tools suggest a broader API context, but the description alone is not fully complete for safe invocation.
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?
The input schema already provides descriptions for all three parameters (`slug`, `count`, `start`), including defaults and a pagination hint for `start`. The description adds context that `slug` is the company's short name as in its LinkedIn URL, which is already in the schema. Since schema_description_coverage is high (100%), the description does not need to add much, and it complements the schema by clarifying the endpoint's addressing mode.
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 says it returns the same post structure as `/person-profile/posts`, and is addressed by `slug` only, which clearly identifies the resource and the key identifier. However, it does not explicitly distinguish itself from sibling tools like `get_person_profile_posts` or `get_posts_postId_comments` beyond the `slug` addressing and group label.
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?
The description implies usage: use this endpoint for a company's posts, addressed by `slug`. It does not explicitly state when to use this tool over siblings, nor does it mention when not to use it. The reference to pagination via `cursor` in the parameter schema provides some context, but the description itself offers no alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the slug or companyId from a result to fetch full details from /company,
the employee list, or the job list. Group: Companies. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| keyword | Yes | Free-text search term. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It reveals that results contain slug/companyId, but it does not state whether the operation is read-only, what the response shape looks like, how ordering works, or anything about pagination beyond what the schema already says. Billing/group metadata is not meaningful behavioral context.
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 short, but it front-loads secondary follow-up guidance instead of the core search behavior. It should start with something like 'Search companies by keyword', with the downstream slug/companyId usage as secondary context. The Group/Billing line is compact but not central.
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?
With no annotations and no output schema, the description leaves critical gaps: it does not explain what the tool returns, whether it is a list, how to page through results, or how to distinguish it from get_company and related detail tools. The only useful addition is the downstream endpoint hint, which is insufficient for confident invocation.
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%: keyword, count, and start all have descriptions in the input schema. The tool description adds no parameter-level information, so the baseline score of 3 applies.
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 never explicitly says that this tool searches for companies; it immediately pivots to a follow-up instruction ('Use the slug or companyId from a result...'). The primary action is only recoverable from the tool name and title, so the description itself is vague and potentially misleading about what the tool does.
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?
The description gives a workflow hint: results expose slug/companyId that can be used for /company, employee list, or job list endpoints. However, it does not explicitly contrast this tool with sibling tools or state when to choose search over the detail tools, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full description for a posting. Several fields are only present on some
postings; the company name is most reliably taken from the search result that
provided the jobId. Group: Jobs. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The posting's identifier, from `/jobs/search` or `/company/{companyId}/jobs`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context: some fields are not present on all postings, the company name reliability caveat, and billing per call. It does not mention authentication, errors, or response shape, but the provided caveats go beyond a minimal description.
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, front-loaded with the core purpose, followed by a useful caveat and billing/group metadata. Every sentence earns its place with no redundancy or 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?
For a simple one-parameter detail endpoint with no output schema, the description covers what is returned, field variability, and source of the jobId. It is sufficiently complete for an agent to call and interpret the result correctly, though it could mention error or auth expectations.
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%: the jobId parameter is fully documented with its source and example. The description only references the jobId indirectly ('provided the jobId') and adds no new parameter semantics 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns the full description for a posting.' This clearly identifies the tool's function and distinguishes it from search/list-oriented siblings. It does not explicitly name a sibling, but 'full description' strongly implies a detail endpoint.
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?
The description implies when to use the tool: when the full posting description is needed. It also provides helpful context that the company name should be taken from the search result, suggesting a relationship to search tools. However, it does not explicitly state when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use the jobId from a result with /jobs/detail/{jobId}. Group: Jobs. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| geoId | No | Location code. Türkiye is `102105699`; worldwide is `92000000`. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| keyword | Yes | Search term for the job title or description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions billing cost and group, and indirectly that results contain jobId. It omits read-only nature, pagination mechanics beyond schema hints, response format, or any rate limiting. The minimal disclosure falls short of the burden placed on the description.
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 very short and front-loaded with the most actionable instruction. The metadata lines about group and billing are compact. Nothing is verbose, though the purpose clarity suffers from oversimplification.
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?
With no annotations, no output schema, and only three brief sentences, the description leaves out key context: what a typical response looks like, how pagination should be handled with cursor, how geoId affects results, and what keyword does. It partially compensates by pointing to the detail endpoint, but overall it is incomplete for a search tool with 4 parameters.
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?
The input schema's description coverage is high (all 4 parameters are described with examples and defaults), so the baseline is 3. The tool description adds no additional parameter-level meaning; it only mentions jobId usage after results are obtained.
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 does not explicitly state the tool's purpose. It implies a search/list behavior by instructing to use the jobId from a result with the detail endpoint, but the primary verb and resource are left to the title and name. This is enough to understand the basic function but is not as direct as a clear statement like 'Searches job postings by keyword'.
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?
The only usage guidance is a follow-up instruction to pass jobId to the detail endpoint. It does not explain when to use this tool versus sibling search tools (e.g., get_company_search, get_people_search), nor does it mention any exclusions or prerequisites for calling this endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All filters are optional and can be combined. Returns the same person structure as
/company/{companyId}/employees. Returns an empty list when nothing matches. Group: Person. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| title | No | Restrict results by job title. | |
| geoUrn | No | Location code. Türkiye is `102105699`. | |
| keyword | No | Free-text search term. | |
| companyId | No | Restrict results to people at this company. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses useful behaviors: empty-list on no match, identical structure to the employees endpoint, and billing cost per call. It does not mention authentication, rate limits, error behavior, or whether results are read-only, leaving part of the burden unmet.
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 compact and avoids repeating schema-level detail. The filter rule is front-loaded, followed by response-shape and empty-result behavior. The trailing group/billing metadata is short and useful, though the description would be slightly stronger if it opened with an explicit purpose statement.
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?
For a six-parameter tool with no output schema and no annotations, the description covers the important operational context: filter combinability, response structure via a known endpoint, empty-result behavior, and cost. It lacks explicit sibling differentiation and authentication/error context, but the essential calling semantics are present and the schema covers parameter documentation.
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%, so the baseline is 3; the description adds value beyond the schema by stating that all filters are optional and can be combined. This cross-parameter semantic is not expressed per-property in the schema and helps an agent understand valid query construction.
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 title 'Search people' provides the verb and resource, and the description adds meaningful scope: all filters are optional/combinable and it returns a person structure identical to `/company/{companyId}/employees`. It is clear enough to distinguish from company-search and profile siblings, though the description itself never states the core action in an explicit sentence like 'Searches for people matching the given filters.'
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?
The description implies usage by noting that filters are optional, combinable, and that results match the employee-list person structure. However, it does not explicitly say when to prefer this tool over `get_company_companyId_employees` or `get_person_profile`, nor does it state exclusions. The guidance is implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a full profile including experience, education, and skills.
Obtain a memberId from /people/search or /company/{companyId}/employees.
Note that profiles which are private or outside your network cannot be retrieved;
these appear in listings with the name LinkedIn Member. Group: Person. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| memberId | Yes | A LinkedIn member identifier, returned by `/people/search` and `/company/{companyId}/employees`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It meaningfully warns that private or out-of-network profiles will not be retrievable and may appear as 'LinkedIn Member', which is useful. However, it does not mention authentication requirements, potential error conditions, or response shape beyond the listed sections.
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 only four sentences and front-loads the core purpose immediately. The prerequisite, limitation, group, and billing information are each concise and useful, though the group and billing details are slightly tangential to the primary call semantics.
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?
For a single-parameter read tool with no output schema, the description provides a solid return summary (full profile with experience, education, skills), a key limitation, and the source of the required parameter. It does not describe pagination or field details, but these are not essential for basic invocation.
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?
The input schema already provides 100% coverage for the memberId parameter, including its type, example, and a description matching the tool description. The description adds no new parameter meaning beyond repeating where to obtain the ID, so the baseline of 3 is appropriate.
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 opens with a specific verb and resource: 'Returns a full profile including experience, education, and skills.' This clearly states what the tool does and distinguishes it from the sibling get_person_profile_posts by focusing on the profile content rather than posts.
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?
The description gives a clear prerequisite by telling users how to obtain a memberId from /people/search or /company/{companyId}/employees. It also notes when profiles cannot be retrieved (private or outside network). However, it does not explicitly contrast this tool with alternatives like get_person_profile_posts, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns an empty list if the person has not posted. Group: Person. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of posts per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| memberId | Yes | A LinkedIn member identifier, returned by `/people/search` and `/company/{companyId}/employees`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries much of the burden. It usefully discloses that an empty list is returned when the person has not posted and notes the billing cost. However, it does not mention authentication needs, pagination behavior beyond the schema, error cases, or whether the posts are public or authored-only.
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 short and front-loads the most notable behavioral detail: the empty-list result. Group and billing details are compact and do not add clutter. It could have used the space to state the purpose more explicitly, but it remains efficient.
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?
For a simple paginated post-listing tool, the schema covers parameter mechanics well, but no output schema exists and the description does not characterize the returned post objects or provide usage context. The empty-list behavior helps, but an agent still lacks guidance on what a successful response looks like or when to choose this tool over related person/post tools.
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?
The input schema already provides strong descriptions and examples for all three parameters, including the cursor-based pagination semantic on `start`. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
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 title and name clearly identify the operation as listing a person's posts, and the description mentions the person context via 'Group: Person.' It is distinguishable from siblings like get_person_profile because it explicitly targets posts, even though the description itself does not restate the verb 'list.'
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?
There is no guidance about when to use this tool versus alternatives such as get_person_profile or the post-detail tools. The first sentence explains an edge-case behavior, but it does not state use cases, exclusions, or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns an empty list when the post has no comments. Group: Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| postId | Yes | The post's `ugcPostId`, taken from `/person-profile/posts` or `/company/posts`. Use `ugcPostId` here, not `activityId`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It usefully discloses the empty-list edge case, which adds real value beyond the schema. However, it does not mention pagination behavior, error cases, authentication needs, or the general response shape, leaving meaningful behavioral gaps.
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 brief and front-loads the most useful behavioral fact: the empty-list return. The 'Group: Posts' and 'Billing per call' sentences are not very useful for tool selection, but they are short and do not substantially harm readability.
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?
There is no output schema, so the description should explain what the response contains and how pagination works, but it only mentions the empty-list case. The schema hints at pagination via 'start' and 'cursor', but the description leaves the actual response structure and when to use pagination unspecified.
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%, so the schema already documents postId, count, and start in detail. The description adds no additional parameter meaning, which fits the baseline of 3 when the schema carries the parameter documentation 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 title 'List comments on a post' plus the description's statement that it 'Returns an empty list when the post has no comments' make the tool's core function clear. However, the description itself never directly states that it returns comments, relying on the title, and it does not distinguish this from the sibling get_posts_postId_reactions.
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?
No guidance is given about when to use this tool versus alternatives such as get_posts_postId_reactions or get_company_posts. The description only provides a conditional behavior, group, and billing information, none of which helps an agent decide between this tool and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns an empty list when the post has no reactions. Group: Posts. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results per page. | |
| start | No | Offset of the first result. Pass the `cursor` value from the previous response to fetch the next page. | |
| postId | Yes | The post's `ugcPostId`, taken from `/person-profile/posts` or `/company/posts`. Use `ugcPostId` here, not `activityId`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does add the useful edge-case that an empty list is returned when there are no reactions, and notes Group/Billing, but it does not clarify auth expectations, read-only nature, rate limits, or response/error behavior beyond what the schema already indicates.
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 very short and front-loads the key behavioral detail about empty lists. The 'Group: Posts' and billing lines add a little operational context, though 'Billing per call' is marginal for an AI agent; overall the text is efficient and scannable.
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?
For a simple list endpoint with three well-documented parameters, the description plus schema cover the basics. However, without an output schema it does not describe the reaction object shape, and it omits pagination-flow context beyond the schema's `start` description, leaving some useful context missing.
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% for count, start, and postId, so the schema already documents parameter semantics. The description adds no extra parameter-level meaning, so the baseline score of 3 applies.
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 title 'List reactions on a post' clearly states the action and resource. The resource is specific, and the name distinguishes it from sibling tools like get_posts_postId_comments, though the description itself does not explicitly differentiate it.
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?
The description gives no guidance on when to use this tool versus alternatives such as get_posts_postId_comments. It relies entirely on the name/title to communicate purpose, with no stated conditions, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_companyget_company_companyId_employeesget_company_companyId_jobsget_company_postsget_company_searchget_jobs_detail_jobIdget_jobs_searchget_people_searchget_person_profileget_person_profile_postsget_posts_postId_commentsget_posts_postId_reactionsget_v1_company_detailsget_v1_person_detailsget_v1_post_detailsget_v1_pulse_detailsget_v1_search_peoplesget_v2_autocompleteget_v2_profile_contact_infoget_v2_profile_detailsget_v2_profile_header_detailsget_v2_search_allget_v2_search_peopleget_v1_company_detailsget_v1_person_detailsget_v1_post_detailsget_v1_pulse_detailsget_v1_search_peoplesget_v2_autocompleteget_v2_profile_contact_infoget_v2_profile_detailsget_v2_profile_header_detailsget_v2_search_allget_v2_search_peopleClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
LinkdAPI - the best linkedin professional data API: Powerful, lightweight B2B Data API for.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
LinkedIn data for AI agents: search, profiles, companies, posts. Free key, self-minted, no signup.
LinkedIn API as MCP tools to retrieve profile data and publish content. Powered by HAPI MCP.
Add one secure layer between your agents and this server.
Most tools map to distinct resource-action pairs, but `get_company_companyId_employees` and `get_people_search` can both return person listings, creating minor overlap. `get_company_posts` vs `get_person_profile_posts` is clear by resource name, so confusion is limited.
All tools follow a `get_<resource>` pattern with path-like segments, but there are minor inconsistencies such as `get_people_search` (plural) vs `get_person_profile` (singular), and redundant segments like `get_company_companyId_employees`. Overall the pattern is recognizable and predictable.
Twelve tools is well-scoped for a read-only LinkedIn data access server. The surface covers companies, jobs, people, and posts without unnecessary duplication or excessive fragmentation.
The core read workflows for company, job, person, and post data are well covered. A notable minor gap is the lack of a standalone `get_post` tool to fetch a post's details by ID, though post content appears in company and person post listings.