LinkedIn MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct resource/action combination. The prepare/execute pairs are clearly separated by their non-mutating vs mutating roles, and search/get/list tools have well-defined boundaries. No two tools appear to perform the same operation.
Naming Consistency5/5All tools follow a consistent 'linkedin.<domain>.<action>' or 'linkedin.<domain>.<subresource>.<action>' pattern with snake_case and standard verbs (get, search, list, prepare, execute). This makes the tool surface predictable and easy to navigate.
Tool Count4/531 tools is on the heavy side, but the breadth of LinkedIn's platform (posts, jobs, people, companies, invitations, connections, messaging, plus server metadata) justifies the count. Each tool has a clear purpose, and the prepare/execute pairs account for many of the tools without redundancy.
Completeness4/5The set covers the core LinkedIn workflows: reading/searching across major resources, and performing key mutations (create post, comment, react, send/accept/ignore invitations, message). Notable gaps include post deletion/editing and job application, but these are workaround-able for most agent use cases.
Average 4.2/5 across 31 of 31 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 82 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful context about 'current visible' (implying hidden/inactive jobs may not be retrievable) and what is included in the response. However, it does not disclose error behavior or authorization requirements beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Read one current visible LinkedIn job by numeric ID') and continues with a clear list of what is included. Every phrase earns its place with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a rich output schema and strong annotations, so the description does not need to explain return values in detail. It covers the main data components and the visibility constraint, but the lack of context_id/request_id explanation is a notable gap. Given the required nature of these parameters, a more complete description would address them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries full responsibility for explaining parameters. It explains that job_id is a numeric ID, but context_id and request_id are completely unexplained. The description fails to clarify their purpose, leaving a significant semantic gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific LinkedIn job by numeric ID, and enumerates exactly what is included (header metadata, application method, hiring-team identities, About section). This distinguishes it from sibling search tools like linkedin.jobs.search, which find jobs rather than fetch one by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a numeric job ID and need detailed job information, but it does not explicitly contrast with siblings like linkedin.jobs.search or state when NOT to use this tool. There is no mention of alternatives or exclusions, leaving the agent to infer the right 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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context by mentioning it hydrates LinkedIn's virtualized result cards, deduplicates results, and returns a cursor page, which are not obvious from the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence with a dense list of filters. It front-loads the core purpose but becomes somewhat unwieldy. It could be better structured by separating the action from the parameter list, yet it remains readable and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested filters, pagination, many enums), the description covers the essential workflow: searching visible pages, applying filters, hydrating cards, and returning a paginated deduplicated page. The existence of an output schema reduces the need to describe return values. It misses some details like session dependencies, but annotations and schema fill in much of the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (22%), so the description should compensate. It names many filter categories (keywords, location, Date posted, sorting, etc.) and clarifies certain parameters like 'typed location' and 'Date posted' mapping to location and freshness_hours, but it does not explain cursor, page_size, context_id, request_id, or detailed semantics for each filter. Partial compensation, not full.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches LinkedIn Jobs pages with a specific verb ('Search') and resource ('LinkedIn Jobs'). It lists numerous filter categories and notes it returns a deduplicated cursor page, distinguishing it from other tools like linkedin.jobs.get or linkedin.people.search by scope and behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (searching jobs with optional filters) but provides no explicit guidance on when to use this instead of alternatives, no exclusions, and no mention of prerequisites or session requirements. The sibling tools like linkedin.jobs.get signal a complementary role, but the description does not state this relationship.
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 meaningful behavioral detail beyond the annotations: it opens a visible conversation, uses the exact profile Message button or Messaging href, creates an immutable draft, hash-locks attachments, allows exactly one KLIPY GIF, and optionally a reply_to_message_ref. These complement the idempotentHint and destructiveHint=false without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description packs substantial detail into three sentences. The first sentence is a long, convoluted run-on that is hard to parse, though it is front-loaded with the core action. The following two sentences are clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 9-parameter tool with zero schema descriptions, the description covers behavioral constraints and exclusions well, and an output schema exists so return values need not be explained. However, key parameters like context_id and request_id are left unexplained, and the interplay between profile_slug, conversation_id, and conversation_ref is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description references message, gif, attachments, and reply_to_message_ref conceptually but does not clearly explain the mandatory context_id, request_id, or the conversation/profile identifiers (profile_slug, conversation_id, conversation_ref). This leaves the agent to guess at crucial routing and correlation parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a one-to-one conversation and creates an immutable draft, explicitly noting it does not send. It distinguishes itself from the sibling execute tool by saying 'This does not send the message' and lists excluded conversation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to prepare but not send a message, with explicit exclusions (group chats, message requests, paid InMail). It implies the companion execute tool for sending, though it doesn't name it directly or provide a formal when/when-not split.
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 readOnly, idempotent, non-destructive. The description adds the specific behavior of 'Always captures exactly the Company overview and About page' and enumerates the precise fields captured, including 'exact field evidence.' This goes beyond annotations by telling the agent what to expect in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that leads with the primary action and resource, then lists captured fields. No redundant or filler content—every phrase contributes meaning. The structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clearly defines the data scope and benefits from output schema and annotations. However, the lack of explanation for context_id and request_id makes it incomplete for invocation purposes, and there is no mention of error handling for non-visible companies. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 1 of 3 parameters (company_slug) has a description in the schema, and the tool description only explains the slug. The required context_id and request_id parameters are undocumented in both the schema and description, leaving agents without guidance on how to populate them. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Read' with a specific resource 'LinkedIn Company' and clearly identifies the exact scope: by public slug, capturing the Company overview and About page. This distinguishes it from sibling search tools like linkedin.companies.search, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need a specific company's overview and About page using its public slug. It does not explicitly mention when not to use it or name alternatives, but the contrast with search tools is implied via 'exact' and 'slug'. Lack of explicit exclusion keeps it a step below perfect.
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?
The description goes well beyond the annotations by disclosing the account-changing nature, immutability, server verification steps (preview, payload and asset hashes, draft expiry, recipient, idempotency), and the exact visible outgoing postcondition. This adds critical context that destructiveHint and idempotentHint only hint at, with 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at around 70 words, front-loading the safety warning before the functional description. The final long sentence is dense but packs relevant detail without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior, approval requirements, and verification steps in a way that is largely complete for an execute tool. Since an output schema exists, explaining return values is unnecessary. It lacks explicit linkage to the prepare sibling, but the context is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (action_id and payload_hash have descriptions). The tool description mentions concepts like preview, payload hashes, and idempotency, but does not map them to parameters or explain the purpose of context_id, request_id, idempotency_key, or approval_preview. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as sending a LinkedIn message with the specific verb 'Send' and resource 'prepared LinkedIn message' in the title. It further specifies 'exactly one immutable text/file message or immediate-send GIF' and distinguishes itself from siblings by focusing on the execute step after preparation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly conditions invocation on approval policy ('Invoke only when... authorizes') and defaults to interactive confirmation, providing clear authorization guidance. However, it does not explicitly reference the prepare tool (linkedin.messaging.message.prepare) or state when not to use this tool versus alternatives; the connection to preparation is implied rather than stated.
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, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond annotations: pagination ('one cursor page'), visibility scope ('visible'), and the explicit non-search behavior, which helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry all key information without redundancy. The purpose and primary behavior are front-loaded, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description is fairly complete: it defines the resource, pagination, visibility, sort behavior, and exclusions. It falls short only in not naming the search alternative and offering little help for required parameters, but overall the context is solid for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate, but it does so minimally. It mentions 'cursor page' (cursor) and 'sort order' (sort_by), yet leaves required params (context_id, request_id) and page_size semantics unexplained. The description does not provide enough parameter-level meaning for such low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('first-degree connection inventory') while also stating its scope ('visible', 'selected visible sort order'). It explicitly distinguishes itself from the search tool by saying 'This tool does not search,' which is a strong differentiator given the sibling tool 'linkedin.connections.search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'This tool does not search' provides an exclusion that signals when not to use this tool, but it does not explicitly name the alternative ('linkedin.connections.search'). It also implies pagination usage with 'one cursor page,' giving some contextual guidance for iterative fetching.
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 valuable behavioral context beyond the annotations: the draft is 'immutable', and the output is 'the exact client-approval preview'. It also reinforces the non-sending nature. With annotations already indicating idempotent and non-destructive, these additions are meaningful and do not contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and critical exclusions. Every clause earns its place: 'Inspect one exact visible profile' establishes scope, 'immutable invitation draft' sets expectations, 'does not send' is a crucial differentiator, and the note length and preview mention are concise and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the prepare/execute pattern and the presence of an output schema, the description covers the essential aspects: it says what it inspects, what it creates, what it does not do, and what the output will be ('client-approval preview'). It does not mention prerequisites beyond visibility, but the sibling list and clear naming fill some gaps. Overall, it is complete for this moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all parameters. It only hints at 'note' (optional personalized note with 200-char limit) and 'profile' (visible profile), but leaves context_id and request_id entirely unexplained. The schema provides only titles and constraints, no descriptions, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as preparing (not sending) a LinkedIn connection invitation. It distinguishes itself from the sibling 'linkedin.invitations.send.execute' by explicitly stating 'This does not send the invitation.' The verb 'create' and resource 'invitation draft' are specific and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it operates on 'one exact visible profile' and produces a draft for later approval. It explicitly excludes sending ('does not send the invitation'), which differentiates it from the execute tool. However, it does not explicitly name alternatives or state when to prefer this tool over others.
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 discloses a non-obvious side effect: 'Opening a conversation may cause LinkedIn to mark it seen,' which aligns with readOnlyHint=false. It also promises explicit history completeness and truncation evidence, adding behavioral context beyond the annotations, which already note idempotency and non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler; the core read action and acceptable identifiers are front-loaded. The term 'reverse-virtualized' is jargon but purposeful, and each sentence adds real value: what it does, what it returns, and a side-effect warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers identifiers, return evidence, and the seen-marking side effect. Since an output schema exists, return-value details are not required. Remaining gaps include the nature of required context_id/request_id and guidance on how to choose among the three lookup routes, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies profile_slug, conversation_id, and conversation_ref, but leaves context_id, request_id, and max_messages unexplained. max_messages is self-evident from its name, but context_id and request_id remain opaque, limiting the compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reads LinkedIn conversation history, enumerating content types (messages, attachments, replies, edits, and reaction summaries) and clearly distinguishes itself from siblings by focusing on a single conversation. It also references messaging.search as the source of conversation_refs, differentiating the tool's role in the messaging workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains how to target a conversation (profile slug, visible conversation ID, or conversation_ref from messaging.search), which gives practical selection context. It doesn't explicitly say when not to use this tool, but the phrase 'conversation_ref returned by messaging.search' implies a search-then-read workflow that helps route usage.
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 readOnly/openWorld/idempotent/non-destructive behavior. The description adds valuable context beyond this: results are limited to 'visible' LinkedIn data, only one cursor page is returned, and name-to-ID resolution plus traversal safety bounds are intentionally private. This gives the agent useful operational expectations without contradicting 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and efficiently packs a lot of filter information without redundancy. The first sentence front-loads the main action and capabilities; the second adds behavioral constraints. It is slightly dense but still concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large nested-filter schema and presence of an output schema, the description provides adequate context: it summarizes the full range of filter types, states pagination is limited to one cursor page, and discloses private resolution/traversal bounds. It does not fully explain cursor-based pagination flow or clarify deprecated parameters, but these gaps are partially covered by schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (13%), so the description carries more burden. It does add meaning by clarifying that the query accepts natural-language or Boolean keywords and that certain name fields are exact keyword filters. However, it omits important parameter details like the deprecated max_results alias, title_keywords semantics, and the distinction between IDs and names across the nested filters, leaving the agent to rely heavily on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Search visible LinkedIn People results') and enumerates a wide range of filter dimensions. It clearly distinguishes this from sibling tools like linkedin.people.get (retrieval) and linkedin.connections.search (connections-specific) by emphasizing network-wide people search with many filter types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what the tool does and notes that it returns one cursor page, which helps set pagination expectations. However, it does not explicitly state when to prefer this over alternatives like linkedin.people.get or linkedin.companies.search, nor does it mention any exclusions.
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 idempotent/non-destructive behavior, but the description adds critical context: it never publishes, never acts as a company Page, and captures detailed post settings and local asset hashes. It still does not disclose what happens if no active composer exists or whether the composer state is modified, but the non-publishing guarantee is a strong, non-obvious behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the core purpose and then efficiently enumerate supported content types, captured settings, and safety constraints. There is no filler, repetition of schema fields, or unnecessary explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with a large nested schema, the description covers content modes, captured settings, and the non-publishing guarantee, which is good high-level orientation. It omits the explicit prepare→execute workflow, prerequisites for the 'active personal member composer,' and the role of context_id/request_id, so it is not fully complete for correct invocation despite the output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 11% schema description coverage, the description must compensate, and it does summarize the content-mode alternatives and top-level options such as audience, group, comment control, brand partnership, collaborators, mentions, and schedule. It also adds the crucial hint that 'the content discriminator is mode, not kind.' However, it leaves context_id/request_id semantics, asset-ref derivation, and many nested constraints to the schema, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Inspect the active personal member composer and prepare one immutable post,' which names a specific action, resource, and non-publishing scope. It also enumerates supported content types and explicitly contrasts with the sibling execute tool by noting it never publishes, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames this as a preparation/inspection step and explicitly states it never publishes and never runs as a company Page, giving useful context for when to avoid it. It does not, however, explicitly name the paired posts.create.execute tool or spell out the exact sequence, so the guidance is clear but not fully explicit.
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 provide idempotentHint=true and readOnlyHint=false, which are broad. The description adds that the operation never changes the reaction and that the target state is immutable, which is more specific than annotations. Yet it does not disclose what other side effects preparation may entail (since readOnlyHint=false suggests some write), leaving a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and clear boundaries. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. The description is adequate for basic selection and invocation, but it omits the relationship to the execute step, prerequisites of 'visible post', and did not explain all required parameters. Still, it is mostly complete for a prepare tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameters. It covers desired_reaction by listing all valid values and post_ref as 'visible post', but context_id and request_id are not explained. Since these are required and likely serve idempotency/context purposes, the description fails to compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects the current reaction state on a visible post and prepares an immutable target state, explicitly listing all allowed values. It also distinguishes itself from the execute sibling by stating 'This tool never changes the reaction.' This is a specific verb + resource with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good context: it is for a single visible post, it captures the exact current state, and it prepares a target state. However, it does not explicitly mention when to use this instead of the execute tool or any alternative, though the statement 'never changes the reaction' implies it is a read-only/preparation step.
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 the tool read-only, idempotent, and non-destructive. The description adds the 'non-secret' disclosure, which is a useful behavioral constraint about response content. However, it does not disclose other behavioral traits beyond the annotations, which is acceptable for such a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action verb and contains no fluff. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a simple read-only purpose, the description provides enough context for an agent to select it correctly. The output schema is available to explain the return value, so no further description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain them. According to the baseline for 0-parameter tools, a score of 4 is appropriate. The description appropriately focuses on the output rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and clearly identifies the resource as 'server configuration and readiness metadata.' It distinguishes from sibling tools like session.status and capabilities.list by focusing on server-level metadata. The 'non-secret' qualifier adds clarity about the response contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance is provided. The purpose is self-evident from the name and description, implying it should be used to check server readiness, but it does not explicitly distinguish from related tools like session.status. This is adequate but lacks explicit alternatives.
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?
The description adds meaningful behavioral context beyond the annotations: it creates an 'immutable acceptance draft' and explicitly states that it does not accept the request. This clarifies side effects (no actual acceptance, no destructiveness) and complements the idempotentHint and destructiveHint annotations. No contradiction 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and immediately states the core action ('Revalidate... and create...'), followed by a clear clarification. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covered elsewhere. The description communicates the high-level purpose and non-acceptance behavior, which is sufficient for basic selection. However, the lack of parameter explanations and any mention of workflow sequencing (e.g., 'use this before accept.execute') leaves gaps for correct invocation, making it average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While it mentions 'member profile' and 'incoming-request controls', which loosely map to profile_slug and request_id, it does not explain context_id or explicitly describe what each parameter represents. The high-level phrasing does not give the agent enough guidance to correctly populate the three required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Revalidate the exact member profile's paired visible incoming-request controls and create an immutable acceptance draft.' It also explicitly differentiates from actual acceptance with 'This does not accept the request.' This makes it distinct from sibling tools like accept.execute and ignore.prepare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating what it does not do: 'This does not accept the request.' This signals that this is a preparation step and that a separate execute tool (e.g., accept.execute) is needed for actual acceptance. However, it does not explicitly name alternatives or provide specific 'use when' conditions, so it falls short of a full 5.
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?
The description adds significant context beyond annotations: it reveals that the tool validates the current visible request, creates an immutable draft, and most importantly does NOT perform the ignore action. This is critical for an agent to avoid mistakenly believing the request is handled after this call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and the crucial negative statement. Every word contributes to understanding; no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively conveys the prepare/execute distinction and non-destructive nature, and the output schema likely covers return values. However, the lack of parameter semantics and the absence of an explicit pointer to ignore.execute leave gaps for an agent trying to invoke all required arguments correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameter meanings. It hints at 'member profile' (likely profile_slug) and 'incoming connection request' (likely request_id), but does not map these explicitly, and context_id is entirely unexplained. The agent must rely on naming conventions and sibling patterns, which is unreliable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Revalidate', 'create') and clearly states the resource (incoming connection request) and the outcome (immutable ignore draft). It explicitly says 'This does not ignore the request,' distinguishing it from the sibling ignore.execute tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is a preparation step, and the explicit 'This does not ignore the request' sets a when-not boundary. However, it does not explicitly name the corresponding execute tool or state the exact sequence (prepare then execute), so it falls short of a full 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral details: it searches the 'current desktop inbox' and results are 'cursor-paginated current conversation cards', providing insight into pagination and response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and filters. Every word earns its place, with no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and an output schema, the description covers the essential aspects: search scope, available filters, required criterion, and pagination. The output schema likely explains the return format, so no additional detail is needed there. However, it could clarify the purpose of context_id and request_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, so the description partially compensates by explaining the category and filter values in prose. It also mentions 'recipient or message keywords' corresponding to the query parameter and 'cursor-paginated' for the cursor parameter. However, required parameters context_id and request_id are not explained, and the description does not fully map all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches the current desktop inbox by recipient or keywords, with optional category and filter parameters. It distinguishes itself from sibling search tools like linkedin.jobs.search and linkedin.people.search by explicitly targeting messaging conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what it searches (desktop inbox) and states the requirement that at least one search criterion is needed. It does not explicitly name alternatives or when not to use it, but the scope is unambiguous and separates it from other search 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 cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: it returns 'full retained text, field evidence, and bounded section-page coverage,' warning of potential limits. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and resource, then efficiently enumerates return contents without redundancy. Every clause carries meaning, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and strong annotations, the description sufficiently covers purpose, input, and return highlights. It doesn't address invalid/invisible profiles or the meaning of context/request IDs, but these are minor given the annotated hints and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, describing sections and profile_slug. The description adds that the slug is 'validated public' and that sections cover 'every visible profile section,' but it does not explain context_id/request_id semantics. This leaves the parameter guidance partially incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a LinkedIn member profile by public profile slug, with a specific verb ('Read') and resource ('LinkedIn member profile'). It lists detailed return contents (typed introduction, About, experience, education, all visible sections, full retained text, field evidence), distinguishing it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'directly by validated public profile slug' implies the agent must already have a profile slug, giving clear context for use. It doesn't explicitly name alternatives like linkedin.people.search, but the 'directly' wording sets it apart from search, providing adequate guidance without exclusions.
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 state read-only, idempotent, and non-destructive behavior. The description adds valuable beyond-annotation context: 'Returns one cursor page while browser traversal remains privately bounded' and 'Names resolve only through exact visible choices' disclose pagination, traversal limits, and name-resolution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences front-load the purpose and then add only operationally critical caveats (content type behavior, name resolution, cursor paging). There is no filler or repetition; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large filter surface, the description covers the key behavioral constraints agents need to know: pagination returns one cursor page, name resolution requires exact visible choices, and content type follows LinkedIn's single-choice control. The output schema handles return-value details, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (14%), and the description partially compensates by summarizing the filter categories and clarifying single-choice content type and exact-name matching. However, most parameter-level semantics are left to the schema; the description does not fully bridge the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and clearly identifies the resource ('visible LinkedIn content'), enumerating many filter dimensions. It distinguishes itself from sibling search tools (jobs, people, companies) by targeting posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies use cases by listing available filters (From-member/company, posted-by, mentioning-member/company, author-industry/company, etc.), giving agents a strong sense of when to invoke it. It does not explicitly name alternatives, but the sibling tool names make those obvious.
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 include readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true. The description adds meaningful context: it emphasizes the server-side verification steps (payload hash, draft expiry, idempotency, exact profile identity, request controls) and the post-condition (verify controls absent and profile shows first-degree connection). This goes beyond simply repeating 'account-changing' and adds concrete behavioral expectations. It does not fully detail all side effects of rejecting or forcing execution, but the description meaningfully supplements 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with front-loaded critical info ('Account-changing action. Invoke only when...'). Every sentence carries substantive guidance, but the phrasing is heavy and could be broken into clearer, more scannable sentences. It is not wasteful, but it lacks the crisp, two-sentence structure seen in the best examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 required parameters, rich schema definitions (including ActionApprovalPreview with nested payload types), and a detailed output schema. The description explains the execution flow and safety checks, and it covers important context like draft expiry and idempotency verification. However, it does not explain what the output schema return values mean or what happens when verification fails (error behavior). Given the rich schema already exists, the description is mostly complete, but the absence of failure-mode context leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 33% (2 of 6 parameters have descriptions: action_id and payload_hash, but those only say 'returned by the matching prepare tool'). The description adds context that the tool verifies a preview, payload hash, draft expiry, idempotency, profile identity, and request controls—which helps the agent understand what the parameters represent (context_id, request_id, approval_preview, idempotency_key). However, it does not map those concepts explicitly to each parameter name, so the agent still has to infer which field corresponds to 'preview' (approval_preview) and 'idempotency' (idempotency_key). This is a moderate supplement but not a full mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Accept exactly one immutable incoming-request draft...' and clearly distinguishes this execute tool from sibling tools (invitations.accept.prepare, invitations.send.execute, invitations.ignore.execute). The phrase 'Account-changing action' and 'Invoke only when...' pin down the exact operation and its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Invoke only when the MCP client's configured approval policy authorizes this exact execute tool' and contrast with 'Interactive confirmation is the safe default; an explicit durable per-tool approval may authorize unattended execution.' This directly guides when vs. when-not to use it, though it doesn't name an alternative tool by name, it clearly states the precondition and the safe default behavior.
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 cover read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context beyond that: it specifies the post must be 'visible', mentions 'bounded completeness coverage', and explains that reposts retain the wrapper and read the linked original as an additional bounded page. This gives the agent a clearer picture of what to expect without contradicting 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the primary action. The first sentence packs a lot of detail without being verbose, and the second sentence succinctly covers the edge case of reposts. Every phrase contributes meaning, with no filler or repetition of schema/annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description lists the major return categories (author/header, expanded text, links, media, reactions, visibility, timestamps, etc.) and covers repost behavior and bounded completeness. This is comprehensive for a read tool with readOnly and idempotent annotations. It provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only post_ref has a description). The description adds meaning for post_ref by explaining it can be activity, share, or ugc-post and is stable. However, it does not explain context_id or request_id, leaving those two required parameters without semantic guidance. The description adds some value but does not fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource ('Read one exact visible LinkedIn post'), and distinguishes this from sibling search tools by emphasizing 'one exact' and requiring a 'stable activity, share, or ugc-post reference.' It clearly lists the returned data types, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a stable post reference and need a single, detailed, visible post. It does not explicitly state exclusions (e.g., use search for lists) or name alternatives, but the schema's note that post_ref is 'returned by LinkedIn post search' provides clear context. The 'one exact' phrasing differentiates it from search and list 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 indicate read-only, idempotent, and non-destructive behavior. The description adds the valuable caveat that only non-secret state is returned, specifying what is not exposed. It also scopes the state to the configured account, providing context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Return non-secret browser-session state for the configured account.' It contains no redundant words and is immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only status tool with no parameters and an output schema. The description and annotations fully cover its behavior, purpose, and safety profile, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the description doesn't need to elaborate on parameter semantics. The baseline for no-parameter tools is 4, and the description provides sufficient clarity given the schema is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns non-secret browser-session state for the configured account, using a specific verb (Return) and resource (browser-session state). It distinguishes from sibling linkedin.server.status by focusing on account session rather than server status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for checking the account session, but it doesn't explicitly state when to use it or provide alternatives. There is no exclusion of similar tools like linkedin.server.status, so usage context is implied rather than stated.
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 cover read-only, idempotent, and non-destructive behavior. The description adds value by mentioning 'visible' results, filter-control name resolution, and the one-cursor-page return behavior, which are not deducible from 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, and every sentence contributes: scope, name/ID resolution behavior, and pagination. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested filters, 7 params) and presence of an output schema, the description provides sufficient context for correct invocation: filter surface, pagination, and name/ID behavior. Minor omissions like rate limits or result ordering do not detract from usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover individual parameters, but the description clarifies the important distinction between human-readable names (resolved via filter UI) and stable facet IDs, which is not fully explicit in the schema. This adds meaningful guidance despite the low schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') and resource ('visible LinkedIn Company results') and details the full filter surface, clearly distinguishing it from sibling search tools like people.search or jobs.search. The scope is explicit and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes clear context for when to use the tool: when a filtered company search is needed, including the option to use names or stable facet IDs. It does not explicitly name alternatives or state when not to use, but the context is strong enough to guide selection.
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, idempotentHint=true, and destructiveHint=false. The description adds behavioral nuance by stating the server enforces first-degree and that it wraps LinkedIn's current visible People surface, which clarifies the tool's limitations and connection to the UI.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with core purpose, then supported filters, then the distinguished alternative. Every sentence adds meaningful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and complexity, the description covers the key aspects: scope, enforced degree, supported filters, and the alternative tool. Output schema exists, so return values are documented elsewhere. It lacks minor details like pagination behavior, but those are in the schema. This is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (13%), so the description must compensate. It lists the categories of supported filters and keyword types, giving an overview of parameters. However, it doesn't explain the structure of the filters object or specific parameter formats beyond what the schema already provides, so it adds some but not comprehensive value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches 'the configured account's established first-degree connections' via LinkedIn's People surface, using a specific verb and resource. It also explicitly contrasts with linkedin.people.search, which handles broader degree discovery, making the purpose distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: when to use this tool (searching first-degree connections) and when to use the alternative (linkedin.people.search for broader degrees). It also notes that the server always enforces first degree, informing the agent of a constraint.
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?
The description discloses account-changing behavior beyond annotations, including 'immutable', 'exactly one', and the verification steps (preview, actor, target author, payload, local asset hash, expiry, idempotency). It also explains approval default vs. durable approval, providing actionable context not in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the critical 'Account-changing action' warning. Every sentence adds value—approval policy, verification, and immutability—without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description covers the essential behavioral safeguards and execution constraints. It could explicitly point to the matching prepare tool, but the schema and sibling context provide that linkage, so it remains complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It mentions verification of 'payload, local asset hash, expiry, and idempotency' which maps to payload_hash and idempotency_key, but it does not explain context_id, request_id, or approval_preview individually. Partial compensation at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Submit exactly one immutable personal-member top-level comment', which clearly states the tool's action and scope. It distinguishes itself from the sibling prepare tool by emphasizing execution and verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear when-to-use condition: 'Invoke only when the MCP client's configured approval policy authorizes this exact execute tool.' It also implies a prepare-then-execute workflow with 'after the server verifies the preview...', though it does not explicitly name alternatives or exclusions.
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?
Adds meaningful behavioral context beyond annotations: "Account-changing action," "exactly one immutable personal-post draft," and "An interrupted final action is never retried automatically." It also explains the verification process (hashes, preview, actor, expiry, options, idempotency key) and directly aligns with the idempotentHint and destructiveHint annotations without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, all dense with essential information. It front-loads the critical warning ("Account-changing action") and then efficiently covers approval, verification, and retry behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk execute tool, the description covers approval policy, verification steps, idempotency, and non-retry behavior. An output schema exists, so return-value documentation is not needed. The only small gap is that the description does not explicitly instruct the user to first call the prepare tool, though the title's "Prepared" and sibling tool naming provide that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only action_id and payload_hash have descriptions), so the description carries some weight. It mentions "preview, payload and asset hashes, actor, expiry, options, and global idempotency key," which gives high-level meaning to the parameters, but it does not provide per-parameter details or clarify the structure of approval_preview beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: "Publish or schedule exactly one immutable personal-post draft." The verb is specific, the resource is exactly defined as a prepared personal-post draft, and the description's account-changing warning distinguishes this from read-only tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit invocation conditions: "Invoke only when the MCP client's configured approval policy authorizes this exact execute tool." It also gives a strong default (interactive confirmation) and an exception (durable per-tool approval for unattended execution). It does not explicitly name the prepare alternative, but the title and schema parameter descriptions imply the prepare-then-execute flow.
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 read-only, idempotent, and non-destructive behavior, so the description adds the additional context that it reports per-capability runtime policy enablement. This is a useful behavioral detail beyond the annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that starts with the verb and resource, then immediately states the key output detail. Every word 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only list tool with an output schema, the description fully covers what the tool does. The annotations handle safety, and the output schema handles return values, so no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter details to add. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description sufficiently covers the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List), the resource (installed capabilities), and the specific output (whether runtime policy enables each one). This distinguishes it from all sibling tools, which target posts, jobs, people, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to check the availability and enablement of capabilities, making its usage context clear. However, it doesn't explicitly state when not to use it or mention alternatives, but the purpose is specific enough for correct selection.
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?
Adds substantial behavioral context beyond annotations: discloses it changes the account, requires approval confirmation, verifies preview/payload hash/expiry/idempotency/profile identity/request controls, and performs a fresh read to confirm controls absent. No contradiction with destructiveHint/idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense paragraph leads with the critical 'Account-changing action' warning, then approval conditions, then the exact behavior and post-verification. Every sentence adds necessary safety or operational detail with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive execute tool with output schema available, the description covers authorization, operational steps, verification checks, and post-action confirmation. It is complete enough for an agent to select and invoke it properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (descriptions for action_id and payload_hash). The description refers to the preview, payload hash, and idempotency checks, giving some meaning, but does not explain context_id, request_id, approval_preview structure, or idempotency_key semantics. Partial compensation for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Ignore exactly one immutable incoming-request draft'), names the resource (prepared LinkedIn connection request), and distinguishes it from sibling execute tools like accept/send by specifying the ignore operation. The phrase 'after the server verifies' ties it to the prepare step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States an explicit precondition: invoke only when the configured approval policy authorizes this exact execute tool, with interactive confirmation as the safe default. It implies this is the execution step after prepare (references preview/payload hash) but doesn't name alternatives or exclusion conditions, so not a full 5.
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?
Annotations already indicate read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral context about live pages, bounded rescanning, suppression of previously returned identities, and completion reconciliation—details that are not in the annotations and help the agent understand pagination consistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the main action. Although complex, every clause contributes useful information about pagination and deduplication. It is not overly long for the content, but could benefit from splitting into two sentences for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema, annotations), the description explains the core pagination and deduplication behavior well. The output schema fills in return structure, and the description covers the most important runtime semantics. Some parameter purpose is left implicit, but overall it is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the direction and invitation_filter parameters by referencing 'received or sent' and describing the union when filter is 'all'. While cursor and page_size already have schema descriptions, other parameters like context_id and request_id remain unexplained, so the description partially compensates for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read one live cursor page') and resource ('current received or sent invitation inventory'), and it distinguishes itself from sibling tools that send, accept, or ignore invitations. It also adds specific details about the 'deduplicated union' of views, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: to read received or sent invitations, and it explains the special behavior when invitation_filter is 'all'. However, it does not explicitly name alternatives or exclusions, though no sibling tool overlaps with listing invitations, so the guidance is adequate.
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?
Annotations already declare read-only, idempotent, and non-destructive semantics. The description adds substantial behavioral context beyond that: one-cursor-page pagination, bounded nested replies, stable references, exact author identities, and truncation coverage. This goes well beyond the annotation hints and helps the agent predict behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Read one cursor page') and then packs in necessary details. It is dense but information-bearing; no filler words. Slightly long but appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and helpful annotations, the description covers the essential aspects: pagination, ordering, field coverage, and limits. It doesn't mention error cases or authentication, but those are likely handled elsewhere. Overall, it is complete enough for a read-only list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, so the description must compensate. It does so implicitly by explaining the nature of the data ('one cursor page', 'relevant/recent ordering', 'bounded nested replies'), which clarifies the role of cursor, sort_by, and max_replies_per_comment. It does not explicitly name parameters but provides enough semantic context to infer their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('one cursor page of visible top-level comments and bounded nested replies'), clearly distinguishing it from sibling tools like comment creation or post retrieval. It also enumerates the exact data fields returned, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: it reads a page of comments with ordering, pagination, and bounded replies. However, it does not explicitly name alternative tools or specify when not to use it, so it stops 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the account-changing nature, the server-side verification checks (preview, actor, target author, prior state, expiry, idempotency), and the possibility of a safe no-op. This goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) by detailing what the tool does and what safety mechanisms exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no redundancy. The description front-loads the safety/approval warning and then delivers the core action in a compact, well-structured way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes execute tool, the description covers approval requirements, behavioral scope, server verification, and idempotency, while the output schema handles return values. An agent has sufficient information to safely select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not individually explain the six parameters. However, it does tie key execution concepts (preview, actor, idempotency, expiry) to the flow, adding modest semantic context beyond the schema. It does not fully compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: set, change, remove, or safely no-op a prepared LinkedIn post reaction after server verification. It distinguishes itself from the prepare sibling and other execute tools by emphasizing 'prepared exact reaction state' and the execute-only scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit invocation rule: only call when the MCP client's approval policy authorizes this exact execute tool, with interactive confirmation as the safe default and durable approval for unattended runs. While it doesn't name alternate tools, it gives clear when/when-not context via the approval gate and the prepare/execute split implied by 'prepared.'
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 annotations, the description discloses critical behaviors: it never submits, the comment is immutable, and only one exact visible post is inspected. It also constrains attachments (local hash-locked photo, exact visible GIF), which is highly informative. Annotation sets cover read-only/idempotent/destructive hints, and this description adds the crucial 'never submits' distinction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the core action, the second lists supported features and the decisive 'never submits.' Every sentence is meaningful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core capabilities, preconditions, and the non-submission behavior, making it sufficient for the tool's complexity. With an output schema present and annotations available, the lack of detail on context_id/request_id semantics is a minor gap but does not undermine overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no schema-level descriptions for main properties, the description compensates by mapping supported content types to the parameters: text, links, emoji, mentions, photo, or GIF. It also implies the post_ref requirement via 'exact visible post.' However, it does not explain the required context_id and request_id fields, which remain undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares an immutable top-level personal-member comment, with explicit enumeration of supported content types. The phrase 'This tool never submits' distinguishes it from the execute sibling and makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use it (prepare a comment) and when not to use it ('never submits'), but it does not explicitly name the alternative execute tool. The tool name and sibling list imply the correct counterpart, so guidance is clear though not fully explicit about alternatives.
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 annotations, the description adds critical behavioral details: the postcondition verification ('Pending is verified success and Connect is verified LinkedIn failure'), the immutable nature of the draft ('exactly one immutable invitation draft'), the list of server verifications (preview, payload hash, draft expiry, idempotency key, target identity, Send control), and the uncertainty handling for unreadable/ambiguous profiles. These go far beyond the annotations' flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about six sentences, each earning its place: a danger warning, approval policy, core action with verification list, postcondition interpretation, and edge case. It is front-loaded with 'Account-changing action' to immediately signal caution, and the structure progresses logically from conditions to outcomes without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—6 required params, approval interplay, and a separate output schema—the description covers the essential decision-making aspects: when to invoke, what the server verifies, the immutable send behavior, and how to interpret success/failure postconditions. The output schema exists to handle return values, so the description appropriately focuses on invocation and execution semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, but the description meaningfully explains the roles of key parameters by listing them as verification criteria: 'exact preview, payload hash, draft expiry, idempotency key, target identity, and actionable Send control.' This gives semantic context to action_id, payload_hash, idempotency_key, and approval_preview. However, context_id and request_id remain unaddressed, and the schema already describes action_id and payload_hash, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send exactly one immutable invitation draft after the server verifies...' This specifies the exact verb, resource, and the execution phase (as opposed to prepare). The title 'Send Prepared LinkedIn Connection Invitation' aligns, and the focus on 'execute tool' differentiates it from prepare and other invitation-related 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly conditions invocation on the configured approval policy ('Invoke only when the MCP client's configured approval policy authorizes this exact execute tool') and states that interactive confirmation is the safe default. It also implies the preceding prepare step ('after the server verifies the exact preview, payload hash...'), but does not name alternative tools or explicitly state when not to use it, leaving some room for improvement.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/prakharagarwal-dev/linkedin-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server