openlinkedinmcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes targeting different resources/actions (profiles, companies, jobs, messaging, feed). There is minor potential confusion between get_company vs search_companies, get_profile vs search_people, and follow_company vs follow_person, but the descriptions clarify the distinction between search vs direct access. The messaging tools (list_conversations, get_conversation, start_conversation, send_message) are well-separated by their distinct operations.
Naming Consistency4/5
The naming follows a strong verb_noun pattern throughout: get_*, search_*, create_*, follow_*, update_*, send_*, etc. A few slight deviations exist like linkedin_login, linkedin_auth_status, linkedin_logout (using the linkedin_ prefix rather than a verb_noun pattern) and navigate, screenshot_page, close_browser which don't follow the resource-targeting pattern, but the majority is highly consistent.
Tool Count3/5
36 tools is on the heavy end for a domain that could be consolidated. The server covers many sub-domains (profiles, companies, jobs, messaging, feed, notifications, auth), so the breadth justifies part of the count, but auth helpers (login, logout, auth_status) and utility tools (navigate, screenshot_page, close_browser) could arguably be grouped or reduced. Still, each tool serves a distinct function.
Completeness5/5
The tool surface is remarkably comprehensive for LinkedIn automation. It covers authentication lifecycle (login, auth_status, logout), profile viewing/editing (get_profile, get_my_profile, update_headline, update_about, open_profile_section), jobs lifecycle (search, get, save, easy_apply, saved, applications), messaging (list, get, start, send), feed engagement (get_feed, create_post, like, comment, repost), and networking (connections, people search, connection requests, invitations). There are no obvious dead-end operations.
Average 3.1/5 across 36 of 36 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't mention whether login is required, whether this opens a browser modal (implying visual/UI state changes), what side effects occur (e.g., navigation state changes, modal blocking), or whether the update persists immediately. The mention of a 'modal' hints at UI side effects but doesn't clarify them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with minimal waste. However, it spends valuable word budget on the UI mechanism ('via the profile intro edit modal') rather than on more useful behavioral or usage information. It's concise but not optimally allocated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool (updates a profile field) with no annotations and no output schema. Given its mutation profile, it should disclose prerequisites (login state, navigation state), success indicators, and side effects. The brief description is inadequate for a tool that alters user-visible profile data and likely involves browser navigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter (headline) at 0% schema coverage, the description doesn't mention the parameter at all. However, the parameter is self-evidently the headline text, and the presence of maxLength (220) in the schema provides the key constraint. The description adds almost nothing beyond what the schema and tool name already convey. Baseline 3 is appropriate since the single param is trivially inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update your LinkedIn headline via the profile intro edit modal' uses a clear verb+resource ('Update...headline'), but the second clause ('via the profile intro edit modal') reveals a UI-automation implementation detail rather than a semantically meaningful distinction. It partially distinguishes from sibling update_about and get_my_profile, but the 'modal' phrasing muddles purpose with mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings like update_about or get_my_profile. It implies it's for editing the headline field but offers no exclusions, prerequisites (e.g., must be logged in), or context about when a headline update is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description reveals nothing about side effects—whether posting a comment is visible publicly, whether it requires specific permissions, whether it can be undone, or what happens on failure/rate limits. The dry_run parameter hints at a testing capability but the description doesn't explain its behavior or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words. It is appropriately concise for the information it conveys, though it's under-specified rather than efficiently specified. The structure is clean but brevity is achieved through omission rather than thoughtful condensation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a 3-parameter schema with a non-obvious dry_run flag and no annotations or output schema, the description provides almost no context. For a mutation tool (commenting) with zero annotation coverage and zero schema description coverage, it should explain dry_run semantics, login requirements given sibling auth tools, and comment length/format expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not: none of the three parameters (post_url, comment, dry_run) are discussed. The dry_run parameter especially needs semantic explanation since its behavior is non-obvious from the schema alone. The description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Comment on a LinkedIn post URL') which clearly states the action. However, it doesn't distinguish itself from sibling tools that could overlap like like_post or repost, and there's a note that it could relate to authorization requirements. The purpose is clear but minimal with no differentiation 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like like_post or repost. It doesn't mention prerequisites such as being logged in (linkedin_login) or having authorization, which is relevant given sibling auth tools exist (linkedin_auth_status, linkedin_login). The context is implied but no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says the tool 'opens LinkedIn notifications,' implying navigation/side effects, and returns 'visible items,' implying a read. But it doesn't disclose whether it changes the browser state, what 'visible' means (scroll depth? loaded vs lazy-loaded?), or whether any accounts/setup are needed. The max_chars parameter hints at truncation, but nothing explains what happens to truncated content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste. However, it is under-specified rather than concisely complete—the brevity leaves critical gaps (parameters, prerequisites, behavior). It's efficient but sacrifices necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param tool with no annotations and no output schema, the description should at least explain the parameter, the navigation side effects, and what 'visible' items means. None of these are addressed. The tool appears to involve opening a page (side effect) and returning content, but the description doesn't cover the state change or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there's exactly one parameter (max_chars) with no description. The description doesn't explain max_chars at all—its purpose (limiting output length) is only inferable from its name and min/max bounds. With 0% coverage, the description must compensate but provides zero parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open LinkedIn notifications and return visible items' has a clear verb+resource (open + notifications) and does state what the tool does. However, it doesn't differentiate from siblings well—there's no mention of scope, recency, or how this differs from similar read tools like get_feed. It's functional but not specific enough to distinguish from related navigation/read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. There is no mention of when this should be used versus alternative tools, whether navigation state matters (e.g., must be logged in first), or any prerequisites. The sibling tools suggest LinkedIn interaction may require prior login, but the description says nothing about this requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't mention pagination behavior, rate limits, whether login is required before searching, what the result format is, or whether it modifies anything. Minimal disclosure beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean sentence with no wasted words. Front-loaded with the verb and subject. However, it is under-specified rather than concisely complete—conciseness is fine but at the cost of necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A search tool with no output schema, no annotations, no parameter documentation, and zero context on result format, limits, or login requirements. Given the tool's complexity (external LinkedIn interaction requiring session state), the description is significantly incomplete for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter detail. The limit parameter (max 50) isn't explained—no mention of default behavior, whether results are paginated, or how keywords should be formatted. Both parameters are entirely undocumented beyond the schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search LinkedIn companies by keywords' with a clear verb and resource (searches companies). However, it doesn't distinguish from the sibling tool search_people except by the resource type (companies vs people), and could be confused with search_jobs. The purpose is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs get_company or search_people. No mention of authentication prerequisites (linkedin_login seems to be a sibling prerequisite). No context on what results look like or how to proceed from a result to get_company or follow_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether login is required (despite linkedin_login and auth_status siblings existing), whether results are paginated, what happens when no matches are found, or what the return structure looks like. For a search tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste. It's front-loaded and easily scannable. The only issue is that it's too short to be maximally useful, but structurally it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderate-complexity tool (2 params, one required) with no output schema and no annotations. The description ('Search LinkedIn people by keywords') is the minimum viable statement. It doesn't explain what result fields are returned, whether results are profiles you can then interact with via get_profile or send_message, or how the limit parameter behaves. For a search operation that likely feeds into many follow-up workflows among the siblings, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description mentions 'keywords' which maps to the required parameter, but the 'limit' parameter (which controls result count, up to 50) is not mentioned at all in the description. There is no guidance on how keywords should be formatted or whether they're free-form text or comma-separated terms. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search LinkedIn people by keywords' uses a clear verb (Search) and resource (LinkedIn people), and the keyword parameter is stated. However, it doesn't distinguish itself from sibling tools like search_companies or search_jobs, which share the same 'search by keyword' pattern. The purpose is clear but generic and doesn't differentiate within the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_connections, get_profile, or search_people's sibling search tools. No context is given about whether this searches public LinkedIn profiles, requires login, or how results map to follow-up actions like send_connection_request. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Send' implies a write/mutation action, but the description doesn't disclose whether sending succeeds silently, whether there are rate limits, what happens on failure (e.g., if the thread index is stale), or any side effects on the conversation state. The dry_run parameter hints at preview behavior but the description doesn't explain it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it's arguably under-specified given the complexity of three targeting modes; 'appropriate size' for this tool would warrant a bit more detail about targeting precedence. It's clean but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, the description is too terse. It doesn't explain the dry_run flag, how targeting modes interact or which takes precedence, error behavior, or return semantics. Sibling tools like start_conversation and comment_on_post create ambiguity that the description fails to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds essentially no parameter detail beyond the schema itself. It names the three targeting mechanisms (thread, URL, index) at a high level but doesn't explain the relationship or precedence between `index`, `thread_url`, and the open-thread mode, nor the meaning of `dry_run`. For a 4-parameter tool with zero schema coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Send a message in the currently open thread, a thread URL, or by conversation index' which clearly identifies the verb (send) and resource (message) with three targeting methods. However, it doesn't distinguish from sibling tools like start_conversation or comment_on_post, and a message could be confused with posting content. The purpose is clear on what it does but not why it exists versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three target methods (open thread, URL, index) which half-serves as usage context, but gives no guidance on when to pick this over start_conversation (for new conversations vs existing ones) or how the targeting precedence works when multiple are provided. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Accepting an invitation' is a state-changing action, but the description doesn't disclose the Nth-value semantics beyond indexing (e.g., what happens if the user is already connected, whether the page must be open, what the response looks like). With zero annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that efficiently conveys the core operation. It's front-loaded and avoids wasted words. However, the 1-based indexing note could be better integrated or the description could add a bit more useful context without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing action with no annotations, no output schema, and a single parameter that carries meaning beyond simply being a number. The description explains the indexing but omits behavioral details: whether the invitation manager page must be open, preconditions (being logged in, having pending invitations), error behavior for invalid nth values, and what the success/failure outcome looks like. For a mutating tool with zero annotations, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially explains the single parameter 'nth' by clarifying it's 1-based. However, schema description coverage is 0%, meaning the schema itself provides no field descriptions. The description adds the 1-based indexing clarification but doesn't explain the maximum of 30, edge cases (e.g., nth beyond pending invitation count), or what happens with invalid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('accept') on a specific resource ('pending invitation'), and clarifies 1-based indexing. However, it doesn't distinguish this from the sibling tool get_pending_invitations beyond the verb difference, and the resource is somewhat generic ('invitation manager page'). The purpose is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for accepting pending invitations, which pairs with get_pending_invitations as a prerequisite (you'd need to see the list first). However, there's no explicit guidance on when to use this vs alternatives, no mention of checking the list first, no prerequisites stated, and no exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read-like operation ('return') but doesn't clarify whether login is required, whether results are paginated, what 'visible people links' means exactly, or whether there are rate limits. With zero annotation coverage, this is a significant gap for a scraping/browser tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. However, it's somewhat under-specified rather than genuinely concise - brevity without substance. Still, for what it covers, it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 params, 0% schema coverage, no annotations, and no output schema, the description provides only minimal value. It doesn't explain result format, pagination behavior, the purpose of the limit parameter, or what keywords match against. Given the tool's moderate complexity (a scraping operation on a dynamic social network), this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't mention the 'limit' parameter at all, and 'keywords' is completely undocumented. The input schema only provides basic type constraints (integer with min/max, string) with no descriptions, so the agent is left guessing what keywords filters against (names? companies? titles?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Open your connections list and return visible people links' - a specific verb ('return') with a clear resource (connections/people links). However, among siblings like get_pending_invitations, get_profile, and search_people, it doesn't explicitly distinguish itself from other connection-related tools, so not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like search_people, get_pending_invitations, or get_feed. The description doesn't mention exclusions, preconditions (e.g., must be logged in), or when not to use it. There's also a sibling 'send_connection_request' and 'accept_invitation' that relate to connections but no delineation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies the tool navigates to a page and scrapes text, hinting at mutating navigation state (switching views), but doesn't disclose whether it changes the user's session, requires authentication, or has side effects like opening a new page. The term 'Open' suggests navigation but no preconditions are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action ('Open My Jobs / applications view') and the return behavior ('return visible text'). No wasted words. Could arguably be more descriptive, but it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-annotation, no-output-schema tool that navigates and scrapes, the description is thin. It doesn't state whether authentication is required (unlike linkedin_auth_status sibling), what the returned text precisely covers, or whether it modifies browser state. Sibling get_notifications likely follows a similar pattern, so more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds minimal but reasonable context about what the tool does without parameters — it's a no-argument action that opens a view and reads text. Nothing more is needed since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Open... applications view and return visible text'), which clearly identifies the action. It distinguishes from siblings like get_saved_jobs and get_job since it's about the applications view. However, it doesn't elaborate on what 'visible text' means or which applications are included (all applications, only ones in a list?).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. Siblings include get_saved_jobs, get_job, search_jobs, get_pending_invitations — but the description offers no when-to-use or when-not-to-use guidance. Context is implied ('return visible text' suggests browsing the applications page) but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output is a base64-encoded PNG, which is useful, but doesn't disclose side effects (navigation state changes), whether the viewport is scrolled during capture, or potential preconditions like requiring a loaded page. Given the moderate complexity (browser interaction), this is a notable gap but partially mitigated by declaring the format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence: 'Capture a PNG screenshot of the current page (base64).' It states the verb, resource, format, and encoding in minimal words. No wasted effort.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple capture tool with 2 optional parameters and no output schema, the description is reasonably complete for the core purpose. However, the optional 'url' parameter behavior (navigating first) and 'full_page' semantics could disrupt expected output, and there's no output schema to clarify the return shape. The description adds the base64 detail but doesn't cover edge behaviors like unloaded pages or navigation side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 params with only 50% coverage. 'url' has a schema description ('Optional URL/path to open first'), but 'full_page' has no description in the schema, and the tool description doesn't explain it either. For a boolean that significantly changes the captured output (full page vs. viewport), the lack of elaboration is a gap. The description adds no param meanings beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Capture a PNG screenshot of the current page (base64).' It clearly distinguishes this from sibling navigation/search tools. Among many sibling tools (navigate, get_profile, search_jobs, etc.), this is the only screenshot tool, so differentiation is naturally clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There's no guidance on when to use this tool vs alternatives. It doesn't state when a screenshot is appropriate, whether it can be used mid-navigation, or how it relates to 'navigate' or the browser tools. Given it's the only screenshot tool among siblings, some context about typical use (e.g., after navigation, for verification) would help but isn't present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether this starts a new thread only, whether it can reply to existing conversations, what happens if a conversation already exists with the target person, or whether actions are reversible. For a mutation tool (sending a message to a real person) with zero annotation coverage, this is a significant 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that effectively states the action and target. Zero wasted words. The brevity is a strength here, though it comes at the cost of missing guidance details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sends real LinkedIn messages (irreversible external action) with no annotations and no output schema, this is under-specified. Missing: what dry_run does, message length constraints, whether it appends to existing threads, login requirements, and how errors/duplicate conversations are handled. The 'dry_run' parameter especially needs documentation since it has no schema description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'profile' has a description in the schema). The description explains 'profile' (URL or vanity name) but does not explain the 'message' parameter requirements or the 'dry_run' parameter at all. dry_run in particular is a non-obvious parameter (likely a test mode) that needs explanation and receives none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') with a clear resource ('new LinkedIn message to a person') and method of identification (profile URL or vanity name). It's clear on the action, though it doesn't explicitly differentiate from the sibling 'send_message' tool, which appears to be a close alternative. Slightly unclear how it differs from send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. the sibling 'send_message' tool, which appears semantically similar. No context about prerequisites like being logged in (though there's a linkedin_login sibling), no indication of message length limits or other constraints. The when-to-use context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Follow a LinkedIn company page' states the action but doesn't reveal side effects (e.g., requires being logged in, whether it creates a follow or toggles, any navigation side-effects on the browser state, or what a successful follow looks like). For a mutating action with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. However, it's under-specified rather than concise in a virtue sense, though brevity itself is appropriate for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though the tool is simple with one parameter and no output schema, it's a mutating operation with no annotations and no context about prerequisites like authentication. Given the presence of sibling tools like linkedin_auth_status and linkedin_login, the description should note that login is required. The description is adequate for a trivial tool but leaves important preconditions unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% but only one self-descriptive parameter ('company', minLength 1), the schema already makes the parameter reasonably clear. The description names the resource (company) but adds nothing about format requirements, e.g., whether it expects a company name, URL slug, or ID. Baseline 3 is appropriate since the parameter is largely self-explanatory despite zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Follow ... company page') and clearly states the action. It doesn't actively distinguish from the very similar sibling follow_person, but the resource distinction (company vs person) is implicit and reasonably clear. The purpose is unambiguous for a straightforward action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The closely related sibling follow_person exists, and get_company/show page navigation are alternatives, but no guidelines distinguish when to choose follow_company. There's no mention of preconditions such as being logged in (though siblings linkedin_login and linkedin_auth_status suggest this is relevant) or when following is appropriate versus connecting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool 'opens' a page and returns visible text, implying a read operation. However, it doesn't disclose whether login is required, whether company pages that are gated/premium-locked will fail, whether the data is paginated/truncated, or what happens when the slug/URL is invalid. For a page-scraping tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that efficiently states the tool's action and return value. No wasted words, well-front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one fully-documented parameter and no output schema, the description is reasonably adequate. However, it lacks information about edge cases (invalid slug, rate limits, authentication requirements) and doesn't describe the format of the returned 'visible text'. Given the sibling set includes navigation/auth tools, the description stands on its own reasonably well but could be richer about failure modes and output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'company' parameter documented as 'Company slug (e.g. 'google') or full company URL.' The description adds marginal value by confirming the input format ('by slug or URL'), consistent with the schema. Since schema is complete, baseline 3 is appropriate; the description doesn't add much beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Open a LinkedIn company page by slug or URL and return visible text.' It has a specific verb (open), resource (LinkedIn company page), and input mechanism (slug or URL). However, the tool name 'get_company' clearly distinguishes it from siblings like 'search_companies' and 'follow_company', but the description doesn't explicitly call out that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Open a company page... return visible text') but provides no explicit when-to-use vs alternatives. It doesn't distinguish when to use get_company versus search_companies or follow_company, and gives no exclusions or context about when this tool should be preferred.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. The phrase 'Open LinkedIn messaging' does communicate a physical browser action (navigation), which is useful context about side-effects (it changes the visible page state). However, it doesn't disclose whether this returns a list vs persists anything, page navigation side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose efficiently. Zero words are wasted. It loses a point only because it omits useful detail about the parameter and usage context that could fit in one or two additional short sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 optional parameter, no output schema, and no annotations, the description is thin. It doesn't explain the limit parameter, the return value shape, potential side effects of navigating the browser, or prerequisites like being logged in. Sibling tools like send_message and start_conversation exist in the same messaging domain, and the description doesn't clarify how results relate to them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all beyond what the schema's min/max constraints imply. The description adds zero value about what 'limit' means, its default, or how it affects results. With 1 parameter and 0% coverage, the description should at least mention it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open LinkedIn messaging and list visible conversation threads' clearly states a specific verb+resource (list conversations) and the action flow (open messaging first). It distinguishes itself from siblings like get_conversation (single thread) and start_conversation (create new). However, it could be more explicit about the differentiation from get_conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool vs alternatives. The description implies opening the messaging tab first, which suggests a navigation prerequisite, but doesn't explicitly state it needs a prior login session or mention that start_conversation/get_conversation are the alternatives for specific thread operations. No exclusions or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It states it 'return[s] visible text' which hints at a read operation, but does not disclose whether this opens a modal, navigates to a new URL, leaves the current page state, or requires an existing logged-in session. For a navigation-like tool, behavioral side effects (page changes) are significant and undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is efficient and conveys the core action plus the return behavior. Zero wasted words, appropriately minimal for a one-parameter tool with an enum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a 0% schema description coverage, the description carries heavy burden. For a tool that navigates UI and returns visible text, it should disclose session preconditions (login required), whether the page navigates away, and what the returned text represents. The description doesn't explain how the returned text enables 'guided edits' or what format it takes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'section' has an enum with 6 clear values, which the schema fully documents. The description adds the phrase 'experience, education, skills, etc.' echoing the enum values. With schema description coverage at 0% but a complete enum present, the description adds marginal value—it confirms these are edit sections but doesn't explain what each section returns or any differences between them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Open a profile edit section') and lists clear section examples (experience, education, skills, etc.), giving a clear purpose. It distinguishes from the sibling edit tools like update_headline and update_about by framing this as navigation to a section rather than a direct content update, though the distinction is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a prerequisite step before guided edits ('for further guided edits'), but provides no explicit guidance on when to use this vs alternatives like update_headline, update_about, or navigate. It doesn't state exclusions or when NOT to use it, leaving the agent to infer the usage context across many sibling profile-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention any behavioral traits: whether results are paginated, whether it navigates the browser, whether authentication is required, rate limits, or what the return structure looks like. This is a significant gap for a search tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is efficient and to the point with zero wasted words. It conveys the core purpose immediately. It could arguably be even more compact, but the current length is appropriate for the limited content it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 6 parameters, no annotations, no output schema, and only 33% schema coverage, the description is notably incomplete. It doesn't address parameter combinations, result format, pagination, or how filters interact. Compare to the TDQS mid example: this is a search tool where the agent needs more operational guidance that is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, with only remote and experience having descriptions in the schema. The description says 'keywords and optional filters' but doesn't elaborate on any parameter semantics. The 'prefer remote roles' phrasing in the schema is vague (does 'prefer' mean filtering or ranking?), and the description doesn't clarify. With 33% coverage, the description should compensate but barely does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Search LinkedIn jobs') and mentions keywords and optional filters. It clearly identifies what the tool does. However, it doesn't distinguish it from sibling tools like search_people or search_companies beyond the word 'jobs', though the resource is explicit enough that this is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_job or easy_apply_job. No context on when search is appropriate, what the results will be used for, or any exclusions. The description simply says what it does, not when to invoke it in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't state whether login is required, whether saving an already-saved job errors or is idempotent, what happens to the saved job (where it appears), or what the response contains. For a mutation action with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's front-loaded with the key verb and resource. It could arguably be marginally more helpful with a usage hint, but as measured purely on conciseness, it's appropriately minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a single parameter, more context is needed. It doesn't clarify whether login state is required (a common requirement given sibling authentication tools), whether repeated saves are safe, or what the user sees afterward. The simplicity of the tool partially excuses some gaps, but the lack of auth/side-effect context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'job' is documented as 'Job ID or job URL'. The description's phrase 'Save / bookmark a LinkedIn job posting' adds the context that the parameter represents a posting to be saved, complementing the schema's format hint. With only one well-documented parameter, there's little more needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it saves/bookmarks a LinkedIn job posting, with a specific verb ('save') and resource ('job posting'). It distinguishes well from siblings like 'get_job', 'search_jobs', and 'easy_apply_job' since it's clearly the act of bookmarking/persisting a job. However, it doesn't explicitly differentiate from 'get_saved_jobs' which is the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives is provided. There's no mention of prerequisites (e.g., needing to be logged in), no note about when not to use it, and no alternative tool references. Among siblings like 'easy_apply_job' or 'get_job', a user could benefit from knowing this is the pre-application bookmarking 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?
No annotations are provided, so the description carries the disclosure burden. The description clearly implies a mutating action ('Create...post'), which is evident. However, it doesn't disclose behavioral specifics like whether a linkedin_login is required first, rate limits, whether the post is immediately public, or failure/response behavior. The dry_run parameter (in schema) signals a safe preview path but isn't surfaced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with zero waste. It's front-loaded with the verb and resource. Slightly terse given the tool's core role, but structurally appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and only the dry_run safety valve documented. For a writing/mutation tool in a large sibling set (39 tools), the description should clarify prerequisites like login state, mention that this actually publishes to a real feed, and address the destructive nature. The description is too sparse for the tool's role and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (text parameter has no description but dry_run does). The description itself adds no meaning beyond the schema for either parameter. The dry_run parameter is well-documented in the schema. Baseline 3 applies since schema does partial heavy lifting, but the description contributes nothing beyond restating the resource type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Create a LinkedIn text post on your feed.' It identifies the platform (LinkedIn), the resource (text post), and the destination (your feed). It distinguishes from like_post, comment_on_post, and repost siblings, though it doesn't explicitly differentiate from other content-creation actions beyond its concise phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like repost or comment_on_post. The dry_run parameter hints at a preview workflow but the description provides no context for when posting is appropriate, prerequisites (e.g., must be logged in), or alternatives. This is a gap given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state whether this is a read operation, whether it opens a new view or returns data, whether it requires an authenticated session, or what it does to the browser/page state. For a tool that 'opens' a thread, the agent can't tell if this returns message content or simply navigates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the primary verb and resource. The main structural improvement would be separating the two input methods into clearer guidance, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema coverage, the description carries the full explanatory burden but provides minimal detail. It doesn't clarify expected return value, whether the tool navigates to a page or fetches data, authentication requirements, or failure behavior. For a messaging tool with two underspecified params, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that index is a 1-based index from list_conversations (adding useful semantics) and that thread_url is an alternative identifier for the thread. However, it doesn't clarify the relationship between the two params (are they mutually exclusive?), which param takes precedence if both provided, or format details for index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ("Open") and resource (a messaging thread), and distinguishes the two input methods (index from list_conversations, or thread URL). It's specific enough to convey what the tool does, though it doesn't explicitly distinguish from sibling send_message or start_conversation beyond context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells how to reference a thread (by index from list_conversations or by URL), which implies the workflow dependency on list_conversations. However, it doesn't state when to prefer this over start_conversation or send_message, nor does it explain when to use index vs thread_url. The reference to list_conversations provides useful guidance but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The 'dry_run' parameter hints at a post-verification mechanism, but the description doesn't mention side effects, whether the action is publish-immediate or draft, auth requirements, or what happens on failure. For a write action (reposting publicly), this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that captures the essential purpose. It's front-loaded and wastes no words. It could include slightly more but remains appropriately sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (3 params, no output schema), but for a write action with no annotations and 0% schema description coverage, it should address the dry_run behavior and any side effects more thoroughly. The description conveys the core purpose but lacks the behavioral depth needed for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains post_url (the post to repost) and thought (optional text overlay), but doesn't clarify the dry_run parameter's behavior, which is non-obvious and left to the schema type (boolean) alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource action ('Repost (reshare) a LinkedIn post URL'), with an optional modifier ('with a thought'). It distinguishes reasonably from sibling tools like create_post, like_post, and comment_on_post, though it doesn't explicitly differentiate itself from create_post, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a user wants to reshare an existing post), but it doesn't explicitly state when NOT to use it or name alternative tools like create_post for fresh content. No exclusions or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. This is a persistent, state-changing social action on LinkedIn — it creates a pending invitation that cannot be easily undone and may trigger rate limits or spam protections. The description reveals none of this: no mention of irreversibility, rate limits, prerequisites (auth), or limitations on daily connection requests. The dry_run parameter hints at the risk of actual action, but the description fails to explain it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no waste. However, it is arguably under-informative rather than concisely complete — it could add a sentence about dry_run or auth requirements without becoming verbose. Given the front-loaded, direct phrasing, it earns above-average marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a persistent, rate-limited social action with no annotations and no output schema, the description is inadequate. It doesn't describe what happens on success/failure, the dry_run parameter semantics, auth dependency (visible from siblings but not stated), or any error conditions. With 3 parameters and 0% schema coverage, more explanation is needed for the agent to use this tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must compensate for the undocumented parameters. There are 3 parameters (note, dry_run, profile), and the description mentions 'optional note' but doesn't explain the dry_run parameter or the format/URL expectations of profile. The description adds some value by noting the note is optional, but leaves dry_run completely unexplained and doesn't clarify what 'profile' should contain (URL vs. ID). Overall, partial compensation for a high coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a connection request to a LinkedIn profile, with optional note' uses a specific verb+resource (send connection request to LinkedIn profile) and clearly states the scope. It differentiates from sibling tools like send_message and follow_person, as the action is distinct and well-named. The name itself is descriptive, and the description reinforces it without being a mere tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the large sibling set including send_message, follow_person, accept_invitation, and get_pending_invitations, the description doesn't clarify the distinction between sending a connection request and following someone or sending a message. No prerequisites (e.g., must be logged in) are stated, though sibling tools like linkedin_login and linkedin_auth_status hint at an auth dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Open' implies navigation/mutation of browser state, but the description doesn't disclose whether this requires prior login, whether it changes navigation state, whether it's read-only, or any rate-limit considerations. For a browser-navigation style tool with zero annotation coverage, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with zero waste. Front-loaded with the action verb and resource. Perfectly sized for what it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a browser-navigation tool with no annotations and no output schema, the description should explain what 'visible details' returns, whether login is required, and how it contrasts with related listing tools. With one parameter fully documented by the schema, basic invocation is clear, but the behavioral expectations and return value scope are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'job' parameter as 'Job ID or full https://www.linkedin.com/jobs/view/... URL'. The description adds little beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting for this single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open a LinkedIn job posting and return its visible details' clearly states the verb (open/return) and resource (LinkedIn job posting). It distinguishes reasonably from siblings like search_jobs and get_saved_jobs by indicating it opens a specific posting rather than listing them. It's clear but could be more specific about what 'visible details' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (open and view a specific job posting) but provides no explicit when-to-use vs alternatives guidance. It doesn't compare with search_jobs, get_saved_jobs, or easy_apply_job, nor does it state exclusions. A minimal acceptable level of implied usage exists but no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Follow' implies a state-changing, irreversible action, but the description doesn't disclose what happens (e.g., the person is notified, the action creates a lasting relationship, requires login state). It doesn't mention authentication prerequisites or whether this is reversible via a sibling 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that conveys the essential action and the required context. Zero wasted words. This is appropriately minimal for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema) so the description is adequate for the basic action, but it lacks behavioral context: what happens after following, whether it requires an active LinkedIn session, and how it differs from send_connection_request. For a state-changing action with no annotations and no schema param descriptions, more disclosure would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The profile parameter exists in the schema but lacks a description. The tool description's phrase 'from their profile page' partially implies that 'profile' refers to the current open profile context. However, with 0% schema coverage, the description should more clearly define what 'profile' means (e.g., an identifier, URL, or the currently active profile). It adds marginal value but doesn't fully clarify the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Follow') and resource ('a person'), and specifies the requirement of being on their profile page. It distinguishes from siblings like follow_company (which targets companies). However, it doesn't clarify the persistent outcome (creates a following relationship) or how it differs from send_connection_request, a nearby sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the precondition: you must be on the person's profile page. This is a clear contextual cue. However, it doesn't explain when to choose following over sending a connection request, or note any restrictions (e.g., cannot follow someone you're already connected with). No alternatives or exclusions are mentioned.
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?
No annotations are provided, so the description carries the burden. It discloses the navigation side-effect ('Open') and return behavior ('return visible post text'). However, it doesn't disclose whether the browser scrolling/state is modified permanently, whether auth is required, or pagination/graceful-failure behavior. The 'open' action implies a navigation side effect, which is a meaningful disclosure but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that communicates the action and the return value with zero waste. No filler, no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (browser navigation plus scraping visible posts) with no annotations and no output schema. The description adequately states the core behavior but does not explain the max_chars parameter, the browser state implications, or failure modes. For a feed-scraping tool, this is acceptable but leaves the agent guessing on edge cases like an unauthenticated session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter max_chars has 0% schema description coverage, so the description carries full responsibility. The description doesn't mention the max_chars parameter or its purpose (likely truncating returned text). However, with only one optional parameter, the schema is relatively self-explanatory, and the description covers the main behavior adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('LinkedIn home feed'), clearly stating it returns visible post text. It distinguishes from siblings like get_company or get_post since it targets the feed specifically, though no sibling alternative like a single-post viewer is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it opens the home feed, implying it needs LinkedIn to be logged in and a browser to be active (a prerequisite likely required by sibling tools like linkedin_login). However, it doesn't explicitly state when to use this vs alternatives, what context is needed (e.g., must be logged in), or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does but reveals nothing about whether it's read-only, whether pagination is involved, ordering of results, or what happens when there are no pending invitations. For a read-type operation, the readOnly nature is implied but never stated, and no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It's appropriately terse for a zero-parameter list tool. It could arguably be front-loaded with a stronger verb, but given its simplicity, one concise sentence is sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema and no annotations, the description is reasonably complete in explaining the purpose. However, it doesn't describe the return format or clarify whether pending invitations are incoming, outgoing, or both. Given the simplicity of the operation, this is adequate but leaves some semantic ambiguity about what 'pending' encompasses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (nothing to document). No parameters means there is nothing to explain beyond what the schema provides, so the baseline of 4 applies. The description correctly implies the tool requires no input filters or arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List pending invitation / connection requests." uses a clear verb+resource structure. It specifies the tool lists pending invitations/connection requests, distinguishing it from related tools like send_connection_request and accept_invitation. The slight ambiguity between 'invitation' and 'connection request' (are these the same or different entities?) prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing pending requests, which naturally contrasts with accept_invitation (act on them) and get_connections (existing connections). However, no explicit when-to-use/when-not-to-use guidance or named alternatives are provided. The usage context must be inferred from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read operation (listing), which is inferable from 'List', but the description doesn't mention pagination behavior, ordering, whether results include full job details or just summaries, or whether the 'limit' parameter controls result count. For a listing tool, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It's appropriately front-loaded and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a fairly simple listing tool with one optional parameter and no output schema. The description covers the core purpose adequately. However, given no output schema exists, it doesn't explain what fields/information the returned jobs will contain, and leaves pagination/ordering behavior unspecified. Adequate for a simple tool but has small gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There's one optional parameter (limit) with a minimum of 1 and maximum of 50. Schema description coverage is 0%, so the description doesn't explain the limit parameter at all. However, the schema itself provides good constraint documentation (min/max), and the semantic of 'limit' is fairly self-evident for a list operation. A description mentioning 'limit controls how many jobs to return (max 50)' would be more helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List jobs you have saved on LinkedIn' clearly states a specific verb (list) and resource (saved jobs), and distinguishes it from sibling tools like search_jobs or get_job by specifying the 'saved' scope. It's clear and unambiguous, though it could be slightly more specific about the personal/owned nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for viewing a user's own saved jobs, which is an implied usage. It doesn't explicitly contrast with sibling tools like search_jobs (which finds new jobs) or save_job, though the sibling context makes the distinction reasonably inferable. There's no when-to-use-when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states it checks login status but doesn't disclose what happens when not logged in (error vs boolean return), whether it performs side effects (e.g., requests, session refresh), or what the response format looks like. With zero annotations and no output schema, more detail would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, immediately front-loaded with the purpose. Every word earns its place for a zero-parameter status-check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema status check, the description is reasonably complete. However, it doesn't explain the return value semantics (boolean? error?) or clarify behavior when the session is missing. Given the lack of annotations, a brief note about expected output or failure behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100% (trivially, since there are no parameters). With no parameters to document, a baseline of 4 is appropriate. The description doesn't need to add parameter detail since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether the saved Playwright session is logged into LinkedIn. It uses a specific verb ('Check') and resource ('saved Playwright session') with a clear scope (login status). It doesn't explicitly distinguish from siblings, but its purpose is naturally distinct from login/logout which perform actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a natural use-case: verifying login state before performing authenticated actions. However, it doesn't explicitly say when to use this vs alternatives (e.g., calling linkedin_login directly), nor does it state that this should be used as a precondition check before other operations. No exclusions or alternatives are mentioned.
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?
With no annotations provided, the description carries full burden. It discloses that a visible browser opens, requires credential entry, and 2FA may be prompted — all useful behavioral traits. The session-persistence note is helpful. However, it doesn't disclose whether this replaces any existing session, what happens on failure, or whether credentials are stored or re-entered each time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences and front-loads the core action. Every sentence contributes value: the first states the action and expectations, the second notes session persistence. Slightly minimal but appropriately concise for a login tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a login tool with a single optional parameter and no output schema, the description covers the essential flow well. However, given the large sibling set of LinkedIn tools that depend on this session, it would be useful to explicitly note that this must be run before other tools and whether existing auth state invalidates the need. The session-save note partially covers this but could be more explicit about sequencing and error recovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and timeout_ms already has a clear description ('How long to wait for login completion (default 5 minutes)'). The tool description doesn't add parameter-level detail beyond the schema, but with full coverage the baseline of 3 is appropriate — the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a visible browser for LinkedIn sign-in, completing email/password and 2FA. The verb+resource (open browser, complete sign-in) is specific and distinguishable from siblings like linkedin_auth_status (check auth) and linkedin_logout (end session). It doesn't explicitly contrast with siblings but the action is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Open a visible browser for LinkedIn sign-in') and notes 2FA may be prompted, giving context about what the agent should expect. However, it doesn't explicitly say when NOT to use it or name alternatives like linkedin_auth_status for checking existing session state. The phrase 'Session is saved for later tools' implies it's a prerequisite step, which is helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the two effects (sign out + close context), but doesn't clarify whether this is destructive to any saved state, whether session data is preserved for future logins, or what happens to cookies/credentials. For a session-terminating action, this is a meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, two clear actions, zero waste. Efficient and appropriately sized for what is a simple stateless operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logout with 0 parameters and no output schema, the description conveys the core behavior. However, it doesn't address state implications (e.g., whether the browser context closing also affects other open tabs or sessions) or confirm what success looks like. Given the tool's simplicity, this is adequate but could note side-effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there's nothing to document. The baseline of 4 for zero-parameter tools is appropriate; the description adequately explains the action without needing parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states verb+resource: 'Sign out of LinkedIn... and close the browser context.' It distinguishes from siblings like linkedin_login and close_browser by combining logout with context closure. However, it doesn't explicitly distinguish from close_browser alone, though the combined action differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is used when ending a LinkedIn session, but provides no explicit when-to-use versus alternatives like close_browser. No exclusions or guidance on when not to use it.
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?
No annotations are present, so the description carries the transparency burden. It states it returns visible text, which is helpful. However, it doesn't disclose loading/wait behavior, whether navigation occurs in a fresh page or the same tab, or what happens on failed/404 navigation. The require_auth parameter hints at auth implications but its behavioral effect isn't described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that states what it does and what it returns. Efficient and front-loaded. Could arguably add a note on auth but remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a general navigation tool with no output schema and no annotations, the description is moderately complete. It covers purpose and return value but omits behavioral details like auth requirements (the require_auth param is unexplained), page load waits, and error behavior. Given the tool's broad scope, more detail on auth and failure modes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented in the schema itself. The description adds no new param-level semantics beyond the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Navigate the automation browser to any LinkedIn path or absolute URL and return visible text.' It distinguishes from siblings by covering browser navigation broadly, while other tools handle specific LinkedIn resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's a general-purpose navigation tool ('any LinkedIn path or absolute URL'), but provides no explicit when/why to use it vs. other tools. Given the many specialized tools (search_jobs, get_profile, etc.), it would help to state when raw navigation is appropriate, e.g., for pages without a dedicated tool.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description clearly signals this is a write/mutation operation ('Update'), which is evident from the verb. However, it doesn't disclose whether a login is required first, whether changes are immediately visible, or whether there are validation rules beyond the schema's maxLength constraint. For a mutation tool with zero annotation coverage, some additional context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It front-loads the verb and resource, and there is no extraneous content. This is appropriately concise for a tool with a single unambiguous parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, so the bar for completeness is lower. The description adequately covers purpose and what to provide, but for a write operation with no annotations, it would benefit from noting the login prerequisite (given the sibling linkedin_login exists) and possibly the max character limit implications. There are no gaps that would cause an agent to misuse the tool, but some operational context (e.g., needing to be authenticated) is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema. While the description itself doesn't explicitly document the 'about' parameter, the single-parameter schema with a maxLength of 2600 is self-explanatory, and the description clearly indicates what content goes into that field (the About/summary text). The description adds meaning by situating the parameter in context, even though it doesn't explicitly enumerate parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update your LinkedIn About / summary section' uses a specific verb (update) with a specific resource (LinkedIn About/summary section), clearly distinguishing it from the sibling update_headline tool. It's not a tautology and clearly identifies what it does, though it could be slightly more explicit about the fact that this is the profile's bio/summary text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (updating the About section of a LinkedIn profile) and the sibling update_headline provides an implicit contrast for when to use which tool. However, it does not explicitly state when to use this tool vs alternatives, mention any prerequisites like being logged in, or note that updating About differs from updating headline.
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?
No annotations provided, so the description carries the burden. It states the tool opens a browser/navigation to the profile page, which implies a browser context (consistent with siblings like navigate, close_browser). However, it doesn't clarify what 'visible profile text' includes (e.g., only what's currently visible vs. full text), scraping reliability, rate limits, or whether login is required before use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no wasted words. Efficient and front-loaded. Could arguably add one more sentence of usage context without becoming verbose, but as-is it's appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the core mechanics: open profile, return text. However, it doesn't discuss prerequisites (logged in?), what the returned text looks like, or behavioral caveats around browser-driven scraping. Sibling-linked context (login/auth tools) implies a dependency but the description doesn't mention it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and 100% schema description coverage (which is trivially full for an empty schema). There's nothing for the description to add semantically since there are no parameters to explain. Baseline 4 for zero params is exceeded slightly because the description fully clarifies what data is returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes opening the user's LinkedIn profile and returning visible profile text. Clear verb ('open') + resource (own profile) + outcome (return text). Differentiates from get_profile, which presumably gets another person's profile, though the description doesn't explicitly make this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or exclusion guidance. The 'My' in the name and 'your' in the description imply it's for the logged-in user's own profile, distinguishing it from get_profile, but this isn't stated as guidance. No mention of requiring login or alternatives.
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?
No annotations are provided, so the description carries the transparency burden. It does state the return is 'visible text' and that it 'opens' a profile (implying browser interaction), but it does not disclose auth requirements (likely needing linkedin_login first), rate-limit behavior, or whether the profile must be publicly accessible. Some useful behavioral context, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero filler. Every phrase earns its place: input formats, resource, and output are all covered efficiently. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with full schema coverage, the description is reasonably adequate. However, given the sibling set includes many profile-related operations (get_my_profile, open_profile_section, search_people) and there's no output schema, it could benefit from noting auth prerequisites, section coverage, or which underlying data makes profiles differ — the current description leaves those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema already detailing the two accepted formats. The description reinforces this by reiterating both the vanity slug and full URL forms. While the schema does most of the work, the description adds modest value by confirming the return behavior tied to the parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') with a clear resource (LinkedIn profile) and explicitly scopes the input to vanity name or full URL, returning visible text. This clearly distinguishes it from siblings like get_company or get_my_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_my_profile, get_company, or search_people. The description states what it does but gives no exclusions, prerequisites (e.g., login required), or contextual cues about when it's the right choice among the many profile/people-related siblings.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (like) but does not disclose whether this requires authentication, whether the like is reversible (unlike), whether it navigates away from the feed when opening a URL, or what happens on failure (e.g., already liked). For an action that mutates state with zero annotation coverage, more behavioral detail would be expected, though the core action is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that covers both usage modes without wasted words. It is appropriately front-loaded with the core action. Minor deduction for not elaborating on parameter interplay, but the description is well-sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 optional parameters with no output schema and no annotations. The description explains the two usage modes but does not address what happens when both parameters are supplied together, the effect on the browser state (navigating to a URL), or failure cases like already-liked posts. Given the sibling set includes login/auth tools, the description could note auth requirements. Generally functional but with notable gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; the description names the parameters implicitly (nth for feed position, post_url for URL-based likes) but does not add semantic detail beyond the schema. The nth parameter's schema explains it's the 1-based index with default 1, and post_url's format is defined as uri in the schema. The description adds context about which mode each parameter enables, giving some value, but does not explain the interplay (e.g., mutual exclusivity) or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (like) and resource (a post), with two specific contexts: a post visible on the current feed, or a post opened via URL. It distinguishes from sibling tools like comment_on_post, repost, and follow_person, which are different feed actions. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates two distinct usage modes (feed-based and URL-based) which implies when each would be used. However, it does not explicitly mention prerequisites like being logged in (though sibling tools like linkedin_login and linkedin_auth_status suggest auth matters), nor does it explain which mode takes precedence when both nth and post_url are provided. Clear context but no exclusions or alternative-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that cookies persist on disk after closing, which is meaningful behavioral context beyond just 'close browser'. However, it doesn't explain what state is lost (open tabs, in-memory data) or whether subsequent tool calls require a new context or login.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no waste. The parenthetical adds genuine value without bloating the description. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter tool with no output schema, so the description burden is minimal. It covers the primary action and the notable side-effect (cookie persistence). The main gap is not explaining follow-on state: whether a new login/navigation is required after closing, or whether certain tools become unusable until reopened.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there's nothing for the description to explain about parameters. With schema coverage at 100% and no params to describe, a baseline 4 is appropriate since there's no parameter ambiguity needing resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes the Playwright browser context, with a specific verb (close) and resource (browser context). It also adds a useful clarification about session cookies remaining on disk, distinguishing the effect from full session deletion. This clearly distinguishes it from tools like linkedin_logout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance. The parenthetical about cookies remaining on disk implies a limited scope of what closing does, but there's no mention of when closing is appropriate vs alternatives, or any cleanup implications. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the dry_run behavior and that submission only affects 'the first step', which is useful. However, it doesn't disclose side effects like needing to be logged in, or what happens after submission (follow-up steps, multi-step forms). The description covers the core safe behavior but leaves the lifecycle of multi-step applications unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The description front-loads the primary purpose and immediately explains the critical dry_run default, making it efficient and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a stateful action tool (submit an application) with no output schema and no annotations. The description explains the dry_run mechanism clearly, which is helpful, but for a tool that triggers a workflow with potentially multiple steps and side effects (form submission, navigation changes), more context about the process lifecycle and login requirements would strengthen completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with note and dry_run documented in the schema itself but job lacking a description. The tool description adds the crucial dry_run default behavior (dry_run=true) which clarifies the boolean's semantics beyond 'do not submit'. The 'job' parameter semantics are implied ('on a job') but not explicitly explained in the description, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Start LinkedIn Easy Apply on a job') and clearly distinguishes the tool's purpose from siblings like save_job, get_job_applications, and search_jobs. The dry_run default behavior is clearly stated, differentiating this from simple job viewing or saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the dry_run default behavior and when to set dry_run=false ('submit the first step if possible'). It implies this is a mutation/action tool for applying, distinguishing it from read-only siblings like get_job or search_jobs. However, it doesn't explicitly state when NOT to use this tool or mention alternatives like save_job for later.
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:

[![openlinkedinmcp MCP server](https://glama.ai/mcp/servers/tiagoyamashita/openlinkedinmcp/badges/card.svg)](https://glama.ai/mcp/servers/tiagoyamashita/openlinkedinmcp)

Score Badge

Copy to your README.md:

[![openlinkedinmcp MCP server](https://glama.ai/mcp/servers/tiagoyamashita/openlinkedinmcp/badges/score.svg)](https://glama.ai/mcp/servers/tiagoyamashita/openlinkedinmcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tiagoyamashita/openlinkedinmcp'

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