linkedin-company-admin-mcp

by negrueu

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Tools are largely distinct with clear prefixes for session, company, and personal actions. A few pairs like company_list_mentions and personal_read_company_mentions could be confused, but descriptions clarify the difference. Overall boundaries are clear.
Naming Consistency4/5
Most tools follow a <scope>_<verb>_<object> pattern, such as company_read_page and company_create_post. Minor deviations like company_analytics and session_status (nouns rather than verbs) exist but do not disrupt the overall predictable scheme.
Tool Count3/5
With 24 tools, this falls into the heavy range (16-25). The count is justified by the breadth of LinkedIn admin features, but it borders on too many for easy navigation. Each tool serves a distinct purpose, yet some trimming or grouping could improve focus.
Completeness4/5
The set covers a wide range of admin workflows: page reading and editing, post lifecycle (create, edit, delete, schedule), comments, analytics, followers, invites, and personal advocacy actions. Notable gaps include listing or deleting comments, and fetching a single post by ID, but these are workable gaps.
Average 3.9/5 across 24 of 24 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description aligns with these annotations and adds minimal context by specifying 'admin notifications', but does not disclose additional behavioral traits such as auth requirements or data scope limitations.
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 a single, clear sentence with no redundant words. It efficiently states the action and target, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are presumably covered, but the description lacks context on when to use this tool versus personal_read_company_mentions and does not mention pagination or the max_results default. It provides a minimal but adequate overview for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about company_id or max_results. The parameter names are somewhat self-explanatory, but the description does not compensate for the lack of schema documentation, leaving the agent to infer meanings and defaults.
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 'List admin notifications for the page' uses a specific verb ('List') and resource ('admin notifications'), clearly indicating a read operation. It is distinguishable from sibling tools like personal_read_company_mentions by the company-level focus, though there is slight ambiguity between 'mentions' and 'admin notifications'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. The description does not mention that company_list_mentions should be used for company-level notifications while personal_read_company_mentions handles personal ones, nor does it address any other usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the annotations. It only restates the action of replying, without adding context about public visibility, permissions, rate limits, or side effects. The annotations already indicate a write operation and open-world behavior.
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 a single, front-loaded sentence that states the action and subject. No filler words, earning high marks for conciseness though it sacrifices guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the comprehensive schema and output schema, is adequate for a simple reply operation. However, it lacks contextual information about when to use it and potential side effects, making it slightly incomplete for an agent needing to select among sibling tools.
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?
All four parameters are fully documented in the schema with descriptions, so the description adds no extra semantic meaning. The schema covers 100% of the parameters, making the description's lack of param details acceptable.
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 uses the specific verb 'reply' and identifies the resource: a comment on one of the company's posts. It clearly states the tool's function, but does not explicitly contrast it with sibling tools like personal_comment_as_admin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. The description does not mention prerequisites, exclusions, or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and possible side effects (openWorldHint=true), but the description adds no additional context about overwriting existing images, authentication needs, or validation behavior.
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 a single, front-loaded sentence that conveys the core purpose without unnecessary detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema is descriptive, but for a mutating write operation the description could mention that uploading a new image replaces any existing one. It's adequate but not thorough.
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%, so the schema already documents logo_path, banner_path, and company_id. The description adds no extra meaning beyond what the schema provides, hence the baseline score of 3.
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 clearly states the action (upload) and the resource (logo and/or banner image for the page), making its purpose distinct from sibling tools like company_edit_about or company_update_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. Usage is only implied by the tool's name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, so the write nature is known. The description adds 'future date/time' which overlaps with the schema's scheduled_at_iso description. No additional behavioral context (e.g., scheduling constraints, editability after scheduling) is given beyond what annotations and schema already convey.
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 a single, well-formed sentence with no filler. It front-loads the action and time qualifier, making it immediately scannable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, presence of an output schema, and comprehensive param descriptions, the description is largely sufficient. It conveys the core behavior (scheduling) without needing to explain return values. A slight gap is the lack of workflow context (e.g., that this is for scheduling rather than immediate posting), which is inferred from the name.
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 schema covers 100% of parameters with descriptions, including detailed constraints for scheduled_at_iso (10-minute minimum, 3-month maximum). The tool description itself adds no parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 'Publish a post at a future date/time.' clearly identifies the action (publish) and resource (post) with a specific temporal qualifier. It distinguishes from immediate posting tools like company_create_post by the 'future' aspect, though it doesn't explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. The 'future date/time' phrasing implies scheduling usage, but there is no explicit instruction, exclusion, or comparison with company_create_post or company_list_scheduled. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false already signaling a write operation, the description adds important nuance by specifying 'replace' rather than 'update', indicating that the entire About section is overwritten. However, it doesn't disclose additional behaviors like validation, irreversibility, or side effects.
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 a single sentence with no filler, effectively communicating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema covers parameters and output. However, the lack of usage guidelines and minimal behavioral disclosure makes it slightly less complete for an AI agent that needs to decide when to invoke it.
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?
Both parameters are fully documented in the input schema (100% coverage). The description doesn't add parameter-level information, but given the schema's completeness, this is acceptable.
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 states the verb 'replace' and the resource 'company page About section', making the purpose obvious. It doesn't explicitly contrast with sibling tools like company_update_details, but the specificity about the About section provides adequate differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as company_update_details. There's no mention of prerequisites, required permissions, or scenarios where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which cover the safety profile. The description adds minimal extra context ('from the analytics page') but does not disclose additional behaviors like pagination or data aggregation. It is consistent with annotations, so no contradiction.
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 a single, efficient sentence ('Read metric cards from the analytics page.') that clearly communicates the core function with no wasted words. It is front-loaded with the verb and object, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, strong schema documentation (100% parameter coverage), an output schema, and read-only annotations, the description is largely sufficient. The only shortcoming is the lack of usage guidance, but the combination of description and schema covers what the tool does and how to call it.
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% for both parameters (company_id and scope). The description adds no additional parameter information beyond what the schema already provides, so a baseline of 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 uses a specific verb ('Read') and resource ('metric cards from the analytics page'), making the tool's function immediately clear. It distinguishes itself from sibling tools like company_list_posts or company_list_followers by focusing on aggregated analytics metrics rather than raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as company_list_posts or company_list_followers. The scope parameter in the schema hints at some flexibility, but the description itself does not explain preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to cover safety. It adds the nuance that only 'published' posts are listed, but does not mention pagination, ordering, or any other behavioral details.
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 a single concise sentence that is front-loaded with the primary action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full input schema, an output schema, and annotations, the description is sufficient for a simple list operation. However, it lacks usage guidelines and any mention of the max_posts cap, though the schema covers that.
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%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema provides.
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 clearly states the action ('List'), the resource ('posts'), and the scope ('published by the company page'). This distinguishes it from sibling tools like company_list_followers or company_list_mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives, no prerequisites are mentioned, and there are no exclusions or conditions. The description only states what the tool does without contextualizing its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and openWorldHint=true, and the description's 'publish' aligns with these. It adds that the post is a text post destined for a company page, but does not disclose additional behaviors such as moderation, error conditions, or immediate visibility.
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 a single concise sentence that immediately conveys the core action. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple create operation, full schema parameter descriptions, and the presence of an output schema, the description is minimally sufficient. However, it lacks context about how this differs from company_schedule_post and does not mention any side effects or prerequisites beyond what annotations provide.
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?
All four parameters have descriptions in the schema (100% coverage), so the description does not need to explain them. It does not add any parameter-specific context beyond what the schema already provides.
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 uses the specific verb 'publish' and identifies the resource as 'a text post to the company page'. This clearly differentiates it from sibling tools like company_edit_post, company_delete_post, and company_schedule_post, which have distinct actions.
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 implies this tool is for immediately publishing a text post, but it does not explicitly contrast with company_schedule_post or other alternatives. No exclusions or alternative recommendations are provided, leaving the agent to infer usage based on the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation (listing is a read operation) and adds the word 'current' to suggest real-time data. However, it does not provide additional behavioral detail such as pagination, authorization requirements, or what 'admins' includes, leaving most transparency to the annotations.
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 one short, front-loaded sentence with no redundant words. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with an output schema present and a single obvious parameter, the description is largely complete. It could benefit from a note about what constitutes an 'admin' or any incidental limitations, but given the tool's simplicity, the description covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (company_id) with 0% schema description coverage, yet the description does not mention what this parameter means or how to use it. The parameter name is self-explanatory to a degree, but the description fails to explicitly link it to the action, leaving the agent to infer from naming conventions.
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 clearly states the action ('List') and the resource ('current admins of the page'), which is specific and distinct from sibling tools like 'company_list_posts' or 'company_list_followers'. The verb+resource combination unambiguously differentiates its purpose.
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 implies usage ('use when you need to see page admins') but provides no explicit guidance on when to prefer this tool over alternatives or any context about exclusions. It lacks the explicit 'when/when-not' that would earn a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and open-world side effects (openWorldHint=true). The description adds that it replaces only the body of an existing post, which is useful scoping, but it does not disclose side effects such as irreversibility, permission needs, or what happens to other post attributes. No contradictions with annotations.
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 a single tightly worded sentence: 'Replace the body of an existing company post.' It front-loads the action and object with no filler, making it immediately scannable and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema covers all parameters, an output schema exists, and annotations define the safety profile, the description is adequate for a simple field-replacement tool. It could mention that the entire body is overwritten, but 'replace' already conveys that. It lacks constraints like text length limits, but these are not essential for initial invocation.
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?
Input schema coverage is 100%; each parameter (company_id, post_urn, new_text) has a description. The tool description does not add additional parameter meaning beyond what the schema already provides, and the schema’s reference to company_list_posts for post_urn is more informative. 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 states a specific action ('Replace the body') and a clear resource ('an existing company post'), which distinguishes it from sibling tools like company_create_post, company_delete_post, and company_update_details. The focus on 'body' clarifies that it is a targeted edit rather than a general post update.
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 implies the tool is for editing an existing post's body, but it does not explicitly say when to use it over alternatives or when not to use it. The parameter description for post_urn references company_list_posts, providing a workflow hint, but the main description lacks direct comparatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false) and openWorldHint=true. The description adds no extra behavioral context such as permission requirements, side effects, or reversibility, relying entirely on the schema for parameter meanings.
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 a single sentence with a clear verb and object, front-loaded with the core action. It contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with 100% schema coverage, an output schema, and annotations covering mutation, the description is adequate. It lacks explicit alternatives and side-effect disclosure, but the structured data fills most gaps, making it nearly complete.
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 schema fully documents all three parameters, including company_id's validation purpose and thoughts_text being optional. The description's mention of 'commentary' aligns with the schema but adds no new information beyond what is already provided.
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 clearly states the action (reshare), the target (company page), and the optional commentary. It distinguishes from sibling tools like personal_reshare_company_post by specifying the company page as the destination, and from company_create_post by focusing on resharing an existing post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to reshare another post on the company page with optional commentary. It does not explicitly mention alternatives or exclusions, but the action is specific enough to differentiate from creating posts or sharing to personal pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety expectations. The description adds no extra behavioral context (e.g., pagination, output format), but does not contradict annotations. With annotations present, a baseline score of 3 is appropriate.
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 a single, clear sentence with no wasted words. It is appropriately sized for the tool's simplicity and front-loads the essential verb and resource.
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?
Given the tool's simplicity, the presence of an output schema, comprehensive annotations, and full schema coverage for parameters, the description is complete for its purpose. It requires no additional detail about return values or behavior since these are covered by structured data.
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% for both parameters (company_id and max_results), so the schema fully documents them. The description itself provides no additional parameter semantics beyond what the schema already states, yielding the baseline score of 3.
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 uses a specific verb ('List') and resource ('followers of the company page'), clearly distinguishing it from sibling tools like company_list_posts or company_list_mentions. It unambiguously identifies the tool's function.
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 implies usage by stating the action, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context is clear enough for a simple read operation, but it lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint=false annotation by explaining the underlying UI mechanics: no dedicated URL, no exposed URN, stable 0-based indices, and display datetime parsed from aria-label. It also discloses that cancellation uses the 'Delete post' action. This provides valuable behavioral context for operating correctly.
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 two succinct sentences: a clear purpose statement followed by a focused paragraph on necessary technical context. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool interacts with a non-standard dialog UI, and the description provides essential details about lack of URNs and index-based row handling. The output schema presumably covers the returned list. It could mention admin-level prerequisites, but the phrase 'admin page-posts screen' implies this. Overall, it is sufficiently complete.
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 provides detailed descriptions for both parameters, with cancel_index explaining its 0-based index, cancellation behavior, and read-only omit. The description text does not add additional parameter-specific meaning, but the 100% schema coverage means it does not need to.
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 clearly states the tool lists posts queued for future publication and optionally cancels one. This distinguishes it from sibling tools like company_list_posts (which lists posts generally) and company_delete_post (which would require a URN that this tool notes is not exposed).
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 implies usage for managing the scheduled queue by explaining the dialog-based UI and row identification, but it does not explicitly contrast with alternatives or state when not to use it. The technical context (no URN, index-based) hints at why this tool is needed, but lacks direct 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and openWorldHint=true. The description adds the 'first match' assembly behavior, which is useful, but it does not disclose potential side effects, authentication requirements, or fate of the published post. This is more than a tautology but still limited.
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 two sentences, front-loaded with the main purpose and then a compact template. There is no fluff or redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only three simple parameters, the description captures the essential behavior including the 'first match' nuance. It does not mention prerequisites like an active session, but given the sibling tools (session_status, session_warmup) and the low complexity, this is a minor gap rather than a critical omission.
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 coverage is 100% with clear parameter descriptions. The description's template ('<lead_text>@<company>[first match]<trailing_text>') reinforces the role of each parameter but does not add meaning beyond what the schema already provides. 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 states a specific action ('Publish a personal post mentioning your company page') with a clear verb and resource. It distinguishes from siblings like company_create_post and personal_reshare_company_post by focusing on tagging/mentioning a company in a personal post, and the assembly template further clarifies the exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to publish a personal post that mentions a company. It does not explicitly contrast with alternatives or state when not to use it, but the use case is evident from the first sentence. No exclusions are provided, so it falls between 'implied usage' and 'clear context'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, correctly aligning with the 'Share' action. The description adds that the share goes to the personal profile, but does not disclose potential side effects like visibility or permission requirements. With annotations covering the safety profile, this level of detail is acceptable.
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 a single, focused sentence with no redundant information. It efficiently communicates the core purpose.
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?
The tool is simple with only 2 parameters, full schema coverage, and an output schema present. The description, combined with the structured fields, provides complete context for correct invocation.
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%, with source_post_urn clearly described as coming from company_list_posts and thoughts_text as optional commentary. The description itself adds no parameter details, so 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 clearly states the action 'Share a Company Page post onto the signed-in user's profile', specifying both the resource (company post) and the destination (personal profile). This distinguishes it from the sibling 'company_reshare_post' which targets the company page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the context of use by specifying 'onto the signed-in user's profile', which implies a distinction from company-level resharing. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal non-read-only, but the description adds valuable runtime behavior: the tool sends up to max_invites, stops when the quota is reached, and handles the LinkedIn error banner gracefully. This is beyond annotation metadata and informs the agent of expected side effects and termination conditions.
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?
Two sentences front-load the core action and then succinctly state the quota constraint and stopping behavior. Every sentence carries critical information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a fully documented schema and an output schema, the description covers purpose, quota, and failure behavior. It lacks details on partial failures for individual invites, but the output schema likely addresses that. Overall, it is complete enough for safe invocation.
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 covers 100% of parameters with detailed descriptions, including the default for max_invites. The tool description reinforces this but does not add new semantic information beyond what the schema already presents, so 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?
Description uses a specific verb ('Send follow invitations') and clearly identifies the target ('your 1st-degree connections'). It is distinct from all sibling tools, which focus on reading, posting, or admin management, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains the LinkedIn 250-invite monthly cap and the max_invites hard cap, giving clear context for when to use this tool and cautioning about quota limitations. It does not explicitly name alternatives, but none of the sibling tools provide the same functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint=false and openWorldHint=true annotations by revealing the identity selector flip behavior and the default of comment_as_company. This is valuable, but it doesn't disclose whether the identity flip persists after the call or other potential side effects.
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 extremely concise: two sentences that front-load the core action and then explain the key conditional behavior. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the main action and the identity switch. With an output schema present, return values need no explanation. Minor gaps like admin prerequisites are not stated, but the name and sibling context make them inferable.
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 descriptions are 100% covered, but the description adds critical meaning for comment_as_company by explaining the default and its consequences. It also clarifies that company_id is used to locate the identity selector, augmenting the schema's own description.
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 clearly states the action: 'Post a comment on a company post' and specifies the optional identity behavior. This distinguishes it from sibling tools like company_reply_comment (which replies to existing comments) and personal_tag_company (which tags a company).
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 implies usage by describing what the tool does, but it doesn't explicitly state when to use it over alternatives or exclude other comment-related tools. There is no mention of prerequisites like admin rights or when to choose comment_as_company=False.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds useful behavioral details: it uses LinkedIn's ?editPage=true admin modal, the modal closes on navigation away, and it explicitly confirms 'no state is modified'. This provides context about the tool's mechanism and side-effect-free nature, going beyond the annotations' basic safety profile.
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 extremely concise: two sentences, no filler. It front-loads the core purpose, then provides a compact explanation of the technical mechanism and safety. Every sentence contributes meaningful information, and the structure is easy to parse.
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?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is complete. It lists the major fields returned, explains the source (admin modal), and explicitly states that no state is modified. This is fully adequate for an agent to decide to use the tool and understand its behavior.
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 describes the single parameter (company_id) with examples and accepted formats, so the description adds no extra semantic meaning. With 100% schema coverage, the description correctly relies on the schema and does not need to repeat parameter details.
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 clearly states the action ('Read every structured field') and the resource ('company page'), using a specific verb and a defined scope. It distinguishes itself from sibling tools like company_edit_about or company_list_posts by emphasizing that it reads all structured fields at once, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it is the only place that exposes name, tagline, description, website, industry, size, type, phone, and founded year all at once. While it doesn't explicitly name alternatives or exclusions, the 'only place' phrasing gives a strong usage signal and distinguishes it from write or listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: it scans the recent activity page, matches company name as a mention link, and implies case-insensitive body matching (also present in schema). No contradictions with annotations, and the added mechanism aids correct mental modeling.
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, front-loaded with the core action, and every sentence contributes value—purpose, mechanism, and use case. No wasted words or redundant restatements of the tool name.
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?
Given the tool's simplicity, two well-documented parameters, an output schema, and read-only annotations, the description is complete for an agent to select and invoke it correctly. It also distinguishes itself from sibling tools by emphasizing 'personal posts' and 'company mention link'.
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 coverage is 100%, so the schema already documents both parameters clearly (company_name with case-insensitivity, max_results as a cap). The description adds only marginal context ('mention link', 'employee-advocacy') beyond the schema, aligning with the baseline of 3 for high schema coverage.
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 uses a specific verb-resource pair ('List personal posts that tag the given company page') and clearly distinguishes from siblings like company_list_mentions by scoping to the personal timeline. It also states the underlying mechanism (mention link in body), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool ('Useful to locate employee-advocacy posts for response/engagement'), implying a read/search scenario. It does not explicitly name alternative tools or exclude cases, but the context is sufficient for a focused personal-timeline read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses that the operation is irreversible, that LinkedIn offers no trash/restore mechanism, and includes an implementation note about using page.evaluate to bypass Playwright actionability checks, referencing the root cause. This adds significant behavioral context that annotations alone do not provide. No contradiction exists.
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 front-loaded with the core action, followed by a critical warning and an implementation note. Every sentence earns its place, with no redundant or filler content. The structure is clear and easy to scan.
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?
Given the complete schema (2 fully described parameters), an output schema, and strong annotations, the description adds complementary details: irreversibility, platform limitations, and a technical caveat about the click sequence. This covers the key behavioral aspects and is fully complete for a delete operation.
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 describes both parameters (post_urn and company_id) with 100% coverage, including a note that post_urn comes from company_list_posts. The description adds no additional parameter-level meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Permanently delete a company post,' providing a specific verb and resource. It clearly differentiates from sibling tools like company_edit_post or company_create_post by emphasizing the delete action and permanence. No ambiguity remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: this tool is for permanently deleting a company post, with explicit irreversibility. It does not name alternative tools or provide exclusions, but the highly specific purpose makes the usage context obvious. A direct comparison to alternatives would be the only missing element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations: 'Fields not passed are left as-is on LinkedIn' clarifies the partial-update semantics. The annotations only indicate readOnlyHint=false and openWorldHint=true, so the description enriches transparency without contradicting them.
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 two sentences, front-loaded with the action and resource, and every sentence adds value. No fluff or repetition of schema details.
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?
Given the rich input schema (100% coverage) and presence of an output schema, the description sufficiently covers the essential: what the tool updates and the partial-update behavior. No critical gaps remain for effective use.
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%, providing baseline 3, but the description adds crucial meaning: 'All arguments are optional; supply only the fields you want to change' clarifies how the nullable parameters and defaults should be interpreted. This goes beyond the schema's field-level descriptions.
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 uses a specific verb 'Update' with a clear resource ('the page's website, industry, size bracket or specialties'), which precisely defines the tool's purpose. It distinguishes from sibling tools like company_read_page or company_edit_about by enumerating the exact fields it modifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the scope of use ('website, industry, size bracket or specialties') and provides partial update guidance ('All arguments are optional; supply only the fields you want to change'). It does not explicitly mention alternatives or when not to use, but the field list implicitly differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context beyond that: 'it does NOT open the browser or hit LinkedIn' and is a 'fast local check.' This tells the agent about side-effect-free execution and performance characteristics, which readOnly alone does not guarantee.
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?
Two concise sentences, front-loaded with the core purpose, followed by a relevant caveat and use case. Every sentence earns its place with no redundancy.
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 no-parameter tool with an output schema and read-only annotations, the description fully covers purpose, usage, and behavioral traits. It is complete enough for an agent to decide whether to invoke it and what to expect.
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?
The tool has zero parameters, so the input schema is trivially complete. Per rubric, baseline is 4 for 0 params; the description appropriately adds no parameter details since none exist.
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 clearly states the tool's function: 'Report whether a persistent LinkedIn profile is present.' This is a specific verb ('report') and resource ('persistent LinkedIn profile'), and it distinguishes this session-status tool from siblings like session_warmup and session_logout by focusing on the presence check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use: 'Useful to decide whether a ``--login`` step is required.' It also notes this is a 'fast local check' that does not hit LinkedIn, implying alternatives like session_warmup are for actually establishing a session, though no sibling is explicitly named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by disclosing the actual behavior (launching a browser, navigating to a specific URL) and the return value (current LinkedIn URL and success flag). This goes beyond what the annotations provide, though it does not cover failure modes or side effects beyond the read-only guarantee.
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 two sentences, front-loaded with the action, and then a usage note. Every word earns its place. No fluff.
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 zero-param tool with good annotations and an output schema, the description covers purpose, usage context, and return value. It is complete for an agent to select and invoke correctly.
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?
No parameters exist (schema coverage 100% and param count 0). The baseline for zero-param tools is 4, and the description correctly makes no parameter claims. Nothing to add.
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 clearly states the specific actions: 'Launch the browser, navigate to /feed/, confirm authentication.' This distinguishes it from siblings like session_status (which likely only checks status) and session_logout (which ends the session). The verb 'warm up' is clarified with concrete steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call this after --login to verify the session works before running other tools.' It does not explicitly mention when not to use or name alternative tools, but the context is clear enough for an agent to sequence this correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds critical behavioral details: what is deleted (profile directory), that it is local, that cookies remain valid server-side, and that re-login is required. This fully discloses the side effects and scope of the operation.
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 concise (three sentences) and well-structured, with the key action front-loaded in the first sentence. Each subsequent sentence adds necessary context: local scope, server-side behavior, and recovery. No wasted words.
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?
Despite being a simple tool, the description fully covers the essential context: what is destroyed, what is preserved, and how to reverse the action. The existence of an output schema and absence of params reduces complexity, but the description still addresses all relevant aspects.
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?
With zero parameters, the schema already provides complete coverage. The description naturally does not add parameter details, but the baseline for zero params is 4, and the description effectively communicates the operation without needing param-specific semantics.
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 states a specific verb ('Wipe') and resource ('persistent browser profile'), clearly indicating the tool's function. It distinguishes itself from siblings by emphasizing the local profile deletion and forced re-login, unlike session_status or session_warmup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (to log out locally) and what it does not do (does not sign out on LinkedIn's side). It also provides a recovery instruction ('Run --login to sign in again'), which serves as an alternative. However, it does not explicitly compare to sibling tools, so a slight deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![linkedin-company-admin-mcp MCP server](https://glama.ai/mcp/servers/negrueu/linkedin-company-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/negrueu/linkedin-company-admin-mcp)

Score Badge

Copy to your README.md:

[![linkedin-company-admin-mcp MCP server](https://glama.ai/mcp/servers/negrueu/linkedin-company-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/negrueu/linkedin-company-admin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/negrueu/linkedin-company-admin-mcp'

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