LinkedIn MCP Server

Server Quality Checklist

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

Latest release: v1.0.6
Disambiguation4/5
Almost every tool has a clearly distinct purpose, and the descriptions are exemplary at resolving overlaps (e.g., linkedin_get_applied_jobs vs linkedin_get_application_history, linkedin_export_connections vs linkedin_request_data_export). A few nearby pairs like linkedin_send_message vs linkedin_reply_to_conversation retain slight overlap, but misselection is unlikely given the detailed guidance.
Naming Consistency4/5
All 101 tools follow a consistent linkedin_verb_noun snake_case pattern with a uniform prefix. Minor deviations keep it from a perfect score: profile sections use add_* while posts use create_post; edit_* and update_* are both used for modifications; and delete_*, remove_*, and withdraw_* all express removal.
Tool Count1/5
At 101 tools, this is far beyond the 50+ threshold the rubric flags as an extreme mismatch. While LinkedIn's surface area is genuinely large and each tool has a defined role, the count is overwhelming for an agent to navigate effectively.
Completeness4/5
The server covers LinkedIn's core workflows end to end: profile CRUD, job search/apply/withdraw, messaging, connection management, posts, notifications, search, settings, and data export. Minor gaps like endorsements, recommendations, and Featured-section management exist, but no essential flow is left as a dead end.
Average 4.1/5 across 100 of 101 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already convey (readOnlyHint=false implies mutation). It does not disclose possible side effects, authentication requirements, idempotency (or lack thereof), or consequences of repeated calls. Since annotations are present, the description contributes no extra transparency.
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 very short and front-loaded with the verb, making it easy to scan. However, 'honour or award' is somewhat redundant since an award is a type of honour; simplifying to 'award' would be more concise, but overall it is not verbose.
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 write tool with a well-described schema, this is minimally viable but lacks important context such as return value or whether the operation appends or replaces existing awards. The absence of an output schema means the description could have disclosed result expectations, but it does not. Annotations and schema partially compensate, so it is not incomplete enough for a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 4 of 5 parameters with meaningful details (e.g., startMonth accepts both name and number), so baseline is 3. The description adds no parameter-specific meaning and does not clarify relationships between parameters; it merely repeats the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Add') and resource ('honour or award') and specifies the target ('the profile'), making the tool's function unambiguous. This clearly differentiates it from sibling tools like add_certification or add_skill, as it unambiguously targets awards/honours.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternative 'add_*' siblings, nor are any exclusions or prerequisites mentioned. The description is purely an action statement without contextual cues about appropriate use 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?
Annotations already indicate this is a mutation (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description's 'Add' aligns with annotations but adds no additional behavioral context, such as whether the new entry is appended, if duplicates are possible, or if any related profile data is affected. With no extra context beyond annotations, transparency is minimal.
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: 'Add volunteer experience to the profile.' It is front-loaded with the verb and target, with zero waste. Every word contributes to the purpose.
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 write operation with 9 parameters and no output schema. The description does not explain the expected return value, how the tool affects existing profile data, or any prerequisites. It is minimally functional but fails to provide contextual completeness for an agent to anticipate behavior beyond the action itself.
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% (6 of 9 parameters described). The description itself does not mention any parameters or clarify the undocumented ones like 'current' or 'cause'. Since coverage is moderate and the description adds no value, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add volunteer experience to the profile' uses a specific verb ('Add'), identifies the resource ('volunteer experience'), and the target ('profile'). The name itself distinguishes it from sibling add_* tools (e.g., add_experience, add_project) by the resource type, so purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives such as add_experience, nor any prerequisites or context about volunteer experience vs other profile sections. There are no exclusions or alternative suggestions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action, which matches the annotations (readOnlyHint=false) but adds no additional behavioral context. It does not mention side effects, duplication risks, or authorization requirements, which would complement the openWorldHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It communicates the essential action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and good schema/annotation coverage, the description is minimal but adequate. It lacks usage guidance and any behavioral caveats, but the schema and annotations fill many gaps. Not fully complete but not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 88% of parameters with descriptions, so the schema carries most of the parameter semantics. The description adds no specific parameter-level guidance beyond what the schema already provides, resulting in baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' and identifies the resource as 'licence or certification' and target 'profile', clearly distinguishing it from sibling add_* tools like linkedin_add_language or linkedin_add_education.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It doesn't mention prerequisites, disambiguation from other add_* tools, 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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, indicating a non-destructive write operation. The description adds no extra behavioral context, such as whether adding a duplicate language replaces the existing entry, whether it requires special permissions, or any side effects. Since the description provides no value beyond the annotations, a low score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no fluff or redundant information, making it easy to parse and understand quickly.
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 2-parameter mutation with annotations, the description is minimally viable. However, it lacks any information about return values (no output schema), behavior on duplicate entries, or success/failure indications. These gaps make it adequate but not complete for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions: 'language' has a clear example, while 'proficiency' only has an enum. The description mentions 'optional proficiency level', which clarifies optionality but adds no further semantic detail about the proficiency values. This is a modest addition, but does not fully compensate for the schema's lack of explanation for the enum meanings.
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 a specific action ('Add') and a specific resource ('a language to the profile'), and the optional proficiency level adds relevant detail. It distinguishes itself from sibling tools like linkedin_add_skill or linkedin_add_certification by explicitly naming the target as 'language'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives. There is no mention of contexts (e.g., when a user requests language addition), prerequisites, or clarification that it is the correct tool for languages rather than skills or certifications. The usage is only implied by the name and simple description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the export formats (JSON, CSV, Markdown), which is a useful behavioral detail. However, it does not disclose session requirements, rate limits, pagination, or what 'any search' means in terms of verticals or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, direct and front-loaded, with no unnecessary words. It earns its place by conveying the core action and output formats efficiently.
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 5 parameters and no output schema, this short description is insufficient. It does not explain what the output looks like (e.g., file, link, data object), how verticals and location work, or pagination behavior. The tool's complexity demands a more detailed description to be contextually complete.
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 40% (limit and format described). The description partially compensates by mentioning export formats, which clarifies the 'format' parameter, and 'Run any search' implies 'query' is the search term. But it does not address 'limit', 'location', or 'vertical', leaving significant gaps for required and optional parameters.
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 runs a search and exports results to JSON, CSV, or Markdown. This specific verb+resource combination distinguishes it from sibling tools like linkedin_export_companies or linkedin_search_people, which either export specific data types or search without explicit format options.
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 the many search and export siblings. It does not mention alternatives, exclusions, or scenarios where a specific search tool would be preferred. The phrase 'Run any search' implies broad usage but lacks concrete decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, so the description adds no new behavioral context. It does not mention duplicate handling, authentication requirements, or what happens after a successful add. The phrase 'to the profile' is the only added context, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently conveys the tool's 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?
For a simple write tool with no output schema, the description is minimally adequate. However, it does not mention that title is required or clarify the undocumented url/title/description fields, leaving some contextual gaps despite low complexity.
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 50% (publisher, startYear, startMonth have descriptions; url, title, description do not). The description does not compensate by explaining these parameters or noting that title is required. It adds no parameter-specific semantics beyond the general term 'publication'.
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 ('Add') and resource ('publication (paper, article, book)') with a clear target ('to the profile'). This clearly distinguishes it from sibling add_* tools like linkedin_add_award or linkedin_add_education.
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 its usage context—when you need to add a publication—but it provides no explicit guidance on when not to use it or how it differs from other add tools. With many sibling tools, explicit alternatives or exclusions would be helpful, but the current phrasing gives a reasonable hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that it lists 'open' jobs (filtering by status) but doesn't disclose pagination, sorting, or whether it requires authentication or has rate limits. Some behavioral context beyond annotations is provided but not extensive.
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 concise sentence that clearly states the action and scope. It earns its place with no wasted words, though it lacks additional structure like intended use cases.
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-only list operation with rich annotations and 100% schema coverage, the description is adequate. It doesn't explain return format or pagination, but the output schema is absent and annotations cover safety. A bit more context about typical use cases (e.g., 'Use to populate a company's job board') would improve it, but it meets the minimum threshold.
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 both `limit` and `company` are already well-documented. The description adds no additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate since 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 states a clear verb ('list') and resource ('open jobs posted by a specific company'), which is specific enough to understand the core function. It differentiates from siblings like `linkedin_get_saved_jobs` and `linkedin_search_jobs` by scoping to jobs posted by a specific company, though it doesn't explicitly name alternatives.
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: when you need open jobs for a known company. It doesn't explicitly say when to use it vs `linkedin_search_jobs` or `linkedin_export_jobs`, but the company-specific scope is clear from the description and parameter name. No explicit exclusions or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description needs only to add context beyond those traits. It does add a useful nuance that followers may not be connections, which clarifies the returned relationship. However, it does not mention pagination, ordering, or what exact fields are returned, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's core function. It front-loads the action and resource, with no superfluous words or repetition of schema/annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and good annotation coverage, the description is reasonably complete. It explains the core behavior and the connection nuance, and the schema handles the limit parameter. Since there is no output schema, the description could have mentioned return format, but 'List people' implies a list of profiles, which is sufficient for this low-complexity 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?
The input schema covers the only parameter (limit) with a description ('Defaults to 50'), so schema coverage is 100%. The description does not add any additional meaning about the parameter, relying entirely on the schema. This meets the baseline for high schema coverage but does not exceed 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 clearly states the action ('List people who follow the signed-in user') and specifies the resource scope ('followers'), distinguishing it from the sibling tool 'linkedin_get_following' by indicating direction ('follow the signed-in user'). It also clarifies that followers need not be connections, adding subtle differentiation from 'linkedin_get_connections'. However, it does not explicitly name alternative tools for when not to use it, so it falls short of 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 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 alternatives. It merely states its purpose without mentioning exclusions, prerequisites, or better-suited tools for similar scenarios. There is only an implicit inference that this tool is for viewing followers, but no 'when not to use' direction.
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?
The description explicitly states that deletion is irreversible and removes the thread from the user's inbox only, which is critical destructive behavior. However, the annotations declare destructiveHint=false, directly contradicting the description. This is a serious inconsistency that undermines the agent's ability to assess the tool's safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action list, and each sentence carries meaningful information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the main actions and the critical consequence of deletion. There is no output schema, but none is strictly needed. A minor gap is the lack of mention of permissions or errors, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for both parameters (action with enum values, conversation with id/URN/URL). The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs and resources: 'Archive, unarchive, mark read/unread, or delete a conversation.' It enumerates the exact actions and distinguishes itself from sibling tools like send_message or get_conversations.
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 the tool (for managing conversation state) but lacks explicit guidance on when not to use it or how it compares to alternatives. For instance, it doesn't mention that sending messages should use linkedin_send_message or that viewing history should use get_conversation_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one useful behavioral detail: 'School names are matched against LinkedIn's directory.' This goes beyond annotations by indicating potential validation or normalization behavior. However, it does not disclose other traits like duplicate handling, response format, or error behavior. Annotations already cover the read-only/idempotent/destructive hints, so this is acceptable but not rich.
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, no fluff. The first sentence delivers the core purpose; the second adds a relevant constraint. Front-loaded and appropriately sized for a simple add 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 9-parameter tool with no output schema, the description is minimal. It leaves open questions: what happens when a school doesn't match the directory? Does it fail or create an unrecognized entry? It also doesn't clarify whether all other parameters are optional (though the schema does). It is adequate for simple use but lacks enough context to anticipate real-world edge cases.
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 78%, so most parameters are already described in the schema. The description adds meaning only to the 'school' parameter by noting directory matching. Other parameters (grade, degree, dates, etc.) rely entirely on the schema. This is adequate but does not fully compensate for the remaining 22% of unannotated params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Add an education entry to the profile.' This clearly distinguishes it from sibling tools like linkedin_add_experience or linkedin_add_skill by naming the resource type ('education entry'). It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or suggest alternatives for other profile sections. It is a bare statement of function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the context that answers are from previous applications and can be reviewed/corrected, but it does not disclose potential staleness, pagination, or whether answers are per-company or global. With strong annotations, a 3 is fair.
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, fully front-loaded, with no filler. It clearly states the action and purpose. Slightly more detail on the output (e.g., 'answers' structure) could earn a 5, but as it stands it is concise and effective.
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 read tool with strong annotations, the description is mostly complete. However, it lacks specifics about what fields are returned or how corrections might be applied (e.g., via a separate tool like linkedin_forget_answer). The output schema is absent, so a bit more detail on return value 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 zero parameters, so schema coverage is 100%. The description explains the resource being listed, which is useful for understanding what the empty parameter set means. Baseline for 0 params is 4, and the description adds minimal but adequate context.
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 lists remembered screening-question answers for review/correction before next batch, using specific verb+resource. It doesn't explicitly distinguish from sibling linkedin_forget_answer, but the purpose is clear and unique enough among the large sibling list.
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 (review/correct before next batch) but does not explicitly mention alternatives or when not to use. Given the sibling tool linkedin_forget_answer likely manages these answers, some guidance would help but is not critical for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false, destructiveHint=false). The description adds the important detail that it can both follow and unfollow based on the 'follow' parameter, which goes slightly beyond the tool name. However, it does not disclose any other behavioral nuances (e.g., auth requirements, error conditions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is immediately front-loaded with the action and target. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and good annotations, the description is sufficient. It covers the core functionality without needing to elaborate on return values or complex behavior. Minor missing context could include what happens if company is not found, but given the tool's simplicity, the completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-described ('follow' boolean semantics, 'company' accepted formats). The description itself adds no parameter-level detail, but per baseline for high coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Follow or unfollow') and the specific resource ('a company page'), distinguishing it from sibling tools like the generic 'linkedin_follow' or other company-related tools. This is a specific verb+resource pairing.
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 offers no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contrast with similar tools like 'linkedin_follow' or 'linkedin_get_company'. There is no context about when following/unfollowing would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds that the tool uses 'title patterns' to find contacts, which is useful behavioral context, but it does not disclose possible limitations like pagination or empty results. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose ('Find recruiters and hiring contacts at a company'), and immediately followed by a practical application. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with rich annotations and well-documented parameters, the description covers purpose, method, and use cases. It could be more complete by differentiating from similar siblings or describing what the result list looks like, but overall it provides sufficient context for a simple 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 coverage is 100%: both 'company' and 'limit' have descriptions. The tool description does not mention parameters at all, so it adds no semantic value beyond what the input schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Find') and identifies the resource ('recruiters and hiring contacts at a company'), then explains the identification method via 'title patterns.' It is clear, but it does not distinguish the tool from similar siblings like linkedin_find_recruiters or linkedin_get_company_employees.
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 states a practical use case ('address a cover letter... or send targeted outreach'), which implies when to use it. However, it does not explicitly say when not to use it or compare it to alternative tools for finding people, such as linkedin_search_people or linkedin_find_recruiters.
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?
Beyond the annotations (readOnly=false, destructive=false), the description adds no behavioral details such as side effects, required permissions, or error conditions. The only extra context is 'by its id', which is parameter semantics rather than behavior. With annotations already indicating a non-read-only, non-destructive action, the description contributes little.
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 immediately conveys the tool's purpose with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with annotations and full schema coverage, the description is complete enough. It explains the core action and identifies the target conversation. No output schema exists, so return values are not described, but that is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (conversation, text) with 100% coverage. The description's mention of 'by its id' reinforces the conversation parameter but adds no new detail beyond the schema.
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 ('Send') and resource ('message into an existing conversation thread'), and specifies it operates by the thread's id. This distinguishes it from sending new messages (e.g., linkedin_send_message) by emphasizing 'existing conversation thread'.
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 that this tool is for replying to an existing conversation thread, but provides no explicit guidance on when to use it over related tools like linkedin_send_message or linkedin_manage_conversation. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no further behavioral context—no mention of side effects, idempotency, permissions, or reversibility—so it fails to add value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and purpose without any wasted words. It is appropriately concise for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one well-documented parameter and no output schema, the description covers the essential purpose and behavior. It could mention whether saving is idempotent or requires authentication, but for a straightforward bookmark action, the current level of detail is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a detailed parameter description (URN, numeric ID, or URL accepted). The main description merely says 'post' and does not add any semantic nuance, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Bookmark' and names the resource 'a post to the user's saved items', which clearly distinguishes this from sibling saving tools like linkedin_save_job (saves jobs) and linkedin_save_draft (saves drafts). The action and target are unambiguous.
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 phrase 'for later reading' implies the intended use case, but the description does not explicitly contrast this with alternatives such as linkedin_save_job or explain when to choose this over other save mechanisms. It provides context but no direct comparison or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat safety. It adds that the tool exports results in specific formats, which is useful context beyond the schema. However, it does not disclose details like whether the output is a file download, how pagination or limit works, or any potential side effects beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word contributes meaning, with no redundant information or filler.
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 relatively simple with three parameters and good annotations, but the description lacks details on the return value or how the export is delivered. It also does not clarify when to use this vs. the similar linkedin_export_search_results tool. While the core purpose is clear, the description is not fully complete for an agent to confidently invoke it without additional assumptions.
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 0% schema description coverage, the description must compensate for parameter meaning. It implicitly clarifies that 'query' is the search term and 'format' is one of JSON/CSV/Markdown, which matches the enum. However, it does not explain 'limit' or the exact semantics of each parameter, leaving some gaps. The description adds some value but does not fully document all parameters.
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 specific verbs and resources: 'Search companies and export the results to JSON, CSV or Markdown.' It clearly states the action (search and export) and the resource (companies), and differentiates from sibling tools like linkedin_search_companies (which likely only searches) and linkedin_export_search_results (which may export other types).
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 use case—when you need to search for companies and export the results—but it does not explicitly say when to use this tool over alternatives like linkedin_search_companies or linkedin_export_search_results. No exclusions or alternative recommendations are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the context of optionally including full message history, which hints at a potentially heavier operation, but does not disclose performance impacts, rate limits, or output handling. This is minimal additional context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and purpose. It lists the output formats and the optional message history without any wasted words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only three parameters, the description covers the core function but leaves gaps such as how the data is returned or saved (e.g., does it return a file path or the data itself?), default behavior, and potential limitations like rate limits. The annotations and schema fill some gaps, but the description alone is not fully complete for an agent to understand all invocation nuances.
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 descriptions for limit and includeMessages, and an enum for format. The description summarizes the format options and mentions full message history, but these are largely redundant with the schema. It does not add new meaning for the limit parameter, so the added value is marginal.
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 exports conversations, optionally including full message history, to JSON, CSV, or Markdown. The verb 'export' plus the resource 'conversations' and the explicit output formats make the purpose unmistakable and distinguish it from sibling tools like get_conversations or search_conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting conversation data to files, but does not explicitly state when to use this tool over alternatives such as get_conversations or search_conversations. There is no mention of exclusions or specific scenarios, so the agent must infer the appropriate context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive, so the safety profile is covered. However, the description adds no additional behavioral context such as pagination, ordering, or whether results are live or cached, leaving the tool's runtime behavior fairly opaque.
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, direct sentence with no filler or redundancy. It is appropriately front-loaded with the main action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter, a brief description is sufficient. The annotations and schema provide additional context, and no output schema is present, so the description need not elaborate on return values. The tool's scope is fully captured.
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 sole parameter 'limit' is fully described in the schema (default 50, min 1, max 200), so schema coverage is 100%. The description adds no extra parameter nuance, matching the baseline score for tools where the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and specific resource ('jobs the user has saved on LinkedIn'), distinguishing it from related tools like get_applied_jobs and search_jobs. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool—to fetch the user's saved jobs—but it does not explicitly discuss alternatives or exclusions. Since the purpose is self-evident for this simple read operation, the usage guidance is adequate but not 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description doesn't need to re-state safety. It does add 'with engagement metrics' as included data, but does not disclose return format, file behavior, or any side effects beyond what annotations cover. Given the annotation coverage, a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action, output formats, and a use case. There is no redundant information or filler, making it highly concise and well-structured.
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 with 3 optional parameters and no output schema. The description covers the main purpose but omits details about limit semantics, default behavior, and what the exported file actually contains or returns. Without an output schema, the description should at least hint at return structure, which it does not. Overall, it's adequate but incomplete for an agent to use with full confidence.
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 'identifier' has a description). The description mentions JSON/CSV/Markdown, which maps to the format enum, but it does not explain the 'limit' parameter (e.g., max 100) or clarify identifier's default. Since coverage is low, the description must compensate, and it does not adequately do so.
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 exports posts with engagement metrics to JSON, CSV, or Markdown files. It specifies a distinct verb ('Export') and resource ('posts'), and the file formats distinguish it from generic post retrieval tools like get_posts. The use-case 'analysing which content performed best' adds useful context.
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 phrase 'useful for analysing which content performed best' provides clear context for when to use this tool, indicating it's appropriate for performance analysis. However, it does not explicitly contrast with alternatives like get_posts or other export tools (e.g., export_profile), so it lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds context about 'locally saved' and 'not yet published,' which is useful but minimal. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the verb 'List' and immediately clarifies the resource and scope. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with rich annotations and high schema coverage. The description conveys the core purpose clearly. It could optionally mention output format or link to save/publish operations, but for a straightforward list tool, this is sufficient.
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% for the single optional boolean parameter includePublished, which is fully described in the schema. The description does not add parameter details, but the schema already carries that burden, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource combination: 'List' + 'locally saved post drafts' and adds the scope 'that have not yet been published.' This clearly distinguishes it from sibling tools like linkedin_get_posts (published posts) and linkedin_save_draft (saving/creation).
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 the tool (when you need to see drafts) but does not explicitly state alternatives or exclusionary conditions. It doesn't mention related tools like linkedin_save_draft, linkedin_publish_draft, or linkedin_delete_draft, which could be relevant for the agent to choose the right operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the search criteria context but does not disclose additional behavior such as result ordering, pagination, or whether it searches only current conversations or archived ones. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the core function. Every word earns its place with zero filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two well-documented parameters and strong safety annotations, the description adequately conveys the tool's purpose. However, since there is no output schema, it does not mention the return format (e.g., list of conversation IDs vs full messages), which would be useful but not critical given the straightforward nature of the 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 coverage is 100% and both parameters have rich descriptions ('query' matches message content and participant names; 'limit' defaults to 20). The description merely restates the search criteria already present in the schema, adding no new semantic detail.
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 ('Search') and clearly identifies the resource ('message inbox') and search criteria ('by keyword or participant name'). This unambiguously distinguishes it from sibling tools like linkedin_get_conversations (list) and linkedin_get_conversation_history (view messages in a specific conversation).
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 (searching messages when you need to filter by keyword/participant), but it does not explicitly state when to prefer this tool over alternatives like linkedin_get_conversations or linkedin_export_conversations, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, indicating a write operation. The description adds no further behavioral details such as authentication requirements, profile visibility, or potential duplication. It does not contradict the annotations, but also does not enrich them beyond the obvious 'add' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and purpose. It is front-loaded with the essential information and contains no redundant words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward mutation tool with fully documented parameters and annotations, this description provides enough context for an agent to select and invoke it correctly. It omits details about return values, but since there is no output schema and the operation is simple, this is not a significant gap. The description could mention potential side effects, but the annotations already indicate a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are already explained in the schema. The description does not add any parameter-specific meaning or clarify formats, dates, or constraints. With full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a project to the profile') and provides specific use cases ('portfolio work, open source and side projects'). This distinguishes it from sibling tools like linkedin_add_skill or linkedin_add_experience, which are also in the same family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explicitly mentioning when it's useful ('portfolio work, open source and side projects'). It does not name alternatives or specify when-not-to-use, but the context and tool name sufficiently guide the agent. No exclusions are stated, but the use cases are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=false), the description discloses that the comment is public and attributed to the signed-in user, and advises confirming wording. This adds meaningful behavioral context that annotations do not capture. It does not mention rate limits or error conditions, but covers the important social/side-effect aspects.
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 short sentences, front-loaded with the core action and immediately followed by key constraints. Every clause earns its place, and there is no redundant filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter write operation, the description is largely complete: it states the action, maximum length, public visibility, attribution, and a user-confirmation requirement. It lacks return-value or error details, but no output schema exists and the tool is simple enough that these are not critical; still, a small gap remains regarding what happens after posting.
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 the schema already describing both 'post' and 'text' including accepted formats and max length. The description only restates the max character limit, adding no extra semantic value beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Add a comment to a post.' This distinguishes it from sibling tools like linkedin_reply_to_comment (which targets comments) and linkedin_create_post (which creates posts). The action 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about the action being public and attributed to the user, and advises confirming wording. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusions, so usage guidance is mostly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive and non-idempotent behavior. The description adds that the tool targets a single notification using substring matching, which is useful operational context. It doesn't restate consequences already indicated by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, with no extraneous words. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with robust annotations and schema, the description covers the core action and identification method. It omits edge-case behavior (e.g., no match or multiple matches) but is otherwise sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented. The confirm parameter explicitly states it must be true and that the action is irreversible. The tool description adds no additional parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('a single notification'), and adds the matching mechanism ('matched by a distinctive substring of its text'). This distinguishes it from sibling tools like get_notifications or mark_notifications_read.
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 (delete notifications by substring) but does not explicitly contrast with alternatives or mention prerequisite steps like retrieving notifications first. It lacks 'when to use vs. not use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. The description adds value by disclosing that reactions and comments are also deleted and emphasizing irreversibility ('This cannot be undone'), which goes beyond the annotation signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences immediately convey the action and consequences, with no redundant or extraneous information. The description is front-loaded with the main action and irreversible impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool, the description covers the essential behavior and consequences. It lacks an explicit mention of the confirm parameter's requirement, but this is fully documented in the schema. Given no output schema and low parameter count, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for both 'post' (URN, numeric ID, or URL) and 'confirm' (must be true, ask user). The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: permanently delete one of your own posts, including reactions and comments. This specific verb+resource combination distinguishes it from sibling delete tools like linkedin_delete_draft and linkedin_delete_notification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting one's own LinkedIn posts but does not explicitly state when to use this tool versus alternatives (e.g., edit_post) or provide exclusions. The phrase 'own posts' offers context, but no explicit alternative guidance is given in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, non-destructive, open-world behavior. The description adds that edits are in place, index-based, and partial-update only, which goes beyond annotations. However, it does not disclose error behavior for invalid indices or what happens to unspecified fields beyond 'not changed', lacking deeper side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and every sentence adds operational value—state main purpose, prerequisite, and update semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core workflow (fetch profile to get index, edit in place, partial update), which is sufficient for a 3-parameter tool. It lacks only error-case details, but with no output schema and good schema coverage, this is not a critical gap.
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%; all parameters (section, index, fields) are described in the schema, including the recognized keys for fields. The description reinforces the index semantics by telling the agent to call get_profile first, but this is more usage guidance than new parameter information. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Edit' with the resource 'existing profile entry', clearly distinguishing from sibling add/delete tools. The 'in place' phrase and zero-based index addressing clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call linkedin_get_profile first to see the current order, providing a clear prerequisite. It also explains partial update semantics ('Only the fields you supply are changed'), but does not name alternative tools for adding or deleting entries, so it's clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds context about producing a structured file in different formats, but it does not clarify how the file is delivered (e.g., returned content vs. saved path) or any other behavioral details beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and purpose. It avoids unnecessary words and clearly communicates the tool's value proposition without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description provides sufficient context: what it does, output formats, and typical use cases. It does not explain return value details, but that is less critical given the clear purpose and annotation coverage.
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 both parameters (format and identifier). The description mentions the file formats (JSON, CSV, Markdown) which aligns with the format parameter, but it adds little beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Export a full profile to a structured file (JSON, CSV or Markdown)'. It specifies the resource (full profile) and the action (export), and distinguishes it from sibling tools like linkedin_get_profile by emphasizing file output for downstream use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'for downstream use — archiving, feeding another tool, or handing to a resume builder.' This implies using it when a file export is needed, but it does not explicitly state alternatives or when not to use it, so it lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=false and destructiveHint=false, so the description does not need to restate that this is a non-destructive write. The description adds useful behavioral context (following shows posts in feed, does not require a connection, and the tool can both follow and unfollow), but it omits other potential side effects or requirements (e.g., authentication, notifications). This is moderate added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the purpose and value proposition, with no redundant or filler content. It is well-structured, front-loading the primary action and then providing contextual benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, this description is sufficiently complete: it explains what the tool does, when to use it, and the effect of following. It could go deeper into edge cases (e.g., what happens when unfollowing), but given the low complexity and full schema coverage, it covers the essential context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for both parameters, clearly documenting the 'follow' boolean and the 'identifier' variants. The tool description adds minimal parameter-specific meaning beyond the schema—it only reinforces the follow/unfollow action. Since the schema fully carries parameter semantics, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Follow or unfollow a person') and the resource (a person), which distinguishes it from the sibling tool linkedin_follow_company. It also explains the purpose—seeing posts in the feed without a connection—which further contrasts with connection request tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers strong contextual guidance by indicating this tool is useful for people who do not accept invitations, implying when to follow instead of sending a connection request. However, it does not explicitly name alternative tools (e.g., linkedin_send_connection_request) or state when not to use it, so it falls short of fully explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the destructive nature is known. The description adds the rationale for deletion (wrong answer) but does not disclose irreversibility or the confirm requirement, which is instead covered by the schema parameter description. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, with an illustrative example. Every word earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple destructive tool with strong annotations and full schema coverage. The description covers the purpose and typical use case well. The only minor gap is not explicitly stating the confirm requirement, but that is fully handled by the schema and the tool remains clear enough for an agent.
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%; both 'confirm' and 'question' have detailed descriptions including irreversibility and loose matching. The tool description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' with a clear resource ('a remembered screening-question answer') and includes a concrete example ('after it turns out to be wrong'). It clearly distinguishes this tool from siblings like add/delete profile sections or skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('after it turns out to be wrong'), implying a corrective workflow. However, it does not explicitly mention alternatives (e.g., linkedin_get_remembered_answers for viewing) or state 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?
Annotations already provide strong safety signals (readOnlyHint, destructiveHint false, idempotentHint). The description adds no additional behavioral details such as pagination, rate limits, or data scope beyond the 'optionally filtered by job title' note. It is consistent with annotations but does not deepen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first states the core function, the second provides practical use cases. No fluff or repetitive information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description provides sufficient context: what it lists, optional filtering, and common use cases. It does not explain return fields or pagination, but given the simple nature and strong annotations, the description is complete enough for an agent to select and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's only parameter-related addition is 'optionally filtered by job title', which is redundant with the schema's 'Filter by job title'. It adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List people who work at a company' and adds 'optionally filtered by job title', which clearly distinguishes it from sibling tools like search_people or get_company. It also provides concrete use cases (warm introductions, hiring managers, peers), reinforcing its specific purpose.
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 explains when to use the tool ('finding warm introductions, hiring managers, or peers in a target team') but does not explicitly contrast it with alternatives or mention when not to use it. It gives context but lacks explicit exclusion or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds detail about what the list contains (participants, last message, unread status) but does not disclose pagination, rate limits, or other behavioral nuances.
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: first states the action and key data points; second gives usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two optional parameters and no output schema, the description covers purpose, return content, and usage context. Lacks pagination details but sufficient for selecting and invoking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit, unreadOnly) are fully described in the schema, so the description adds no additional parameter semantics. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'message conversations' and specifies return fields (participants, last message, unread status), clearly distinguishing it from siblings like linkedin_get_conversation_history and linkedin_search_conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to triage the inbox before reading or replying to specific threads,' giving a clear when-to-use context. However, it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the specific metrics returned, but it does not clarify edge cases such as whether the pending invitation count includes both sent and received invitations, or if the counts have any pagination or rate-limit implications. This is a minor gap given the simple read-only nature.
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 that front-loads the action and lists the key output metrics without any filler or repetition. It is appropriately sized for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema) and rich annotations, the description is nearly complete. It clearly states what the tool returns (three specific count types). It does not describe the output format (e.g., JSON structure), but that is not essential for a simple summary tool. A tiny bit more detail on the semantics of 'pending invitation counts' would make it fully complete.
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 the schema is empty with 100% coverage, so the baseline is 4. The description correctly focuses on the output rather than inputs, and no parameter documentation is needed.
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 ('Summarise') and identifies the exact resource ('network size') with the metrics included (connection count, follower count, pending invitation counts). This clearly distinguishes the tool from sibling getters like get_connections, get_followers, and get_invitations, which return full lists rather than aggregated counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a quick numeric overview of network size, but it does not explicitly state when to prefer this tool over alternatives or provide any exclusions. With zero parameters, the use case is straightforward, but there is no direct comparison to 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the output format (grouped by category, flags for read-only/mutating/destructive) but does not disclose additional behavioral traits beyond what annotations provide.
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, first states the core action, second gives usage context. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema. The description explains the purpose, grouping, and flags, which gives a good sense of the return structure. It could mention that the output is a list of tool names, but it's sufficient for the simplicity.
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 the schema already describes the optional 'category' parameter with examples. The description does not mention the parameter, but the baseline of 3 applies when schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), clearly identifies the resource ('every tool this server exposes'), and specifies output structure ('grouped by category, with flags'). This distinguishes it from sibling tools that perform LinkedIn actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'Useful for orienting before planning a multi-step workflow.' It does not explicitly state when not to use it, but there are no direct alternatives for this meta-tool, so the context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation, and the description adds valuable behavioral context: 'Paces sends and stops on quota or session failures.' It also warns that this 'contacts real people on the user's behalf,' which appropriately raises the stakes for an agent.
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?
Three sentences, each earning its place: the first states the action, the second covers pacing and failure handling, and the third delivers the critical human-impact warning. It is front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and real-world messaging impact, the description covers the key operational behaviors (pacing, quota stops, personalization, and safety confirmation). It does not describe output/return behavior, but the absence of an output schema makes that less critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces how the message parameter works ('personalising from the user's profile unless a fixed message is supplied'), but that detail is already present in the schema. No additional parameter-specific meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific compound action: 'Find recruiters hiring for a role and message each one,' which clearly differentiates it from siblings like linkedin_find_recruiters (find only) and linkedin_send_message (message only). It also specifies the personalization behavior, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (finding and messaging recruiters) and provides a strong safety guideline to confirm recipients before invoking. However, it does not explicitly state when to choose this over alternatives such as linkedin_find_recruiters or linkedin_send_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds the specific consequence of removing endorsements, which is not captured by the annotations. This extra detail clarifies the scope of the destructive action, though it doesn't mention the confirm parameter (which is in the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and includes a meaningful secondary effect. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with a destructive annotation and a required confirmation parameter documented in the schema, the description sufficiently covers the core behavior and the endorsement side-effect. It doesn't need to explain return values since no output schema exists, and the tool's complexity is low.
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 both 'skill' and 'confirm' having descriptive comments. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with a clear resource ('skill from the profile') and adds a distinctive detail (endorsements) that differentiates it from related tools like linkedin_add_skill and linkedin_delete_profile_section.
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 use case (removing a skill) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The context is clear from the name and siblings, but the description itself lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only and non-idempotent, so the description does not need to restate that. It adds a useful behavioral prerequisite (fetch comments first) but does not disclose further behaviors such as reply visibility, error conditions, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, starts with the core purpose, and includes only necessary procedural context. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with fully documented parameters and annotations, the description provides the core purpose, the index-addressing mechanism, and the required prerequisite call. It could mention return behavior or error handling, but the description is otherwise sufficient for an agent to invoke the tool correctly.
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 all three parameters fully described. The description merely repeats the zero-based index note from the schema and adds the prerequisite to get_post_comments, which is already in the parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reply to a specific comment on a post') and distinguishes it from sibling tools like linkedin_comment_on_post by emphasizing 'specific comment' and zero-based indexing. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs the agent to call linkedin_get_post_comments first to determine the comment order, giving a clear prerequisite and workflow. It does not explicitly mention alternatives or exclusions, but the context is sufficient for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive operation. The description adds the dual behavior of saving and removing, which is valuable beyond the tool name. However, it does not mention edge cases like duplicate saves or prerequisite authentication, though annotations cover the safety profile partially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys both save and remove actions. No wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description plus schema and annotations provide sufficient context. The tool's behavior is clear, and the schema covers parameter specifics. Slight gap: no mention of expected response or side effects if already saved, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters fully described (job format alternatives, saved boolean with default). The description itself adds no additional parameter semantics, so baseline 3 is appropriate as the schema 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?
The description clearly states the tool saves a job to the user's saved list or removes it, using a specific verb and resource. This distinguishes it from sibling tools like save_post and get_saved_jobs, which handle different resources or 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 tool's use case is implied by its name and description, but there is no explicit guidance on when to use it versus alternatives or any exclusions (e.g., 'use get_saved_jobs to view saved jobs'). The usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true and destructiveHint=false, so the safety profile is well covered. The description adds useful ordering and scope detail ('oldest to newest', 'full message history'), but it does not disclose behavior like pagination, rate limits, or response structure beyond what annotations and schema imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action ('Read the full message history...') followed by a direct use-case instruction. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple read operation has minimal parameters, rich schema, and strong annotations. The description fully explains its purpose and usage context, making it complete for its scope without needing to detail return values or complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters (conversation accepts ID, URN, or URL; limit has range and default). The tool description adds no extra semantic value for parameters, matching the baseline of 3 since schema carries the burden.
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 reads 'the full message history of one conversation, oldest to newest.' The verb 'read' and resource 'message history' are specific, and the phrase 'one conversation' differentiates it from sibling tools like linkedin_get_conversations (which lists conversations) or reply/send tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to get context before composing a reply' provides clear, actionable context for when to invoke the tool. It implies a specific workflow but doesn't explicitly exclude other uses or mention alternatives like linkedin_search_conversations, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation. The description adds no extra behavioral context (e.g., pagination, auth requirements, rate limits), but given the tool's simplicity, this is adequate and not misleading.
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 no filler. It immediately states the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter, the description is complete. The annotations cover safety, the parameter schema covers the limit, and the return value (a list of people) is obvious from the description. No output schema is needed.
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%—the only parameter (limit) has a description ('Defaults to 50') and range constraints. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('people the signed-in user follows'). It distinguishes from similar sibling tools like linkedin_get_followers (who follows the user) and linkedin_get_connections (connections), leaving no ambiguity.
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 context is clear: use to retrieve the signed-in user's following list. However, it does not explicitly mention when not to use it or name alternatives (e.g., for connections use get_connections). No exclusions are stated, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about the specific notification categories and a tip for unreadOnly, but does not disclose behavior beyond what annotations and parameter descriptions already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word adds value. It avoids redundancy with the schema and annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no required parameters and full schema coverage, the description adequately conveys what the tool does and how to use the main option. No output schema is expected for such a tool, and return format is not critical for selection.
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 both parameters (limit, unreadOnly) have descriptions in the schema. The description's mention of unreadOnly as 'triaging what is new' aligns with the schema's 'Only return unread notifications' without adding new semantic depth.
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 'Read LinkedIn notifications' with a specific verb and resource, and lists content types (reactions, comments, invitations, job alerts, profile views). This distinguishes it from sibling tools like linkedin_delete_notification and linkedin_mark_notifications_read, which operate on notifications differently.
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 implies usage context by defining what the tool reads and suggests 'Use unreadOnly to triage only what is new,' which provides practical guidance. However, it does not explicitly mention when not to use this tool or point to alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and 'Read' aligns with these. The description adds little behavioral context beyond the input formats (already in schema) and the vague 'in detail'; no additional side effects, rate limits, or return structure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys action, object, and input variations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, full schema coverage, strong annotations, no output schema), the description is complete. It tells the agent exactly what the tool does and how to specify the target post; 'in detail' sufficiently hints at the return richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'post' parameter fully documenting the accepted forms. The description's mention of the same three formats adds no new semantic value beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the object ('a single post'), and the level of detail ('in detail'). It lists three accepted input formats (URN, activity id, URL), which distinguishes it from siblings like linkedin_get_posts (plural) and linkedin_get_post_comments.
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 implies use for retrieving one specific post, differentiating from plural list tools. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two useful behaviors: it attaches any media recorded with the draft, and it marks the draft as published on success. These add context beyond the annotations (which only state that the operation is not read-only, not destructive, and not idempotent). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, action-first, and entirely relevant. It states the primary action, a supporting detail about media, and the resulting state change without any redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publish action with two parameters, the description covers the essential side effect (draft marked published) and media handling. It omits error cases or return values, but the lack of an output schema and the simple scope make this adequate without being excessively detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 50% coverage: draftId is described, but visibility is an undocumented enum. The description does not explain the visibility parameter or its possible values, nor does it mention any defaults. It adds no parameter semantics beyond what the schema already provides, leaving a 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 clearly states the tool publishes a previously saved local draft to LinkedIn, which is a specific action on a specific resource. It distinguishes itself from sibling tools like linkedin_save_draft and linkedin_delete_draft by focusing on the publish action.
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 phrase 'previously saved local draft' implies the intended use: after a draft has been saved with linkedin_save_draft. It does not explicitly mention when not to use it or alternatives like linkedin_create_post, but the draft-focused context provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: company names are matched against LinkedIn's company directory, and ongoing roles require current=true with no end date. This gives the agent insight into expected validation behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling 31 words. Front-loaded with the core purpose, then provides key behavioral notes. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema and annotations, the description is sufficient for an add tool. It covers the main purpose and important matching behavior, though it doesn't discuss failure modes or specifics of the output (no output schema exists).
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 90%, and the relevant parameters (current, endMonth, etc.) are already described in the input schema. The description's guidance on current/end date largely repeats the schema's own notes, so it adds little semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a work experience entry to the profile' with a specific verb and resource. It distinguishes from sibling add_* tools by explicitly mentioning work experience and the company directory matching behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use—adding a work experience entry—and gives a concrete usage guideline (set current=true and omit end date for ongoing roles). Does not explicitly name alternatives, but the purpose is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond annotations by explaining that the score is computed by this server from section presence/substance and is not LinkedIn's own metric. This prevents misinterpretation and clarifies the tool's internal logic.
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, both purposeful: the first states the core action, the second clarifies the metric origin and provides a use-case example. No fluff, front-loaded with the main verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers a single-parameter tool with no output schema. It explains what it does, how the score is computed, and when to use it. It could mention the exact return format (e.g., score plus list of suggestions), but 'return specific, actionable improvement suggestions' already implies the 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 description coverage is 100%, with the single 'identifier' parameter fully documented (me, public identifier, URL, or URN). The description does not add extra parameter semantics, but the schema already carries the burden, so baseline 3 applies.
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 ('Score profile completeness') and resource ('profile') and clearly distinguishes itself from siblings like linkedin_get_profile or linkedin_get_profile_analytics by focusing on actionable improvement suggestions. The explicit use case 'how can I improve my profile?' reinforces its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this to answer "how can I improve my profile?"' which implies the tool is for profile improvement advice. It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-idempotent operation. The description adds useful behavioral context: it reloads cookies from a file/env source, re-validates the session, and serves as an alternative to server restart. It does not fully disclose failure modes, but the annotations cover the basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence contributes value: first defines what it does, second specifies the recommended usage scenario. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, the description adequately covers purpose, usage context, and the role of parameters. It lacks explicit mention of return values or failure behavior, but no output schema exists and the annotations provide safety context.
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 well-described parameters. The description does not add additional parameter details beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Reload cookies') and clearly states the action of re-validating the session. It distinguishes from sibling auth tools by referencing the 'configured source (file or environment)' and the recovery-from-expired-session use case.
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?
Provides explicit when-to-use guidance: 'Use this after the user has exported a fresh cookie file to recover from an expired session without restarting the server.' It does not explicitly mention alternatives, but the context of sibling tools like import_cookies is implied by the phrase 'configured source'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it destructive, and the description adds that it only affects the local store, not LinkedIn, providing scope beyond annotations. It doesn't contradict any annotation.
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 short sentences with no redundant wording; each sentence conveys distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with annotations and schema covering the confirm flag, the description adequately covers purpose and scope, though it could mention irreversibility directly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the confirm parameter with a clear description, but draftId has no description. The tool description adds no parameter-level detail, and with 50% schema coverage, it's adequate but not enhanced.
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 deletes a local post draft and explicitly scopes it to the server's store, distinguishing it from LinkedIn-post deletion tools like linkedin_delete_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clarifies the local scope (not affecting LinkedIn), which implies usage for local drafts, but it does not explicitly name alternatives or exclusion scenarios like published posts, so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate destructiveHint=true, the description explicitly states 'Permanently delete' and 'This cannot be undone', reinforcing the irreversibility. It also adds a verification step, going beyond the annotation by advising the agent to confirm before acting.
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 impactful sentences convey the essential information: the irreversible action and the recommended prerequisite. There is no redundant or tangential content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with annotations and a complete schema, the description sufficiently covers what the agent needs to know: verification step, irreversibility, and the index-based addressing. It could mention response behavior or error cases, but those are not critical for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with clear descriptions for all parameters (index, confirm, section). The description's mention of 'zero-based index' and 'within the section' aligns with but does not add significant new meaning beyond what the schema offers.
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 ('delete') and identifies the resource ('profile entry') within a section, clearly distinguishing this from sibling tools like add or edit operations. It also adds the zero-based index scope, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call linkedin_get_profile first to confirm the correct entry, providing a clear usage prerequisite. It does not mention exclusions or alternatives, but the context is strong enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations by noting that immutable post types are reported clearly rather than silently failing. The annotations only indicate non-read-only and non-idempotent, which aligns with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every phrase adds value including the caveat about immutable posts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, full schema coverage, and no output schema, the description covers the key caveat and error behavior, making it sufficient for a mutation tool. However, it doesn't describe the success response, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (post, text) have 100% schema description coverage, so the schema already provides full semantics. The description adds no extra parameter details beyond noting the text overwrites the entire body, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Replace' and names the resource 'text of an existing post', clearly distinguishing it from siblings like create_post and delete_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (editing text of an existing post) and when not (polls and some reposts), though it doesn't explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the agent knows this is a safe read operation. The description adds the format-export behavior but no additional latency, pagination, or file-handling context beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by use cases and a pointer to a sibling tool. Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no output schema, the description covers use case, output formats, and filter semantics. It could be more explicit about whether exporting returns file content directly or creates a file, but the format parameter and annotations reduce ambiguity.
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 only 44%, but the description compensates by stating it accepts the same filters as linkedin_search_jobs, giving semantic context to keyword, location, datePosted, and other search filters. Format and source are already described in the schema, and the cross-reference effectively fills the gap for the undocumented filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: run a job search and export results to JSON, CSV, or Markdown. It also distinguishes the tool by referencing the same filters as linkedin_search_jobs, making its job-specific purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It cites concrete use cases: building a pipeline spreadsheet or feeding another tool. It implies a relationship with linkedin_search_jobs by referencing its filters, though it doesn't explicitly state when to use this tool instead of searching or exporting search results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idiempotent, and non-destructive. The description adds behavioral context beyond annotations by explaining that matches include a recruiterScore and the signals behind it, and that recruiters are inferred from headline patterns. This gives the agent insight into the tool's operational quirks.
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 three sentences, each serving a distinct purpose: stating the main function, explaining the score output, and clarifying the inference approach. It is front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description gives the core return concept (recruiterScore and signals) but does not outline the full response structure or pagination. Given the tool's moderate complexity and good annotation coverage, this is largely sufficient, though a bit more detail about the result listing could make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all five parameters, so the description need not repeat parameter details. The description does add the concept of recruiterScore and its range, but this is already partially echoed in the minScore parameter description. It adds no new parameter-specific meaning beyond the schema.
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 'Finds recruiters relevant to a role or company' and reinforces its unique value with the recruiterScore explanation. It also distinguishes itself from generic search tools by noting LinkedIn has no 'recruiter' entity type and that inference is based on headline patterns, which separates it from siblings like linkedin_search_people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (when you need recruiters for a role/company) and explains its inference method, implying it is the appropriate choice over generic search. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds strong behavioral guarantees beyond the annotations: 'Every line comes from real profile data — nothing is invented' and the 'gaps field lists what could not be sourced.' This discloses data authenticity and output caveats that annotations don't cover. The potential file-writing side effect is left to the schema's save parameter, so not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, using two sentences to convey the core action, optional tailoring, authenticity guarantee, and actionable guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 optional parameters and no output schema, the description covers the essential context: what is built, the tailoring behavior, data provenance, and how to handle gaps. It omits output format details but those are in the schema, and the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have detailed schema descriptions (100% coverage), so baseline is 3. The description does not add extra meaning about parameters, though it references the output 'gaps' field, which is not a parameter.
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 begins with 'Build a structured resume from the user's actual LinkedIn profile' — a specific action on a clear resource. It also notes optional tailoring to a specific job, which distinguishes this from sibling tools like linkedin_list_resumes or linkedin_generate_cover_letter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when tailoring is appropriate ('optionally tailored to a specific job') and directs the agent to ask about or rewrite content from the 'gaps' field before sending. It does not explicitly contrast with sibling tools, but the use case is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral details beyond annotations: comments are returned 'in order' and each comment's index is significant for the reply tool, enriching the agent's understanding of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences with zero fluff. The first sentence states the purpose, and the second sentence provides crucial additional context about the output's relationship to another tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, good annotations, and no output schema, the description adequately covers the main purposes. It explains the reading behavior and the significance of indices. It does not describe the full comment object structure, but for a read operation with openWorldHint this is not critical.
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%; both 'post' and 'limit' parameters are fully described in the schema. The description does not add parameter-specific semantics beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the comments on a post, in order.' This clearly indicates the tool's function and distinguishes it from siblings like linkedin_get_post (which retrieves the post itself) and linkedin_comment_on_post (which writes a comment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual usage guidance by noting that the returned index is what linkedin_reply_to_comment expects, implying a workflow of fetching comments before replying. It does not explicitly mention when *not* to use this tool, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context about non-Premium restrictions and the policy of reporting unavailable data explicitly rather than guessing, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and key metrics, and the restriction caveat is concise and useful. No unnecessary words or repetition of structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the core data points and the handling of restricted data, giving an agent reasonable expectations for a read-only analytics tool. The explicit reporting behavior partially compensates for the lack of a formal return schema, though a bit more detail on response structure would make it fully complete.
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 the schema coverage is 100% (empty schema), so there are no parameter meanings to expand on. The description correctly focuses on the data returned rather than parameters, matching the baseline for zero-parameter tools.
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 'Read profile analytics' and enumerates specific metrics (profile views, post impressions, search appearances, follower count), making it distinct from sibling tools like get_network_stats or get_profile. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes a limitation ('LinkedIn restricts several of these for non-Premium accounts') and mentions how unavailable data is handled, but it does not explicitly compare against alternatives or state when to use this tool versus other analytics or profile-related tools. Usage context is implied but not explicit with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only false, destructive false, idempotent false), the description adds a valuable behavioral detail: calling on an already-liked post is a no-op rather than an error. This is contextual information the annotations do not capture, though it does not disclose all potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every phrase earns its place: what it does, the reaction options, the default, and the no-op behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with rich schema descriptions and reasonable annotations, the description covers the essential context: purpose, options, default, and an edge-case behavior. It lacks explicit return-value information, but no output schema exists and this is often unnecessary for write operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters, including accepted post formats and the reaction enum with default 'like'. The description repeats the default and reaction list but adds no meaning beyond the schema; the no-op behavior is about the operation, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action, 'React to a post', and clearly distinguishes the resource and scope. It enumerates the available reactions and notes the default, making the tool's purpose unmistakable and differentiating it from siblings like linkedin_comment_on_post or linkedin_save_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: reacting to a post with a specified reaction type, defaulting to Like. It does not explicitly name alternatives or exclusions, but the action is straightforward and the no-op note clarifies a use case edge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive action. The description adds valuable behavioral context by explaining the two distinct outcomes (instant repost vs. quoted post), which goes beyond what the annotations convey. It does not cover rate limits or visibility, but for this simple action, the disclosed traits are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, and every clause adds value. The conditional explanation is compact and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema and good annotations, the description covers the core behavior and both modes. It lacks details on side effects like posting visibility or potential duplicates, but is sufficiently complete for an AI agent to invoke correctly.
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 detailed parameter descriptions for both 'post' and 'thoughts'. The tool description repeats the effect of 'thoughts' but adds little beyond the schema. Baseline 3 is appropriate since the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Repost (reshare) someone else's post.' It then distinguishes two modes (instant vs. with thoughts), which clearly differentiates it from siblings like linkedin_create_post, linkedin_comment_on_post, and linkedin_react_to_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each mode: omit 'thoughts' for an instant repost, include it to create a new post quoting the original. It does not explicitly name alternatives, but the distinction is sufficient to guide selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds little behavioral detail beyond the core transformation; it does not mention error behavior, output format specifics, or rate limits. Acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and every clause adds value—clarifying when to use it and why. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only resolver with no output schema, the description covers what it does, when to use it, and the parameter format. It lacks explicit return-value structure, but 'geo id/URN' gives adequate context for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a description and example ('Berlin, Germany'). The tool description adds minimal extra semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resolve') and the specific resource ('a place name to LinkedIn's internal geo id/URN'). It also distinguishes this from sibling search tools by noting they resolve locations automatically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when not to use it ('Most callers do not need this') and identifies the alternative ('the search tools resolve locations automatically'), then gives a concrete use case ('useful for building precise filters by hand').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a useful behavioral trait—invitation list reordering—which explains why indexes are not used. It complements annotations by emphasizing non-read-only, non-idempotent operation without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, followed by a key usage warning. Every word earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema descriptions and no output schema, the description is adequate. It covers the operation, identification method, and a behavioral caveat, making it complete for the task.
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 baseline 3 is appropriate. The description adds minimal extra meaning beyond the schema, only reinforcing that person is a name or public identifier. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accepts or ignores a received connection invitation, using specific verbs and a clear resource. It distinguishes itself from sibling tools like send_connection_request and withdraw_invitation by focusing on responding to received invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use for received invitations, identify by name or public identifier. It does not explicitly mention alternatives or exclusions, but the 'invitation list reorders' note guides usage effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false), the description discloses that messaging outside the network requires InMail and that the tool will explicitly indicate when that is the blocker. It also mentions the max character limit. This adds useful behavioral context without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the main action, and each sentence adds value: purpose, InMail context, and character limit. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key behavioral aspects (conversation initiation/continuation, InMail blocker, max length) and is reasonably complete for a messaging tool. It lacks details on return values or error handling beyond the InMail note, but the schema and annotations cover safety, so this is sufficient.
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 each parameter is already described in the schema (text, subject, identifier). The description only repeats the max length and adds no new semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a direct message to a person, with a specific verb and resource, and distinguishes itself from siblings like linkedin_reply_to_conversation by covering both new and existing conversations. The InMail note adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for use: starting or continuing a conversation, and mentions the InMail requirement for out-of-network recipients. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false) and non-destructive. The description adds value by clarifying the toggle behavior and the effect of enabling versus disabling, including visibility options (everyone vs. recruiters). It does not contradict annotations, and the additional context around the recruiter-only visibility is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core action, and the second explains optional configurations. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward toggle tool with a well-documented schema and annotations, the description provides sufficient context. It explains the main effect, optional parameters, and visibility semantics. Lack of an output schema is not an issue here, and return values are not essential for this type of state change.
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 detailed descriptions for all four parameters. The description adds a small semantic layer by stating that titles and locations are relevant 'when enabling' and that visibility determines badge audience, but it largely repeats schema information, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Turn the "Open To Work" signal on or off.' It names the specific resource and action, and it distinguishes itself from sibling tools like linkedin_update_headline or linkedin_add_experience by focusing on this unique signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when controlling the Open To Work state. It explains that enabling allows specification of job titles, locations, and visibility. However, it does not explicitly mention when not to use it or name alternatives, though siblings make the tool's unique role evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds behavioral context by specifying that it clears the in-memory cache and restarts the browser. It does not contradict annotations and provides extra clarity about what the tool actually does, though it could mention potential side effects like re-authentication after a restart.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and then followed by usage context. Every sentence earns its place with no redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three optional boolean parameters and no output schema, the description is largely complete. It explains what the tool does and when to use it. However, it omits potential side effects of restarting the browser (e.g., needing to re-login) and does not highlight the resetQuotas caution in the main description, though the schema covers that. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (clearCache, resetQuotas, restartBrowser) already well-described in the schema. The main description does not add parameter-specific semantics beyond the schema, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs and resources: 'Clear the in-memory cache and/or restart the browser.' This distinguishes it from all sibling tools, which are LinkedIn data operations, making it a unique system-level maintenance tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: 'when reads seem stale after an out-of-band change, or when browser automation starts failing repeatedly.' This provides clear context, but it does not mention alternatives or when not to use it, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a non-read-only operation. The description adds valuable context beyond annotations: it warns of 'real privacy consequences' from mis-clicks and notes LinkedIn's UI instability. This gives the agent an important risk perspective.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, no fluff. Every clause adds value: the safe settings are enumerated, and the manual-only boundary is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter mutation tool with annotations and full schema coverage, the description covers purpose, scope, and risk. It lacks a note about return value, but that's not essential here given the output schema is absent and the action is straightforward updates.
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 already documents allowed values for both settings. The description adds minimal meaning by explaining 'how you appear when viewing others' for profile-viewing-mode, but doesn't elaborate on value semantics. Meets baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Change' and identifies the exact settings ('profile-viewing-mode' and 'open-to-work-visibility'), with a brief explanation of each. This clearly distinguishes it from read-only siblings like linkedin_get_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states these are 'one of the few settings that can be automated safely' and that everything else 'must be changed manually,' providing clear when-to-use and when-not-to-use guidance. It doesn't name specific alternate tools, but the exclusion of other settings is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds functional transparency by specifying the analysis outputs (match score, skills, keyword coverage, recommendations), giving the agent a clear picture of what the tool computes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. The first sentence front-loads the core function and outputs, and the second adds actionable usage guidance, earning every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is self-contained: it explains the purpose, the decision context, and the return components (match score, skills, keyword coverage, recommendations). The agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters ('job' accepts id/URN/URL, 'identifier' defaults to 'me'). The description adds no parameter-specific details, so the baseline of 3 is appropriate because 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?
The description uses a specific verb ('Compare') and resource ('user's profile against a job posting'), and enumerates concrete outputs (match score, required skills, keyword coverage, recommendations). This clearly distinguishes it from sibling tools like linkedin_analyse_profile and linkedin_apply_to_job.
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 second sentence explicitly states when to use the tool ('to decide whether a role is worth applying to') and what to emphasize if applying. It provides clear context but does not mention alternatives or when not to use, so it stops short of a full exclusion set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral depth by stating the session and cookie details reported, and indirectly implies a cached verdict (via the 'force' parameter), giving the agent useful runtime expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states purpose and output, the second provides usage guidance. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no required inputs, output schema present), the description fully covers purpose, output behavior, and when to invoke it. The output schema handles return-value details, so nothing essential is missing.
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 only parameter 'force' is fully described in the input schema with its purpose and cache validity (5 minutes). Since schema coverage is 100%, the description doesn't need further param detail, and the tool description adds no extra parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb ('Check') and clear resource ('LinkedIn session'), then details the exact output: which cookies are loaded, from where, and who the session belongs to. This fully distinguishes it from siblings like auth_export_cookies or system_status.
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?
Explicitly states when to call: 'Call this first if any other tool returns an AUTH_EXPIRED or AUTH_MISSING error, and before starting a long workflow.' This provides strong contextual guidance, though it doesn't mention when not to use it or alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral limitation: the export may not include emails or connection dates, implying this tool's output is less complete. This goes beyond the annotations and gives useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core purpose and formats; the second provides a crucial alternative. Every word earns its place, and it is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has rich annotations, and a clear purpose. However, there is no output schema and the description does not state what the return value looks like (e.g., file content, path, JSON structure). The alternative reference adds context, but the missing output behavior keeps it from a 5.
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 50%; the description does not compensate. It mentions the format values (JSON, CSV, Markdown) but those are already in the enum. It adds no new meaning about the limit parameter or format behavior, so the description adds little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Export connections to JSON, CSV or Markdown.' It also distinguishes itself from the sibling linkedin_request_data_export by noting that tool is preferred for complete archives, so the purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative for a specific use case: 'For a genuinely complete archive (with emails and connection dates) prefer linkedin_request_data_export.' This tells the agent when not to use this tool, which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by specifying the exact fields returned and the significance of companyId for downstream searches. It does not discuss caching or rate limits, but with strong annotations, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, zero fluff. Every piece of information earns its place: the field list and the companyId note are both valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with excellent annotations and full schema coverage, the description is complete. It lists return contents, explains the practical use of companyId, and the schema handles parameter details. No output schema exists, but the description covers what you get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters well. The description adds no extra detail about the parameters beyond what the schema provides; the mention of companyId is about output, not parameter semantics. Thus it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and names the resource 'company page', followed by a concrete list of fields it returns (description, industry, size, etc.). It clearly distinguishes from sibling tools like linkedin_get_company_jobs and linkedin_get_company_employees by focusing on the company page itself, not related entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to fetch company details and especially to obtain the companyId needed for filtering in job and people searches. It implies when to use it (before searching) but does not explicitly name alternatives or exclusion cases, so it misses the full 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations by noting that LinkedIn only reveals most contact info for 1st-degree connections, so results may be sparse. This is a useful behavioral insight not captured in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and followed by a relevant limitation. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter, the description completely covers what the tool does, what data it returns (enumerated fields), and the key limitation affecting results. Annotations and schema fill any remaining gaps, and no output schema is needed given the clear field list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter 'identifier' with a clear description, so schema coverage is 100%. The tool description adds no additional parameter-specific semantics, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read a profile's contact information' and enumerates specific fields (email, phone, websites, Twitter, birthday). This distinguishes it from sibling tools like get_profile or get_connections, which focus on other aspects of a profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to retrieve contact info) and a key caveat (1st-degree connections only). However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is covered. The description adds context about what is returned (sender names and personalized message) and clarifies the meaning of received vs. sent, adding value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main purpose and includes no fluff. Every word contributes to understanding the tool's function and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with only two params and no output schema, the description is complete. It covers what the tool does, what it returns, and the key distinction between received and sent invitations, leaving no critical 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?
Schema coverage is 100% with both parameters documented (defaults for 'type' and 'limit'). The description adds some semantic context for the 'type' parameter (received vs. sent) but does not add syntax or format details beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'List pending connection invitations'. It also distinguishes between received and sent invitations, making it distinct from sibling tools like linkedin_respond_to_invitation or linkedin_withdraw_invitation.
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 implies when to use the tool: to view pending invitations, with the received/sent distinction. It does not explicitly name alternatives or exclusions, but the context of sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds behavioral nuance by noting required skills are 'extracted from the text' (not a structured field) and that hiring team inclusion is conditional ('where LinkedIn shows it'). It also implies a cache via the refresh parameter, though the description itself doesn't mention caching; the schema does. Overall, the description adds meaningful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence enumerates the specific data returned, and the second gives direct usage guidance. It is front-loaded with the core action ('Read a job posting in full') and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with two parameters and no output schema, the description provides a comprehensive picture of what the agent will get (all major job fields) and when to use it. The lack of output schema is compensated by the detailed list of returned content. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with detailed descriptions (job accepts id/URN/URL, refresh bypasses cache), so the schema does the heavy lifting. The tool description does not add extra meaning to the parameters beyond what's already in the schema. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a job posting in full, listing specific content fields (description, skills, salary, applicant count, employment type, experience level, hiring team). It also distinguishes it from sibling search tools by emphasizing full detail and provides a concrete use case ('before applying or tailoring a resume'). The verb 'Read' precisely identifies the operation.
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 explicitly says 'Use this before applying or tailoring a resume,' which gives a clear when-to-use context. It does not explicitly name alternatives or exclusions (e.g., 'use search_jobs for listings'), but the use case is unambiguous and sufficient for agent selection. The read-only nature is implicitly aligned with pre-application workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already capture the read-only, open-world, idempotent, and non-destructive nature. The description adds behavioral context by naming the sources (profile/feed), the content included, and implies recent chronological ordering. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the purpose front-loaded and use cases following. Every sentence adds value with no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, the description is complete: it covers sources, return fields, and use cases, while annotations address safety. The schema documents all parameters, so no output schema is necessary to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameters with useful descriptions (limit, source, identifier). The tool description does not add parameter-specific details beyond what the schema already explains, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read recent posts') and resource ('a profile's activity or from the home feed'), and specifies the returned fields (text, author, engagement metrics, post type). It distinguishes itself from sibling tools like get_post by emphasizing lists of recent posts rather than a single post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases: 'review what someone posts about before engaging, or to audit your own posting history.' It does not explicitly mention alternatives or when not to use this tool, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable context by stating it returns each setting's current value and a direct link, explaining why (manual changes). This goes beyond the structured safety hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, and every word earns its place. The category list is efficiently parenthetical, and the manual-change note is brief but informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter read-only tool with comprehensive annotations, the description fully covers what it does, what it returns, and the categories available. No output schema is needed because the return value is clearly summarized as each setting's value and a link.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the 'category' parameter with an enum and description, so the description adds no new semantic value. It does repeat the category list, but the schema carries the load, yielding the baseline score.
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 reads LinkedIn account settings, lists the specific categories available, and distinguishes it from the sibling update tool by focusing on read-only behavior. The verb 'Read' and resource 'LinkedIn account settings' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading settings and notes that most settings must be changed manually, which guides use away from expecting modification. However, it does not explicitly name the sibling 'linkedin_update_setting' as the alternative for changing settings, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses important behavioral details: connection is not notified, reconnecting requires a fresh invitation, and the action cannot be undone directly. This provides valuable transparency about consequences and post-action state.
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 three short sentences, front-loaded with the core action. Every sentence provides additional useful context (removal, notification status, reconnection, irreversibility) without redundancy or digression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive action with 2 parameters and no output schema, the description covers the essential behavioral aspects, and the schema handles parameter details. The combination of description and annotations fully addresses purpose, consequences, and irreversible nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for both parameters, with clear descriptions for 'confirm' and 'identifier'. The description itself does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove an existing 1st-degree connection.' It uses a specific verb and resource, and distinguishes itself from related sibling tools like linkedin_withdraw_invitation (for pending invitations) and linkedin_send_connection_request (for adding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for removing existing connections) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The context is clear, but it lacks explicit guidance on when not to use it (e.g., pending invitations handled by linkedin_withdraw_invitation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds the scope of universal search and the 'broad sweep' characterization, but it doesn't disclose additional behavioral details such as pagination, result ordering, or how the universal search aggregates results. With annotations carrying the safety context, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then provides clear usage guidance. Every phrase earns its place with no redundancy or filler, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description, combined with rich annotations and a well-described schema, fully covers the tool's purpose, usage context, and parameter semantics. The explicit guidance on when to use this vs. dedicated tools completes the context needed for correct selection and 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 83% (only sortBy lacks a description). The description mentions the vertical parameter by listing supported verticals and references location resolution implicitly, but it doesn't add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate since the schema 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?
The description uses a specific verb 'search' with a clear resource ('LinkedIn') and explicitly scopes it as 'universal' across any vertical, enumerating people, jobs, companies, posts, events, groups, schools. It distinguishes itself from sibling tools by naming linkedin_search_jobs, linkedin_search_people, and linkedin_search_companies and clarifying when to use this tool instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use dedicated tools when vertical-specific filters are needed, and use this tool for posts, events, groups, schools, or a broad sweep. This names alternatives and clearly states the conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only behavior. The description adds valuable behavior not in annotations: notes improve acceptance, free accounts limited to ~5 notes/month, LinkedIn caps invitations at ~100/week, and the server enforces a daily limit for safety. This is practical behavioral disclosure beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, no filler. Every sentence adds value: the first defines the tool, the second provides essential usage and rate-limit context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description fully covers the action, optional parameters, and critical rate limits. Schema covers parameter semantics, no output schema is needed, and no extra return-value explanation is necessary.
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%: both 'identifier' and 'note' have descriptive schema text. The description only restates the max 300 characters for note and adds motivational context (acceptance rates), but it does not add new meaning beyond the schema. Baseline 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Send a connection request' and clarifies the optional personalized note. It clearly distinguishes this tool from siblings like send_message or respond_to_invitation by naming the exact action.
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?
Provides clear context about when to use the tool (for sending connection requests) and important limitations (note limit, weekly cap, daily limit). It does not explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false and destructive=false, but the description adds valuable context that this is a full replacement operation. The warning to read existing profile first implies overwriting, which is behavioral context beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. The first states the purpose, the second repeats a schema constraint, and the third gives a critical safety tip. No wasteful prose; it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutable update tool with no output schema, the description covers all essential aspects: what is updated, scope (signed-in user), limits, and a safety precaution. It is complete enough for the agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter (about) is fully described in the schema, including max length and line break preservation. The description only repeats the max character count and does not add new semantics beyond the schema.
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 starts with 'Replace the About (summary) section on the signed-in user's profile,' which uses a specific verb and resource. It clearly distinguishes from siblings like update_headline or update_location, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context (updating the About section) and a specific safety guideline: read the existing profile first to keep facts intact. It doesn't explicitly state 'when not to use' but the purpose clarity already differentiates it from alternatives, and the read-first advice serves as a practical usage instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful context by explaining the headline's importance and the maximum length (220 chars), which is also in the schema but reinforced. It does not contradict annotations and adds behavioral context beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Replace the headline'), and every clause earns its place. It includes essential context (visibility, max length) without unnecessary fluff. This is an exemplary model of concise, high-value description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for this low-complexity tool. It explains the purpose, the primary action, and even provides strategic guidance on content. The schema handles parameter specifics, and the lack of output schema is appropriate for a simple mutation. No gaps in needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions, including the conditional behavior of the 'industry' parameter. The description does not add any new parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate. It does not harm, but also does not elevate the understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Replace the headline') and specifies the resource ('the signed-in user's profile'). It distinguishes from sibling tools by targeting the headline field specifically, and even adds domain context about the headline's visibility in search results, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: to update the profile headline. It does not explicitly name alternatives like 'linkedin_update_about' or 'linkedin_update_location', but the specificity of 'headline' makes the use case unmistakable. The added content guidance ('prefer a specific role + specialism') is more about how to phrase the headline than when to use the tool, but it still helps the agent understand its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds valuable context beyond this: LinkedIn's conditional allowance and the acceptable 'not possible' outcome. This helps the agent reason about failures without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, followed by one critical usage caveat. No redundant or tangential content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter mutation with full schema and annotations, the description covers purpose, key behavioral constraints, and outcome expectations. Output schema absence is mitigated by the clear 'not possible' note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed explanations for 'job' (URL/URN/ID formats) and 'confirm' (must be true, irreversible). The tool description adds no parameter-specific information, so it stays at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Withdraw a submitted job application.' The verb-resource pair is specific and the mention of LinkedIn's posting/window limitation differentiates it from the sibling tool linkedin_withdraw_invitation.
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?
Provides clear context on when withdrawal may be possible ('only for some postings and within a limited window') and sets expectation that a 'not possible' answer is normal. Does not explicitly name alternatives or when-not-to-use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating operation (readOnlyHint=false). The description adds a valuable consequence: LinkedIn blocks re-inviting the same person for three weeks after withdrawal. This goes beyond the annotations and helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action, the second adds a necessary caveat. No filler, well front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with annotations and no output schema, the description sufficiently covers the action, the scope ('you sent'), and a critical post-withdrawal constraint. Nothing essential is missing.
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% because the only parameter 'person' has a clear description. The tool description does not add further parameter detail, but the schema already covers it, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Withdraw) and resource (connection request you sent), clearly distinguishing this from siblings like send_connection_request, respond_to_invitation, and remove_connection. It states exactly what the tool does with no ambiguity.
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 phrase 'you sent' establishes the usage context: for outgoing pending invitations. It does not explicitly name alternatives or exclusions (e.g., use respond_to_invitation for received invitations), but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: it reads each step, may use safe defaults, stops rather than guessing on unknown required questions, and submits a real application to a real employer. It also mentions the `unanswered` field in results and the need for user confirmation. This goes beyond the annotations (which only indicate non-read-only and open-world) and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tightly written sentences, front-loaded with the primary action. Every sentence adds value: purpose, behavior, actionable guidance on handling `unanswered`, and a safety warning. There is no fluff or redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description hints at the result's `unanswered` field, which is essential for the workflow. It covers the main flow (apply, handle unknowns, confirm intent) but does not elaborate on potential errors, success criteria, or all output fields. Given the tool's complexity (8 params, nested objects, real-world side effects), it is mostly complete but leaves some ambiguity about the exact result 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?
The schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds minor context: it clarifies how `answers` and `rememberAnswers` interact (supplied vs previously remembered), and that `stopOnUnknown` defaults to true (stopping behavior). This is helpful but not extensive, so it remains at 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 opens with a specific verb and resource: 'Apply to a job through LinkedIn Easy Apply.' It further explains the process (reads form, answers questions, submits) and clearly distinguishes from siblings like bulk apply or get application history. The purpose is unambiguous and covers the tool's core functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: apply to a single job via Easy Apply, answers can come from supply, memory, or defaults, and it warns to confirm intent with the user first. It also instructs on re-invoking after checking the `unanswered` field. However, it does not explicitly mention alternatives or when not to use it (e.g., for bulk applications, use `linkedin_apply_to_jobs_bulk`), so slightly below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the mutation nature is known. The description adds supported formats and use case, but does not disclose side effects such as overwriting existing auth state, whether the import takes effect immediately for subsequent tool calls, or how invalid cookies are handled. This is a notable gap for an auth-import tool, but it does not contradict any annotation.
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?
Three sentences, each earning its place: the first states the action, the second lists the supported formats, the third gives the usage context. No filler or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, this description covers the core aspects: what it does, what inputs it accepts, and when to use it. It omits details about return values or session side effects, but the schema's `persist` description and the annotations fill in some gaps. Slightly more behavioral depth would make it fully complete.
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%, so the baseline is 3. The description enriches the `cookies` parameter by enumerating five concrete formats (Cookie-Editor JSON, EditThisCookie JSON, Playwright storageState, Netscape cookies.txt, raw header string), which significantly reduces ambiguity. It adds nothing for `persist`, but that parameter is already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with "Import LinkedIn cookies supplied directly as text," which names the specific action (import), the resource (LinkedIn cookies), and the method (direct text). This clearly distinguishes it from sibling auth tools like linkedin_auth_export_cookies, linkedin_auth_reload, and linkedin_auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence explicitly states "Use this when the user pastes cookies into the conversation rather than saving a file," providing a concrete trigger condition and implicitly contrasting with file-based alternatives. This gives the agent a clear decision rule with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavioral traits: it draws evidence from real experience rather than inventing achievements, reports gaps for improvement, and warns that the output needs rewriting for voice. These are valuable insights that the annotations alone do not provide, making this a standout description.
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 three sentences, each earning its place: the first states the core function, the second explains the evidence-based approach and gap reporting, and the third provides an actionable next step. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no output schema), the description covers the key behavioral aspects (grounded in profile, gaps, rewrite) but does not mention that the tool can save output to disk (save=true default) or return format. Since the schema covers save, this is a minor miss, but the description is still quite complete for a drafting 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 86%, so the schema already documents most parameters. The description adds no direct parameter-level details, but it does reinforce the purpose of the job and profile inputs by mentioning 'user's real profile' and 'specific job posting.' This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Draft') and resource ('cover letter'), and distinguishes it from sibling tools like linkedin_generate_resume by grounding it in the user's profile and a specific job posting. This is exactly the kind of specific verb+resource+scope that the rubric rewards.
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 implies when to use this tool—when a cover letter is needed based on a job posting and profile—and adds practical guidance by telling the agent to rewrite for voice before sending. It does not explicitly name alternatives or exclusions, but the context is clear enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the tool's scope ('files this server has produced or can use') and including both previous exports and resume/cover-letter documents. It does not fully describe return format, but with annotations covering safety, the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'List files,' and contains no filler. Each sentence adds meaningful context: what files are listed and when to use it. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and strong annotations, the description is mostly complete. It explains the file scope and provides use cases. However, it does not explicitly differentiate from the sibling list_resumes tool, which could cause minor ambiguity in tool selection.
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 the schema is empty with 100% coverage. Per the rubric, a baseline of 4 is appropriate because there are no parameters needing explanation. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists files the server has produced or can use, specifically 'previous exports and available resume/cover-letter documents.' The verb 'List' plus the resource scope distinguishes it from sibling tools like list_resumes (which only lists resumes) and export_* tools (which create exports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this to find a resume path before applying to a job, or to locate an earlier export.' This tells the agent when to invoke the tool, though it does not mention explicit alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context by specifying the file types and the fact that paths are pre-formatted for another tool, which goes beyond the annotation basics.
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, well-structured sentence that front-loads the action ('List') and resource ('resume and cover-letter files'), with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the essential user need: retrieving file paths for applying to jobs. It implies the return format via 'paths ready to pass to' and is sufficient for a simple listing tool, though it could explicitly mention output format.
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?
There are 0 parameters, so the schema covers all parameter semantics. The description adds no parameter details because none are needed, matching the baseline for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists resume and cover-letter files from a configured directory, with a specific purpose: paths ready for linkedin_apply_to_job. This distinguishes it from sibling tools like linkedin_list_files or linkedin_list_drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: files come from a configured resume directory and are intended for use with linkedin_apply_to_job. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by describing the internal mechanism ('server loads and scrolls the notifications page'), which implies non-trivial behavior such as potential delays or side effects. Annotations only state it is not read-only and not destructive, so this added context is 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?
Two concise sentences. The first front-loads the action, the second provides the necessary mechanism context. No wasted words; every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no parameters and no output schema, the description covers the action, the reason for the non-standard approach, and the method. It could have mentioned potential side effects (e.g., marking all notifications read) but the mechanism implies this, so it remains fairly complete.
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 the schema coverage is 100% (trivially). The description doesn't need to add parameter details, and the baseline for zero-parameter tools is 4. It adds no extra parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with the clear verb+resource pair 'Mark notifications as read', which directly states the tool's function. It also distinguishes itself from siblings like 'get_notifications' and 'delete_notification' by explicitly targeting the unread badge mechanism.
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?
Provides clear context by explaining that LinkedIn lacks a bulk API and this tool simulates how LinkedIn itself clears the unread badge. This implies the tool should be used when the goal is to clear unread notifications, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds useful context by explaining that the tool's output (companyId) is intended as input for other search tools. It does not contradict annotations, though it could elaborate on return format or multiple-match behavior, but given the annotation coverage, this is sufficient.
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 exactly two sentences, front-loaded with the action ('Search for companies') and immediately followed by a clear usage context. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search/resolve tool with 4 parameters and no output schema, the description explains the primary purpose (name to ID resolution) and connects it to sibling tools. It doesn't describe the return structure, but given the annotations and schema coverage, the description provides enough context for an agent to effectively select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (query, limit, and companySize have descriptions, industryIds does not). The description adds minimal parameter-level detail beyond the schema; it repeats that query is a 'company name or keyword' and mentions the ID resolution, but does not clarify industryIds. With coverage near the high threshold, the description is not required to heavily compensate, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' with the resource 'companies by name or keyword', and explicitly distinguishes its role by stating it resolves company names into numeric companyId for other tools. This clearly differentiates it from sibling tools like linkedin_search_jobs and linkedin_search_people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to resolve a company name into the numeric companyId that linkedin_search_jobs and linkedin_search_people need for company filters.' This tells the agent exactly when to use this tool and how it fits into the broader workflow, effectively indicating that it should be used before those search tools when a company filter is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe read-only, idempotent operation. The description adds meaningful behavioral context beyond those annotations: it states "Handles pagination automatically" and clarifies that the output is jobIds intended for subsequent tools. This gives the agent a clearer mental model of the tool's behavior, though it doesn't disclose edge cases 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences: the first lays out the scope and filter list, the second explains pagination and the tool's role in the workflow. Every clause adds value, with no redundant phrasing or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 16 optional parameters and no output schema, the description covers the essential context: it's a read-only, paginated search that returns jobIds to be used with other tools. It doesn't elaborate on the full return structure, but the downstream tool linkage provides sufficient context for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 69% schema description coverage, the description compensates partially by listing many filters and offering practical advice (e.g., "Set true when planning automated applications" for easyApplyOnly, "best for high-competition roles" for datePosted, "Combine freely" for workplaceType). It does not, however, elaborate on the five parameters lacking schema descriptions (e.g., jobFunctionIds, fairChanceEmployer), so it doesn't fully close the 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 clearly states the tool's function: "Search LinkedIn jobs using the full filter set" and lists many specific filters. It also differentiates this tool from siblings by designating it as "the entry point for every job workflow," distinguishing it from linkedin_get_job (fetch a single job) and linkedin_get_company_jobs (company-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context by calling it "the entry point for every job workflow" and explaining that returned jobIds feed downstream tools. However, it does not explicitly mention when NOT to use this tool or point to an alternative like linkedin_get_company_jobs for company-scoped searches, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing the return fields (names, headlines, locations, identifiers) and the downstream integration with other tools, going beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause adds information: what it searches, what filters are available, what it returns, and how to follow up. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 11 parameters and no output schema, the description provides a solid high-level overview: filters, return data, and next steps. It does not mention pagination or limit specifics, but given the schema covers limit and the core usage is clear, it is sufficiently complete.
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 55%, and the description compensates by listing the semantic families of filters (connection degree, current/past company, school, industry, location, job title) that map to the otherwise undocumented array parameters like schoolIds, industryIds, and pastCompanyIds. It does not detail every parameter (e.g., limit, firstName, lastName), but the schema covers those with descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Search for people'. It enumerates the key filter dimensions (connection degree, company, school, industry, location, job title) and what it returns (names, headlines, locations, profile identifiers), making it distinct from sibling tools like linkedin_search_companies or linkedin_search_jobs.
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 implies usage for people search and provides downstream guidance: 'Use the identifiers with linkedin_get_profile, linkedin_send_connection_request or linkedin_send_message.' This clarifies the workflow but does not explicitly contrast with alternatives or state when not to use it, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating it is a mutation (readOnlyHint=false) and open-world, the description adds valuable constraints: accepted formats (JPG, PNG, GIF), size limit (8MB), and a resolution recommendation. This goes beyond the schema and annotations, though it omits details like authentication and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, information-dense sentences. It front-loads the primary purpose, follows with concrete constraints, and ends with a recommendation—all without extraneous content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential aspects: purpose, accepted input constraints, and a recommendation. It does not specify return values or post-upload behavior, but for a straightforward upload operation, this is a minor gap.
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 input schema fully describes the filePath parameter with 100% coverage, so the baseline is 3. The description adds meaning by specifying which file types and sizes are acceptable, thus enriching the semantics of the parameter beyond the schema's generic 'image file' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Upload or replace the profile photo') and specifically identifies the resource. It distinguishes from siblings like linkedin_upload_banner by explicitly targeting the profile photo, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (for the profile photo) and implicitly differentiates it from the banner upload sibling. However, it does not explicitly mention alternatives or exclusionary conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by warning that the output contains live session credentials and that anyone holding them can access the user's account. This is valuable security context not provided by the readOnlyHint or other annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the purpose first, followed by a critical warning. Every sentence earns its place, no redundancy, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description covers the essential use case, security implications, and usage restriction. The output nature is inherently clear from the export purpose, and the schema handles the format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the only parameter 'format', including its default behavior ('Defaults to cookie-editor'). The description adds no additional parameter semantics, but the schema fully covers it, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'currently loaded cookies', with a clear outcome (moved to another machine or backed up). This distinguishes it from sibling tools like linkedin_auth_import_cookies (import), linkedin_auth_reload, and linkedin_auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage condition: 'Only surface this when the user explicitly asks for it.' This is a clear when-to-use guideline. However, it does not explicitly compare against alternatives like the import tool, but the contrast is implied by naming and the export/import relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, lowering the bar. The description adds substantial context: it returns a draft plus notes about missing information, has a 'no invented credentials' constraint, and produces an accurate factual base rather than finished prose. This goes beyond what annotations provide.
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 three concise sentences, front-loaded with purpose, and every sentence contributes: purpose, output format, and usage guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and many optional parameters, the description covers the essential behavior: it drafts based on the real profile, returns a draft plus missing notes, and should be rewritten before sending. Combined with strong annotations, this is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so baseline is 3. The description reinforces the purpose of identifier and highlights ('grounded in the real profile', 'no invented credentials') but does not add specific parameter-level meaning beyond the schema.
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 drafts a personalised outreach message grounded in the user's real profile, with explicit mention of 'no invented credentials'. It distinguishes itself from sibling tools like send_message by emphasizing it returns a draft to be rewritten before sending, not finished prose.
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 implies the use case (drafting an outreach message based on the profile) and instructs to rewrite for voice before sending, suggesting a follow-up send tool. However, it does not explicitly name alternatives or state when not to use, so it is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context by noting the data source ('submitted through this server') and scope ('including the answers given and any failures'), which goes beyond the annotations and helps the agent understand the tool's limitations and output contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and the second sentence adds an important differentiation without fluff. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered-list tool with strong annotations and full parameter schema documentation, the description is complete. It covers the purpose, data source, content scope, and a key alternative, leaving no major gaps for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (since and status) have full descriptions in the schema, yielding 100% schema coverage, so the schema already explains the parameter semantics. The description does not independently elaborate on parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists applications submitted through this server, including answers and failures, using a specific verb 'List' and resource 'applications'. It also distinguishes itself from the sibling tool linkedin_get_applied_jobs by pointing to that tool for LinkedIn's authoritative record, making the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names an alternative tool (linkedin_get_applied_jobs) for a different use case, providing a clear exclusion. It implies the primary use case is for server-local application history with answer and failure details, which gives context on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering the safety profile. The description adds valuable behavioral context by explaining that the data source is authoritative (LinkedIn's own record) versus server-local, which affects interpretation of the results. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and immediately provides a meaningful differentiator. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and strong annotations, the description is complete. It clearly states what is returned (jobs the user applied to), identifies the authoritative source, and names an alternative. The lack of an output schema is mitigated by the clear purpose and read-only semantics.
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 parameter 'limit' documented with its default value. The description adds no additional parameter details, so the baseline score of 3 is appropriate given that the schema already explains the parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and clearly identifies the resource: LinkedIn's own record of jobs the user has applied to. It also explicitly contrasts with linkedin_get_application_history, distinguishing it from a closely related sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly states when to use this tool: to get the authoritative, complete record from LinkedIn, and contrasts it with linkedin_get_application_history for applications made through the server. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds valuable behavioral context about pagination performance ('Large networks take a while to page through'), which is not captured in annotations, thus enriching transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the exact purpose and return fields, the second delivers a concise, actionable performance tip. Every word earns its place with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional parameters and no output schema, the description is fully self-sufficient. It states what the tool does, what the response contains, and warns about performance, requiring no additional context to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit defaults to 50, refresh bypasses cache) with 100% coverage. The description goes beyond by explaining the rationale for the limit parameter—pagination time in large networks—adding meaningful context that helps the agent choose appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'the signed-in user's 1st-degree connections', including the exact data returned (names, headlines, profile links). This sharply distinguishes it from sibling tools like linkedin_export_connections or linkedin_get_contact_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool operates on the signed-in user's network and offers a practical usage tip about setting a realistic limit due to slow paging through large networks. However, it does not explicitly mention alternatives or when-not-to-use it, so it misses the upper bound.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description complements these by disclosing the trigger action and expected outcome: LinkedIn emails a download link within minutes to 24 hours. It also details what the archive includes. No contradictions with annotations; the 'Trigger' wording aligns with the non-read-only hint.
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 three sentences, front-loaded with the core action, then value proposition, then delivery expectation. Every sentence contributes information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description effectively covers what the action is, why it's valuable, and what the user will receive (email link). Given the tool's simplicity and the supportive annotations, the description is complete enough without needing to explain return formats or prerequisites.
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 input schema has zero parameters, so schema coverage is 100%. The description adds no parameter semantics because there are none to describe; the baseline of 4 for zero-param tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Trigger LinkedIn's official data export,' a specific verb and resource. It further specifies that this is 'the only way to obtain a genuinely complete archive' and enumerates contents (connections with emails, full message history, activity logs), which clearly distinguishes it from the many sibling export and scraping tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: it positions this tool as the unique route to a complete archive, implicitly advising its use over scraping or partial exports. It doesn't explicitly name sibling alternatives (e.g., linkedin_export_connections) or state when not to use them, but the 'only way' framing gives a clear usage trigger for complete-archive needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by revealing that LinkedIn has no draft API, so drafts are stored locally and are not visible in the LinkedIn UI. This is critical behavioral context that helps the agent understand what 'save draft' actually does.
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?
Three sentences deliver purpose, storage location, and usage guidance without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple save-draft operation with full schema coverage and no output schema, the description adequately covers behavior, constraints, and use case. It also notes the local-store nuance, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions (100% coverage), so the description adds no additional parameter-specific meaning. Baseline 3 is appropriate since the schema already handles parameter semantics effectively.
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 'save' and the resource 'post text as a local draft', and explicitly notes 'without publishing it', distinguishing it from publishing tools like linkedin_create_post and linkedin_publish_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to prepare content for review before publishing.' It implies when this tool is appropriate and contrasts with publishing, though it does not explicitly name alternative tools or spell out 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral context by detailing what data is reported (cache, rate-limit quota, local storage) and how DRY_RUN status is surfaced, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the tool's purpose with specific output categories, the second provides concrete usage guidance. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic tool, the description is fully sufficient. It covers what the tool does, what metrics are included, and when to use it, without needing to explain return values (since there is no output schema) or input complexity.
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 input schema has zero parameters, so there is no parameter-specific information needed. The baseline for 0-parameter tools is 4, and the description appropriately focuses on the tool's output and purpose rather than inputs.
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 'Report' and explicitly enumerates the categories of server health information (configuration, browser state, cache stats, rate-limit quota, local storage counts). This clearly distinguishes it from related tools like auth_status or get_settings by focusing on diagnostic server health metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: diagnose slowness, unexpected refusals, or confirm DRY_RUN before writes. It does not explicitly name alternatives or provide exclusions, but the intended use cases are well-defined and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail about typeahead matching beyond the annotations, explaining how the value is processed, though it does not cover failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter update tool with annotations and full schema coverage, the description provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents the parameter with examples; the description adds the matching-semantics nuance, which is useful beyond the schema.
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 updates the profile location with a specific verb and resource, distinguishing it from sibling tools like linkedin_add_experience or linkedin_update_about.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by explaining LinkedIn's typeahead requirement and advising on recognisable city/region names, but it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false), and the description adds critical behavioral details: the tool can replace an existing banner and enforces LinkedIn's image requirements. This goes beyond the structured metadata.
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 communicates the purpose and all constraints without waste. It is front-loaded with the action and resource, then provides needed file specifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the operation, input requirements, and expected behavior. It would be difficult to misuse this tool with the given information.
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 schema already describes filePath as 'Path to the banner image file.' The description adds valuable constraints on dimensions, formats, and file size, which the agent needs for input validation. This supplemental info enhances the schema's bare parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Upload or replace') and names the exact resource ('profile background banner'), clearly distinguishing it from sibling tools like linkedin_upload_profile_photo. There is no ambiguity about what this tool does.
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?
While it doesn't explicitly reference alternatives, the description clearly states the tool's scope for the profile background banner, making it obvious when to use it over sibling upload tools. No exclusion criteria are needed for such a targeted operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds valuable behavioral context: LinkedIn matches against its own taxonomy, implying possible normalization or rejection, and that skills affect recruiter search. It also discloses a hard maximum of 50 skills. This goes beyond annotations and helps the agent anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause earns its place. No wasted words; the constraints and rationale are included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description fully covers purpose, usage constraints, behavioral implications, and limits. Nothing critical is missing for an agent to successfully invoke the tool.
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 input schema already provides 100% coverage for the single 'skill' parameter. The description enriches this with specific guidance on naming conventions ('Machine Learning' over 'ML wizardry') and the 50-skill limit, adding meaning beyond the schema's simple description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a skill to the profile') with a specific resource (skill), and mentions key constraints (taxonomy matching, max 50). It implicitly distinguishes from sibling 'add_' tools (e.g., add_language) by naming the resource type explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance: prefer standard names for recruiter search and respect a 50-skill limit. It lacks explicit exclusionary language or alternatives (e.g., 'use remove_skill to delete'), but the guidance is clear and directly relevant to when/how to use the tool safely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals multiple behavioral traits beyond the annotations: human-like pacing, skipping previously applied jobs, aborting on session/quota failure, reporting skipped jobs with specific unanswered questions, and the real-world consequence of submitting applications. The annotations only indicate readOnly=false and openWorld=true, so this description adds substantial safety and failure-mode context.
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 four sentences, each delivering actionable information: the batch apply action, pacing and skip behavior, failure handling and skipped-job reporting, and the approval requirement. No filler or repetition, front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives essential operational context for a complex mutation tool: it warns about real submissions, requires approval, and explains edge cases (already applied, session/quota aborts, unanswered questions). It does not describe the return value/output, but with no output schema and clear behavior, the missing return-type detail is not critical for correct invocation.
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 schema covers most parameters (83% coverage), but the description adds interaction context: 'supply those answers and retry those jobs' clarifies the answers parameter, 'daily safety quota' explains maxApplications bound, and 'required question could not be answered' relates to stopOnUnknown. This goes beyond basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Apply to several Easy Apply jobs in sequence'. It clearly distinguishes itself from the singular sibling linkedin_apply_to_job by emphasizing 'several' and 'batch'. The purpose is unambiguous and differentiates from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool (for several Easy Apply jobs) and includes an explicit prerequisite: 'get explicit user approval for the batch first'. It also mentions failure handling (aborts on session/quota failure) and skipped jobs due to unanswered questions, but does not explicitly state 'do not use for a single job' or name the alternative. However, the batch context and sibling list make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: it mentions a 5-minute cache (via the refresh parameter description) and that the tool reads the complete profile, giving the agent expectations about data freshness and scope. It doesn't mention rate limits or auth requirements, but with annotations already covering the safety profile, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence is dense with useful detail (listing all sections), and the second clearly states two specific use cases. Every clause carries meaning, no wasted words, and the most important information (what the tool reads) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters, a rich set of profile sections, and already strong annotations, the description covers the essential aspects: the full scope of data read, the two primary use cases, and evidence of the cache behavior. It doesn't describe return format or error cases, but with no output schema and read-only semantics, the description is sufficient for an agent to correctly invoke the tool for most profile-reading tasks.
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%, so the schema already documents all four parameters. The description further enhances parameter understanding by clarifying the 'identifier' parameter values ('me', public identifier, URL, URN) and the 'refresh' parameter's cache-bypass behavior, which are not fully specified in the schema alone. However, the description doesn't elaborate on the exact format of the return value, which is fine given no output schema exists but the description could have added more context on response shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Read a complete LinkedIn profile') and enumerates the exact sections included (headline, about, experience, education, etc.), making the tool's scope unmistakable. It also implicitly distinguishes this read tool from sibling mutation tools like linkedin_update_headline or linkedin_add_experience by framing it as the 'read' counterpart to those actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'before writing any profile update' and 'before tailoring a resume.' It also offers clear context for recommended usage based on data freshness, implying the tool is the right choice whenever you need to review existing profile content before modifying it. While it doesn't name specific alternative tools, the context inherently distinguishes this read operation from the many profile-edit siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the annotations: immediate, network-visible publication and the need for user confirmation. It also clarifies the single-media-type constraint. These are meaningful insights not covered by readOnlyHint/idempotentHint/destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Every sentence provides useful detail—media types, character limit, immediate-publication warning—without redundant or promotional language. It is efficiently structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite not having an output schema, the description covers essential behavior (what it does, media types, limits, immediacy, safety). Combined with a rich input schema covering visibility, document title, and video transcoding nuances, the tool is well-specified for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 86% schema coverage, the baseline is 3, but the description adds cross-parameter meaning: 'Only one media type per post' and 'a document (PDF/PPT — this is how carousels are made)' explain how parameters relate and why the document option is significant. This adds value beyond the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Publish a post to the LinkedIn feed' uses a specific verb and resource, clearly distinguishing it from sibling tools like edit_post, delete_post, or save_draft. The scope is further clarified by enumerating supported media types, making the tool's function 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 statement 'This publishes immediately and is visible to the network, so confirm the text with the user first' provides clear contextual guidance on when to use the tool and a caution about its immediacy. It does not explicitly name alternatives like save_draft for deferred publishing, but the implication is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/Sabari2005/linkedin-mcp-server'

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