LinkedIn Intelligence MCP Server

by southleft

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation2/5
The tool set suffers from significant ambiguity with many overlapping purposes. For example, there are multiple content analysis tools (analyze_content_performance, analyze_my_content_performance, generate_engagement_report) with unclear distinctions, and multiple post creation tools (create_post, create_image_post, create_video_post, create_document_post) that could cause confusion about which to use for specific media types. The sheer number of tools (85) exacerbates this problem, making it difficult for an agent to reliably select the right tool.
Naming Consistency4/5
Naming is mostly consistent with a clear verb_noun pattern throughout (e.g., get_profile, create_post, analyze_content_performance). There are minor deviations like 'debug_context' (noun_verb) and 'list_drafts' (verb_plural_noun), but the overall convention is readable and predictable. The consistency helps despite the large number of tools.
Tool Count1/5
With 85 tools, this is an extreme mismatch for a LinkedIn-focused server. The count is excessive, creating overwhelming complexity and likely including many niche or redundant tools. A well-scoped server for this domain should have 15-30 tools at most; 85 indicates poor coherence and will confuse agents trying to navigate the surface.
Completeness5/5
The tool set is remarkably complete for the LinkedIn domain, covering nearly every conceivable operation: profile management (get, update, skills), content creation (posts, comments, reactions, drafts), analysis (performance, engagement, hashtags), search (people, companies, jobs, ads), messaging, connections, and scheduling. There are no obvious gaps; it provides full CRUD/lifecycle coverage across all major LinkedIn features.
Average 3.7/5 across 85 of 85 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 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 failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool returns 'content analysis with score, suggestions, and recommended hashtags,' which gives some behavioral insight. However, it lacks critical details: whether this is a read-only operation, if it has rate limits, what permissions are needed, or how the analysis is generated. For a tool with no annotations, this is insufficient.
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 well-structured and front-loaded: the first sentence states the purpose clearly. The 'Args' and 'Returns' sections are efficient, though they could be integrated more seamlessly. There's minimal waste, but it's slightly verbose with separate sections instead of a flowing paragraph.
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 complexity (analysis tool with 2 parameters, no annotations, but an output schema exists), the description is moderately complete. It covers the purpose and parameters but lacks behavioral details like error handling or usage context. The output schema likely documents return values, so the description doesn't need to explain those, but it should address more operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'content' as 'Draft post content to analyze' and 'industry' as 'Optional industry for targeted hashtag suggestions,' adding meaningful context beyond the bare schema. However, it doesn't detail format constraints (e.g., length limits for content, valid industry values), leaving gaps. With 0% coverage, this is adequate but not comprehensive.
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's purpose: 'Analyze draft content and get suggestions for improvement.' It specifies the verb ('analyze') and resource ('draft content'), and distinguishes it from siblings like 'analyze_content_performance' or 'analyze_engagement' by focusing on draft content rather than published content. However, it doesn't explicitly differentiate from 'analyze_my_content_performance' which might also involve drafts, so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'analyze_content_performance' or 'analyze_engagement', nor does it specify prerequisites or exclusions. The only implied usage is for draft content, but that's already covered in purpose clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'deep engagement analysis' and output types but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 well-structured and appropriately sized: it starts with the core purpose, lists parameters with brief explanations, and ends with the return value. Every sentence adds value, though the parameter explanations could be slightly more detailed given the lack of schema descriptions.
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 that an output schema exists (though not provided here), the description doesn't need to detail return values. However, with no annotations, 0% schema description coverage, and multiple related sibling tools, the description is incomplete—it lacks behavioral context and differentiation guidance. It's minimally adequate but has clear gaps for a tool performing analysis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds some value by explaining 'post_urn' as a 'LinkedIn post URN' and 'follower_count' as 'Author's follower count for rate calculation (optional).' However, it doesn't fully compensate for the coverage gap—e.g., it doesn't clarify URN format, what 'rate calculation' means, or how the optional parameter affects results.
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 performs 'deep engagement analysis on a specific post' with 'comprehensive engagement metrics, reaction distribution, and quality score.' This specifies the verb ('analyze'), resource ('post'), and output scope. However, it doesn't explicitly differentiate from sibling tools like 'analyze_content_performance' or 'get_post_analytics,' which appear related.
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. With multiple sibling tools that seem related (e.g., 'analyze_content_performance,' 'get_post_analytics,' 'generate_engagement_report'), there's no indication of what makes this tool distinct or when it should be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions the analysis scope but doesn't cover permissions needed, rate limits, data freshness, whether it's a read-only operation, or what happens with invalid inputs. The description doesn't contradict annotations (none exist), but provides inadequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences that each serve a purpose: stating the tool's purpose, documenting parameters, and describing returns. It's front-loaded with the core functionality. Minor improvement could be made by integrating parameter details more seamlessly.
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 has an output schema (which handles return values), 2 parameters with 0% schema coverage, and no annotations, the description is minimally adequate. It covers the basic purpose and some parameter details but lacks behavioral context and usage guidance that would be helpful for this analytical 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 description adds some parameter context beyond the schema: it clarifies that 'profile_id' is a 'LinkedIn public ID' and provides default/max values for 'post_limit' (30 default, 50 max). However, with 0% schema description coverage and 2 parameters, this partial information doesn't fully compensate - it doesn't explain format requirements for profile_id or what happens when post_limit exceeds 50.
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's purpose: 'Analyze hashtag usage and performance' with specific resources (hashtags) and outcomes (frequency, engagement correlation, recommendations). It distinguishes from some siblings like 'analyze_content_performance' by focusing specifically on hashtags, though not all sibling distinctions are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'analyze_content_performance' or 'analyze_engagement', nor does it specify prerequisites or appropriate contexts for hashtag analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool analyzes audience demographics but doesn't disclose behavioral traits like whether it's read-only (implied but not explicit), what data sources it uses (commenters' profiles only), rate limits, permissions required, or format of returned demographics. For a tool with no annotation coverage, this leaves significant gaps.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by Args and Returns sections. Every sentence adds value, though the structure could be more integrated (e.g., combining into a single paragraph). No wasted words.
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 1 parameter with 0% schema coverage and an output schema exists (so return values are documented elsewhere), the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral context (no annotations) and usage guidelines. For a read-like analysis tool, it's passable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema only indicates a required string parameter 'post_urn'. The description adds meaning by specifying it's a 'LinkedIn post URN', which clarifies the parameter's purpose and format beyond the bare schema. However, it doesn't explain URN structure or provide examples, leaving some ambiguity.
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's purpose: 'Analyze the audience engaging with a specific post' and specifies it returns 'audience demographics based on commenters' profiles.' This is a specific verb+resource combination that distinguishes it from siblings like analyze_content_performance or analyze_engagement. However, it doesn't explicitly differentiate from analyze_my_content_performance which might also involve audience analysis.
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 doesn't mention prerequisites (e.g., needing a post URN), exclusions, or compare it to similar tools like analyze_engagement or get_post_analytics. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions that the tool 'Returns a full engagement report', it doesn't describe important behavioral aspects: whether this is a read-only operation, if it makes external API calls, what permissions are required, potential rate limits, or how long the generation might take. For a tool that likely involves data analysis and potentially significant processing, this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence clearly states the purpose, followed by organized sections for Args and Returns. Every sentence adds value, though the 'Args' and 'Returns' labels could be more integrated with the natural flow. There's no unnecessary repetition or verbose explanation.
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 that there's an output schema (which handles return value documentation) and only 2 parameters with some semantic clarification in the description, the description is minimally adequate. However, for a tool that generates 'comprehensive engagement reports' with content analysis and recommendations—likely involving complex processing—the description should provide more context about what 'comprehensive' entails, any limitations, or prerequisites. The absence of annotations exacerbates this 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?
With 0% schema description coverage, the description adds meaningful context for both parameters: it clarifies that 'profile_id' is a 'LinkedIn public ID' (not just any string) and that 'post_limit' specifies 'Number of posts to analyze' with a default of 20. This provides essential semantic information beyond the bare schema. However, it doesn't explain parameter constraints like valid profile_id formats or post_limit ranges.
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's purpose: 'Generate a comprehensive engagement report for a profile' with specific details about analyzing posts and returning content analysis, timing, and recommendations. It distinguishes from siblings like 'analyze_engagement' by specifying a full report generation rather than just analysis. However, it doesn't explicitly contrast with other report-related tools like 'generate_my_content_calendar'.
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. With many sibling tools like 'analyze_engagement', 'get_my_posting_recommendations', and 'get_post_analytics', there's no indication of when this comprehensive report is preferred over more focused analysis tools. The description mentions what it returns but not when it's the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns conversation details with full message history' and includes a 'WARNING: Uses unofficial API,' which adds some context about reliability or potential risks. However, it doesn't cover other important behavioral aspects such as rate limits, authentication requirements, error handling, or whether the operation is read-only or has side effects, leaving significant gaps.
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 well-structured and front-loaded, with the core purpose stated first, followed by parameter details and a warning. Each sentence adds value: the first defines the tool, the second explains the parameter, the third clarifies the return, and the fourth provides a critical warning. There's no unnecessary fluff, making it efficient, though it could be slightly more concise by integrating the return statement into the first sentence.
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 (a read operation with one parameter) and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the purpose, parameter source, and a key warning. However, without annotations and with sibling tools like 'get_conversation_details', it lacks guidance on tool selection and deeper behavioral context, making it adequate but not fully comprehensive.
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 0% description coverage, but the description compensates by explaining that 'conversation_id' is a 'Conversation ID (from get_conversations results).' This adds meaningful context beyond the schema's type definition. However, with only one parameter, the baseline is high, and the description doesn't provide additional details like format examples or constraints, so it meets but doesn't exceed expectations.
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's purpose: 'Get full message history for a specific conversation.' It uses a specific verb ('Get') and resource ('full message history for a specific conversation'), making the function unambiguous. However, it doesn't explicitly differentiate from its sibling 'get_conversation_details', which appears to serve a similar purpose, preventing a perfect score.
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 minimal guidance: it mentions that 'conversation_id' should come 'from get_conversations results', which is a useful prerequisite. However, it lacks explicit instructions on when to use this tool versus alternatives (e.g., 'get_conversation_details' or other conversation-related tools), and it doesn't specify any exclusions or conditions for use beyond the warning about the unofficial API.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), which implies non-destructive behavior, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what 'draft details' includes. For a tool with zero annotation coverage, this is insufficient.
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 appropriately concise with three sentences: a purpose statement, parameter explanation, and return value note. It's front-loaded with the main action. There's no wasted text, though the structure could be slightly improved by integrating the Args/Returns into a single fluent paragraph.
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 low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is minimally complete. However, with no annotations and low schema coverage, it lacks context on behavioral aspects like permissions or error handling, making it adequate but with clear 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?
The description adds minimal semantics: it explains that 'draft_id' is the 'ID of the draft'. With 0% schema description coverage and 1 parameter, this provides some clarification beyond the bare schema. However, it doesn't specify the ID format (e.g., numeric, UUID) or constraints, so it only partially compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a specific draft by ID' and 'Returns the draft details.' This specifies the verb (get), resource (draft), and scope (specific by ID). However, it doesn't explicitly differentiate from sibling tools like 'list_drafts' or 'get_my_posts', which would be needed for a score of 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_drafts' for browsing drafts or 'get_my_posts' for published content, nor does it specify prerequisites such as needing an existing draft ID. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns list of comments with author info,' which adds some context about the output format. However, it lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 well-structured and concise, with a clear purpose statement followed by parameter explanations in a simple format. It avoids unnecessary details and is front-loaded with the main action. However, the 'Args:' and 'Returns' sections could be integrated more seamlessly, and it lacks a concluding sentence, slightly affecting flow.
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 low complexity (2 parameters, no nested objects) and the presence of an output schema, the description is adequate but incomplete. It covers the basic purpose and parameters but misses usage guidelines and behavioral details like error handling or permissions. The output schema likely documents return values, so the description doesn't need to elaborate there, but overall it leaves room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema. It explains that 'post_urn' is a 'LinkedIn post URN' and 'limit' is the 'Maximum comments to return (default: 50),' which clarifies the purpose of each parameter. However, with 0% schema description coverage, the schema itself provides no descriptions, so the description compensates somewhat but doesn't fully address nuances like URN format or limit constraints. This meets the baseline for partial compensation.
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's purpose: 'Get comments on a specific post.' It specifies the verb ('Get') and resource ('comments on a specific post'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_comments_official' or 'get_post_reactions', which prevents a perfect score.
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 doesn't mention sibling tools like 'get_comments_official' or 'get_post_reactions', nor does it specify prerequisites or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'scheduled post details', but doesn't describe what those details include, whether it's a read-only operation, error handling (e.g., if the job_id is invalid), or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief 'Args' and 'Returns' section. There's no unnecessary verbosity, and each sentence adds value, though the structure could be slightly more polished (e.g., integrating the return statement into the main description).
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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but has gaps. It covers the basic purpose and parameter semantics but lacks usage guidelines and behavioral details (e.g., error cases). With no annotations, it should provide more context to fully guide the 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 description adds minimal semantics beyond the input schema: it explains that 'job_id' is the 'ID of the scheduled post', which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, the baseline is 4 for zero parameters, but here the single parameter is documented in the description, so it meets the minimum viable level without fully compensating for the schema gap.
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's purpose: 'Get a specific scheduled post' specifies the verb ('Get') and resource ('scheduled post'), and distinguishes it from siblings like 'list_scheduled_posts' (which retrieves multiple posts) and 'schedule_post' (which creates one). However, it doesn't explicitly contrast with all siblings, such as 'update_scheduled_post' or 'cancel_scheduled_post', which is why it's not 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get_scheduled_post' over 'list_scheduled_posts' for retrieving a single post, or how it relates to tools like 'update_scheduled_post' or 'cancel_scheduled_post'. Without any usage context, the agent must infer this from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions a default and max for 'post_limit' and hints at return content, but lacks details on permissions, rate limits, data freshness, or whether this is a read-only operation. For a tool with potential data access implications, this is insufficient.
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 appropriately sized and front-loaded with the core purpose, followed by parameter details and return summary. Every sentence adds value, though the structure could be slightly more polished (e.g., integrating Args/Returns into prose). No wasted words.
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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It explains parameters adequately and defers return details to the output schema, but lacks behavioral context (e.g., auth needs, side effects) which is a gap for a tool in a social media analytics context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by explaining both parameters: 'profile_id' as a LinkedIn public ID and 'post_limit' with default and max values. This adds crucial context beyond the bare schema, though it doesn't cover validation rules or format specifics for 'profile_id'.
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 analyzes content performance patterns for a LinkedIn profile, specifying the resource (profile) and action (analyze patterns). It distinguishes from siblings like 'analyze_my_content_performance' by targeting external profiles, but doesn't explicitly contrast with 'analyze_engagement' or 'analyze_post_audience' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'analyze_engagement' or 'analyze_my_content_performance'. The description implies usage for performance analysis but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing engagement patterns but doesn't specify whether this requires authentication, involves data fetching (e.g., from LinkedIn API), has rate limits, or returns real-time vs. historical data. For a tool with zero annotation coverage, this is a significant gap in 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 well-structured and appropriately sized, with a clear purpose statement followed by parameter and return value explanations in separate sections. Every sentence adds value, but the 'Args' and 'Returns' sections could be integrated more seamlessly, and some redundancy exists (e.g., repeating 'engagement' in the purpose and returns).
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 (2 parameters, no annotations, but with an output schema), the description is adequate but has gaps. It covers the purpose and parameters well, and the output schema likely handles return values, so it doesn't need to detail those. However, it lacks behavioral context (e.g., data sources, execution time) and usage guidelines, making it minimally viable but incomplete for optimal agent decision-making.
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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'profile_id' is a 'LinkedIn public ID' and 'post_limit' specifies the 'Number of posts to analyze' with default and max values, clarifying usage. However, it doesn't detail format constraints (e.g., URL format for profile_id) or edge cases, slightly limiting completeness.
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's purpose: 'Analyze optimal posting times based on engagement patterns.' It specifies the verb ('analyze'), resource ('optimal posting times'), and basis ('engagement patterns'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'analyze_engagement' or 'get_my_posting_recommendations', which might have overlapping functionality, preventing a perfect score.
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 doesn't mention prerequisites, such as needing prior engagement data or a valid profile, nor does it compare to siblings like 'analyze_engagement' or 'get_my_posting_recommendations'. This lack of context leaves the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions what metrics are returned (cache size, hit rate, memory usage) but doesn't disclose behavioral traits like whether it's read-only, requires permissions, has rate limits, or how data is formatted. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with two sentences that directly state the purpose and return values without unnecessary elaboration. It could be slightly more structured but is efficient overall.
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 has an output schema and no parameters, the description covers the basic purpose and return metrics adequately. However, with no annotations and a read operation implied, it lacks details on permissions, data freshness, or error handling, making it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't need to add parameter details, and it appropriately avoids redundancy, earning a baseline score above 3 due to the lack of parameters.
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's purpose with the verb 'Get' and resource 'cache statistics and performance metrics', making it specific and actionable. However, it doesn't explicitly differentiate from sibling tools, though none appear to be direct alternatives for cache statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons with other tools, leaving usage unclear beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list of users and reaction types, which is useful, but doesn't cover critical aspects like whether this is a read-only operation, rate limits, authentication needs, or pagination behavior. For a tool with zero annotation coverage, this is insufficient.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by an 'Args' section with parameter details and a 'Returns' statement. Each sentence adds value, with no wasted words, though minor improvements in flow could elevate it to a 5.
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 low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is adequate but has gaps. It explains the parameter well but lacks behavioral context (e.g., safety, limits) and usage guidelines. With no annotations, it doesn't fully compensate for missing structured data.
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 description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'post_urn' is a 'LinkedIn post URN' and provides an example format ('e.g., "urn:li:activity:123456789"'), clarifying the parameter's purpose and syntax. With only one parameter, this compensation is effective, though not exhaustive.
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's purpose: 'Get reactions/likes on a specific post.' It specifies the verb ('Get'), resource ('reactions/likes'), and scope ('on a specific post'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_post_comments' or 'get_post_analytics', which prevents a score of 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_post_comments' for comments or 'get_post_analytics' for broader analytics, nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Returns school details' but doesn't disclose behavioral traits like whether it's a read-only operation (implied by 'Get'), authentication requirements, rate limits, error conditions, or what happens with invalid public_id. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by parameter and return information. No wasted sentences. However, the 'Args:' and 'Returns:' formatting could be more integrated, and it's slightly verbose for a single-parameter 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 tool's low complexity (single parameter, no nested objects) and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers purpose, parameter meaning, and return content at a high level. The main gap is lack of behavioral context, but with output schema existing, it doesn't need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds value by explaining 'public_id: School's public identifier (URL slug)', giving semantic meaning beyond the bare schema. However, it doesn't provide examples, format details, or constraints, and there's only one parameter, so baseline 3 is appropriate with marginal improvement over schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get school/university information' with specific verb ('Get') and resource ('school/university information'). It distinguishes itself from sibling tools like 'get_company' or 'get_profile' by focusing on educational institutions. However, it doesn't explicitly differentiate from potential similar tools (none exist in the sibling list), so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparison with other data retrieval tools in the sibling list (e.g., when to use get_school vs get_company). The agent must infer usage solely 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?
No annotations are provided, so the description carries the full burden. It mentions the API source and factors used for similarity, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, what permissions are required, whether there are rate limits, how relevance scoring works, or the format of returned profiles. For a tool with no annotations, this leaves significant gaps.
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 well-structured and appropriately sized. It starts with a clear purpose statement, adds context about the API and factors, then lists parameters and returns in separate sections. Every sentence adds value, with no wasted words, though it could be slightly more front-loaded by integrating the API mention earlier.
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 2 parameters with 0% schema coverage and no annotations, the description does a decent job explaining parameters and mentioning the return format. However, with an output schema present, it doesn't need to detail return values, but it still lacks behavioral context for a tool with no annotations. It's minimally adequate but has clear gaps in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively explains both parameters: 'profile_id' as a 'LinkedIn public ID' with an example, and 'limit' as the 'maximum number of similar profiles to return' with a default. This adds meaningful context beyond the bare schema, though it doesn't detail constraints like ID format or limit ranges.
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's purpose: 'Get profiles similar to a given profile' and mentions it uses 'Professional Network Data API' with specific factors like 'industry, role, skills, and other factors'. It distinguishes itself from siblings like 'get_profile' or 'search_people' by focusing on similarity rather than direct retrieval or search. However, it doesn't explicitly contrast with all similar siblings like 'batch_get_profiles'.
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 doesn't mention when this tool is preferred over 'search_people' or 'batch_get_profiles', nor does it specify prerequisites or exclusions. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool returns a sorted list, which is useful, but lacks critical details: it doesn't mention pagination, rate limits, authentication requirements, or whether it's read-only (though implied by 'list'). For a tool with no annotations, this leaves significant gaps in understanding its operation and constraints.
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 well-structured and concise, with three clear sentences: the purpose, parameter explanation, and return behavior. Each sentence adds value without redundancy. It could be slightly more front-loaded by integrating the parameter info into the first sentence, but overall it's efficient.
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 low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is moderately complete. It covers the basics but lacks behavioral details like pagination or error handling. With no annotations, it should do more to guide usage, but the output schema reduces the burden slightly.
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 description adds meaningful context for the single parameter: 'tag: Optional tag to filter by'. This clarifies the parameter's purpose beyond the schema, which has 0% description coverage and only defines 'tag' as an optional string/null. Since there's only one parameter and the description explains it well, the score is high, compensating for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all content drafts.' This specifies the verb ('list') and resource ('content drafts'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_draft' (which retrieves a single draft) or 'create_draft' (which creates one), so it doesn't reach the highest score.
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 mentions an optional tag filter but doesn't explain when filtering is appropriate or compare it to other list/retrieval tools like 'get_draft' or 'list_scheduled_posts'. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists posts and returns a list, but it doesn't describe key behaviors such as pagination, rate limits, authentication requirements, or whether it's a read-only operation (though listing implies reading). For a tool with no annotation coverage, this is a significant gap in 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 appropriately sized and front-loaded, with the core purpose stated first ('List all scheduled posts.'). The additional details about args and returns are concise and relevant. However, the formatting with 'Args:' and 'Returns' is slightly verbose for such a simple tool, preventing a perfect score.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is mostly adequate. It covers the purpose and parameter semantics well. However, it lacks behavioral details (e.g., pagination, auth needs) and usage guidelines, which are gaps for a tool with no annotations.
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 description adds meaningful semantics beyond the input schema. The schema has 0% description coverage and only defines 'status' as a nullable string, but the description specifies that 'status' filters by values like 'pending, published, failed, cancelled'. This clarifies the parameter's purpose and possible values, compensating well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all scheduled posts.' It uses a specific verb ('List') and identifies the resource ('scheduled posts'), making the action and target unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_scheduled_post' (singular) or 'list_drafts', which might serve similar listing functions in different contexts, so it doesn't reach the highest score.
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 doesn't mention sibling tools like 'get_scheduled_post' (for a single post) or 'list_drafts' (for drafts), nor does it specify prerequisites, contexts, or exclusions for usage. The only implied usage is filtering by status, but this is a parameter detail, not a guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention permission requirements, whether partial updates are allowed, what happens to unchanged fields, or error conditions. The return statement is minimal and doesn't describe the format or what 'updated draft' means.
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 efficiently structured with a clear purpose statement followed by a well-organized parameter section. Every sentence serves a purpose, though the 'Returns' statement could be slightly more informative given there's no output schema description provided in context.
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 mutation tool with 4 parameters and no annotations, the description covers the basics but has significant gaps. It documents parameters well but lacks behavioral context about permissions, partial updates, error handling, and the return format. The existence of an output schema (per context signals) means the description doesn't need to detail return values, but other behavioral aspects are underspecified.
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 0% schema description coverage, the description compensates well by explaining all 4 parameters in the Args section. It identifies draft_id as required and the others as optional, and provides meaningful context about what each parameter represents (e.g., 'New content', 'New title', 'New comma-separated tags').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a content draft'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'edit_post' or 'update_scheduled_post', which prevents a perfect score.
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 about when to use this tool versus alternatives like 'edit_post' or 'update_scheduled_post'. It mentions optional parameters but doesn't explain when they should be used or what happens if none are provided beyond the required draft_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'Returns detailed performance analysis' but doesn't disclose behavioral traits like whether it's read-only (implied but not explicit), requires authentication, has rate limits, or how it handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
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?
Well-structured with a clear opening statement, bullet-point-like listing of analysis areas, and separate Args and Returns sections. The description is appropriately sized for a single-parameter tool, though the opening sentence 'Analyze your content performance comprehensively.' could be more specific to avoid slight redundancy with 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?
Given one parameter with good semantic coverage in the description, an output schema exists (so return values don't need explanation), and no complex behavioral requirements, the description is reasonably complete. The main gap is lack of guidance on when to use versus sibling tools, but for the tool's core functionality, it provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by explaining the single parameter 'post_limit' in the Args section: 'Number of posts to analyze (default: 30, max: 50)'. This adds crucial semantics beyond the bare schema, providing default value and maximum constraint. Since there's only one parameter, this is nearly complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze your content performance comprehensively' with specific analysis areas (posting patterns, engagement metrics, content types, posting times). It distinguishes from some siblings like 'analyze_engagement' or 'analyze_optimal_posting_times' by being more comprehensive, though the distinction from 'analyze_content_performance' (nearly identical name) is unclear.
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 explicit guidance on when to use this tool versus alternatives. The description mentions comprehensive analysis but doesn't specify when to choose it over more focused siblings like 'analyze_engagement', 'analyze_optimal_posting_times', or 'get_my_post_analytics'. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Cancel') and return ('success status'), but lacks details on permissions required, whether cancellation is reversible, error conditions (e.g., invalid job_id), or side effects. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement followed by parameter and return documentation in a bullet-like format. Every sentence earns its place with zero waste, making it easy to parse 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?
Given the tool's moderate complexity (a mutation with one parameter) and the presence of an output schema (which handles return values), the description is minimally complete. However, with no annotations and incomplete behavioral context, it leaves gaps in understanding permissions, errors, and usage scenarios, making it adequate but not thorough.
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 description explicitly documents the single parameter 'job_id' with its purpose ('ID of the scheduled post to cancel'), adding crucial meaning beyond the schema's 0% coverage. Since there's only one parameter and the description fully explains it, this compensates well for the schema gap, though it doesn't specify format or sourcing details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Cancel') and resource ('scheduled post'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_post' or 'delete_draft' which might also remove content, so it doesn't fully distinguish its specific scope.
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 doesn't mention prerequisites (e.g., needing a scheduled post ID), exclusions (e.g., cannot cancel already published posts), or compare to siblings like 'delete_post' for non-scheduled content. This leaves the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a deletion but doesn't clarify if it's reversible, requires specific permissions, has side effects (e.g., affecting scheduled posts), or details error conditions. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by a brief parameter explanation and return note. Every sentence adds value without redundancy, making it efficiently structured 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?
For a destructive tool with no annotations, the description is minimal but covers the basic action and parameter. The presence of an output schema reduces the need to detail return values, but it lacks critical behavioral context (e.g., irreversibility, permissions), making it only partially 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 description adds meaningful context for the single parameter 'draft_id' by specifying it's the 'ID of the draft to delete', which clarifies its role beyond the schema's type definition. With 0% schema description coverage and only one parameter, this compensates well, though it doesn't explain ID format or sourcing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a content draft'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete_post' or 'delete_comment', which have similar deletion semantics but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing draft), exclusions, or how it relates to siblings like 'delete_post' or 'cancel_scheduled_post', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Returns company details' but doesn't specify whether this is a read-only operation, requires authentication, has rate limits, or what happens on errors. For a tool with zero annotation coverage, this is insufficient—it only covers basic output intent without operational context.
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 well-structured and front-loaded with the core purpose, followed by parameter and return details. It uses bullet-like formatting for clarity without unnecessary verbosity. Every sentence adds value, though it could be slightly more concise by integrating the return statement into the opening line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return value details), the description is reasonably complete. It covers the purpose, parameter meaning, and output intent. However, it lacks behavioral context like authentication needs or error handling, which holds it back from a 5.
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 description coverage is 0%, but the description compensates by explaining the 'public_id' parameter as 'Company's public identifier (URL slug, e.g., 'microsoft')', adding crucial semantic context beyond the bare schema. Since there's only one parameter, this effectively covers it, though it doesn't detail format constraints beyond the example.
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's purpose: 'Get detailed company information' with a specific verb ('Get') and resource ('company information'). It distinguishes from siblings like 'search_companies' (which likely returns lists) and 'get_company_by_domain' (which uses a different identifier). However, it doesn't explicitly contrast with these siblings, keeping it from a perfect 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 provides no guidance on when to use this tool versus alternatives like 'get_company_by_domain' or 'search_companies'. It mentions the required parameter but offers no context about prerequisites, typical use cases, or limitations. This leaves the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'network size, growth indicators, and connection insights,' which gives some output context, but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied but not explicit), mention rate limits, describe data freshness, or note authentication requirements beyond 'authenticated user.' For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 efficiently structured in two sentences: the first states the purpose and scope, and the second specifies the return values. Every word adds value, with no redundancy or fluff. It's front-loaded with the core function, making it easy for an agent to quickly grasp the tool's role.
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 simplicity (0 parameters, output schema exists), the description is minimally adequate. It covers the purpose and output types, but lacks behavioral context (e.g., authentication needs, rate limits) that would be helpful even with an output schema. The presence of an output schema means the description doesn't need to detail return values, but it could better address when and how to use the tool in practice.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, focusing instead on the tool's purpose and output. This aligns with the baseline expectation for zero-parameter tools, where the description should not waste space on non-existent inputs.
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's purpose: 'Get statistics about the authenticated user's LinkedIn network' specifies the verb (get), resource (network statistics), and scope (authenticated user's LinkedIn network). It distinguishes from siblings like 'get_profile_views' or 'get_my_post_analytics' by focusing on network-level metrics rather than profile or content analytics. However, it doesn't explicitly differentiate from all siblings (e.g., 'analyze_engagement' could overlap), preventing a perfect score.
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 doesn't mention prerequisites (e.g., authentication status), compare to similar tools (e.g., 'analyze_engagement' for engagement metrics), or specify use cases (e.g., for network growth analysis vs. content performance). The absence of usage context leaves the agent to infer applicability from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves contact info but doesn't mention potential limitations, such as rate limits, privacy restrictions, or whether the profile must be public or connected. For a data retrieval tool with zero annotation coverage, this is a significant gap in 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 well-structured and concise, with a clear purpose statement followed by brief sections for arguments and returns. Every sentence adds value, and there's no unnecessary information. It could be slightly improved by integrating the argument and return details more seamlessly, but overall it's 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?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It covers the purpose, parameter meaning, and return types. However, it lacks usage guidelines and behavioral details, which are important for a tool interacting with external data like LinkedIn profiles, preventing a perfect score.
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 description adds meaningful context for the single parameter: 'profile_id: LinkedIn public ID.' Since schema description coverage is 0%, this compensates by clarifying what the parameter represents beyond just a string. However, it doesn't provide examples or format details, such as how to obtain the public ID, which slightly limits its utility.
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's purpose: 'Get contact information for a LinkedIn profile.' It specifies the verb ('Get'), resource ('contact information'), and target ('LinkedIn profile'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_profile' or 'get_my_profile', which might also retrieve profile data but not specifically 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 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 doesn't mention any prerequisites, such as authentication status or profile accessibility, nor does it compare to sibling tools like 'get_profile' or 'search_people' that might retrieve different types of profile data. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Returns remaining API calls and rate limit information,' which gives basic output context, but lacks details on permissions, rate limits themselves, error handling, or whether it's a read-only operation. For a tool about rate limits, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds necessary detail in the second. Both sentences earn their place by clarifying the action and return value, with zero wasted words. It's appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. It states the purpose and return value, but with no annotations and many complex siblings, it could better explain behavioral aspects like when to call it or what the output schema contains. The output schema reduces burden, but more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter information (none needed), but it doesn't detract from the schema's completeness. A 5 would require extra value beyond the schema, which isn't applicable here.
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's purpose with 'Get current rate limit status' (specific verb + resource). It distinguishes itself from siblings by focusing on API rate limits rather than content, profiles, or posts. However, it doesn't explicitly differentiate from potential similar tools (none exist in the sibling list), so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after API calls), frequency, or context (e.g., before batch operations). With many sibling tools for analytics and content management, usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('publish') and return ('published post details'), but lacks critical behavioral details: permission requirements, whether publishing is irreversible, rate limits, error conditions, or how visibility affects the post. For a mutation tool with zero annotation coverage, this is insufficient.
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 well-structured and front-loaded: the first sentence states the purpose, followed by clear 'Args' and 'Returns' sections. Every sentence adds value without redundancy, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 2 parameters), no annotations, and an output schema (which handles return details), the description is moderately complete. It covers purpose and parameters but lacks behavioral context (e.g., side effects, errors). The output schema reduces the need to explain returns, but more guidance on usage and transparency 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'draft_id' as 'ID of the draft to publish' and 'visibility' as 'Post visibility - PUBLIC, CONNECTIONS, or LOGGED_IN', including enum values not in the schema. This clarifies both parameters beyond their schema definitions, though it doesn't cover default behavior for 'visibility'.
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's purpose: 'Publish a draft as a LinkedIn post.' It specifies the verb ('publish') and resource ('draft'), but doesn't explicitly differentiate from sibling tools like 'create_post' or 'schedule_post', which also create posts. The distinction is implied (publishing vs. creating/scheduling), but not explicitly stated.
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 doesn't mention prerequisites (e.g., needing a draft from 'create_draft'), exclusions, or comparisons to tools like 'create_post' (for direct posting) or 'schedule_post' (for delayed posting). Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns the scheduled post details with job_id,' which gives some output context, but doesn't cover critical aspects like required permissions, rate limits, error conditions, or what happens if scheduling fails. For a mutation tool with zero annotation coverage, this is insufficient.
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 well-structured and appropriately sized. It starts with a clear purpose statement, then lists parameters with brief explanations in a formatted 'Args' section, and ends with return information. Every sentence adds value, though the formatting could be slightly more concise (e.g., combining some lines).
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 (4 parameters, mutation operation) and the presence of an output schema (implied by 'Returns...'), the description is reasonably complete. It covers the basic operation, parameters, and output indication. However, without annotations and with sibling tools present, it could better address usage context and behavioral details.
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 description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'content' as 'Post content', 'scheduled_time' with format details, 'visibility' with enum values, and 'timezone' with default. This compensates well for the schema's lack of descriptions, though it doesn't cover validation rules or examples beyond the ISO format mention.
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's purpose: 'Schedule a post for future publishing.' This is a specific verb ('Schedule') with a resource ('a post') and indicates the temporal aspect ('for future publishing'). However, it doesn't explicitly differentiate from sibling tools like 'create_post' or 'update_scheduled_post', which would be needed for a perfect score.
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 doesn't mention sibling tools like 'create_post' (for immediate publishing), 'create_draft' (for unscheduled drafts), or 'update_scheduled_post' (for modifying scheduled posts). There's no context about prerequisites 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It adds valuable context about implementation priorities and potential limitations (Pro plan requirement, bot detection risks), which helps the agent understand reliability and cost implications. However, it doesn't cover other important behavioral aspects like rate limits, authentication requirements, or error handling.
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 well-structured with clear sections (purpose, args, returns, implementation details). Every sentence adds value, though the technical implementation details might be more appropriate in a separate section. The front-loaded purpose statement is effective, but the two-paragraph structure could be slightly more streamlined.
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 an output schema (so return values are documented elsewhere), the description provides good context. It covers purpose, parameters, implementation constraints, and limitations. For a search tool with 2 parameters and output schema, this is reasonably complete, though it could benefit from more usage guidance relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents both parameters ('keywords' and 'limit') with clear explanations of their purpose and constraints (default: 10, max: 50). This adds meaningful semantics beyond the bare schema. However, it doesn't provide examples or format guidance for the 'keywords' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for companies on LinkedIn.' It specifies the verb ('search') and resource ('companies on LinkedIn'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_people' or 'search_jobs', which would be needed for a perfect score.
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. While it mentions two backend implementations (Fresh Data API and linkedin-api), this is technical detail rather than usage context. There's no mention of when to choose this over other search tools like 'search_people' or 'search_jobs' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'returns the created draft details' but doesn't disclose behavioral traits like whether this is a write operation (implied by 'create'), permission requirements, rate limits, or what happens if a draft with duplicate content is created. The description is minimal and lacks crucial operational context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a structured Args section and return statement. It's efficient with zero wasted sentences, though the Args formatting is slightly verbose. Every sentence earns its place by clarifying parameters and output.
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 a creation tool with 3 parameters, no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers purpose and parameters but lacks behavioral context like side effects or error conditions. The output schema reduces the need to explain returns, but more operational guidance 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?
With 0% schema description coverage, the description compensates by explaining all three parameters: 'content' as draft content, 'title' as optional for organization, and 'tags' as comma-separated for categorization. This adds meaningful semantics beyond the bare schema types, though it doesn't specify format details like tag constraints or content length limits.
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 creates a content draft for later publishing, specifying the verb ('create') and resource ('content draft'). It distinguishes from siblings like 'create_post' or 'create_document_post' by emphasizing it's for 'later publishing' rather than immediate posting. However, it doesn't explicitly contrast with 'update_draft' or '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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'for later publishing,' suggesting this is a preparatory step before publishing. It doesn't provide explicit when-to-use vs. alternatives like 'create_post' (immediate posting) or 'update_draft' (modifying existing drafts). No exclusions or prerequisites 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it 'Returns list of company posts/updates,' which gives some output context, but it doesn't cover important aspects like rate limits, authentication needs, pagination, error handling, or data freshness. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's 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 well-structured and concise, with a clear purpose statement followed by parameter details and return information. Every sentence adds value without redundancy, and it's front-loaded with the main functionality. The bullet-point style for args enhances readability without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the purpose, parameters, and output at a high level. However, the lack of behavioral details (e.g., rate limits, error cases) and usage guidelines relative to siblings prevents a perfect score.
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 description adds meaningful context for both parameters beyond the input schema, which has 0% description coverage. It explains that 'public_id' is the 'Company's public identifier (URL slug)' and 'limit' has a 'default: 10, max: 50.' This clarifies usage and constraints effectively, compensating well for the lack of schema descriptions.
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's purpose: 'Get recent posts/updates from a company page.' It specifies the verb ('Get') and resource ('posts/updates from a company page'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_company' or 'get_profile_posts', which would be needed for a perfect score.
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 doesn't mention sibling tools like 'get_company' (which might retrieve company metadata) or 'get_profile_posts' (which might retrieve posts from individual profiles), nor does it specify prerequisites or contexts for usage. This lack of comparative guidance limits its effectiveness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Returns recent feed posts with engagement data,' which gives some output context, but lacks details on permissions needed, rate limits, error conditions, or whether it's a read-only operation (implied by 'Get' but not explicit). For a tool with no annotations, this leaves significant gaps in understanding its 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 well-structured and concise, with a clear opening sentence stating the purpose, followed by bullet-like parameter explanations and a closing sentence on returns. Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential 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?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is reasonably complete. It covers purpose, parameters, and return value, and the output schema likely handles return details. However, it lacks context on authentication needs or error handling, which could be important for a LinkedIn API tool.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'limit' is the 'Maximum number of feed items to return' with default and max values, and 'use_cache' indicates 'Whether to use cached data if available' with a default. This compensates well for the schema's lack of descriptions, though it doesn't detail caching behavior implications.
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's purpose: 'Get the authenticated user's LinkedIn feed' specifies both the verb ('Get') and resource ('LinkedIn feed'), and clarifies it's for the authenticated user. However, it doesn't explicitly differentiate from sibling tools like 'get_my_posts' or 'get_profile_posts', which might retrieve similar content but from different sources.
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. With many sibling tools that might retrieve posts or content (e.g., 'get_my_posts', 'get_profile_posts', 'get_company_updates'), there's no indication of when this feed-specific tool is preferred or what distinguishes it from other content-fetching 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: returns posts with engagement metrics (likes, comments, shares), mentions caching behavior via 'use_cache', and implies a read-only operation ('Get'). However, it lacks details on permissions (e.g., public vs. private profiles), rate limits, error handling, or pagination. The description doesn't contradict annotations (none exist), but could be more comprehensive for a tool with potential access restrictions.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args' section with clear parameter explanations, and ends with return value info. Every sentence adds value, though the 'Args' label is slightly redundant. It's efficient with minimal waste.
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 (3 parameters, no annotations, but has output schema), the description is partially complete. It covers parameters well and mentions return metrics, but lacks context on authentication, error cases, or sibling differentiation. The output schema exists (not shown here), so the description needn't detail return values extensively, but more behavioral context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'profile_id' as 'LinkedIn public ID or URN', 'limit' with default and max values, and 'use_cache' explaining its purpose. This goes beyond the bare schema (which only shows types and defaults) by clarifying formats and constraints. However, it doesn't detail parameter interactions or edge cases.
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's purpose: 'Get posts from a specific LinkedIn profile' with the verb 'Get' and resource 'posts from a specific LinkedIn profile'. It distinguishes from siblings like 'get_my_posts' (personal posts) and 'get_feed' (general feed), but doesn't explicitly mention these distinctions. The purpose is specific and actionable.
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 doesn't mention siblings like 'get_my_posts' for the user's own posts or 'get_feed' for a broader feed. There's no context about prerequisites (e.g., authentication) or exclusions (e.g., private profiles). Usage is implied by the purpose but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the action (marking as seen/read) and warns about using an unofficial API, which is valuable context. However, it doesn't mention authentication requirements, rate limits, side effects (e.g., whether this affects notifications), or error conditions. The description adds some behavioral context but leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured clearly, and the WARNING is placed effectively. There's minimal waste, though the 'Returns success status' could be slightly more informative.
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 (single-parameter mutation), no annotations, and the presence of an output schema (which handles return values), the description is partially complete. It covers the purpose and parameter well but lacks behavioral details like permissions, side effects, or error handling. The output schema existence means the description doesn't need to explain return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly documents the single parameter 'conversation_urn' and clarifies it's a 'Conversation URN ID', adding meaningful semantics beyond the schema's type information. This fully compensates for the lack of schema descriptions, making the parameter well-understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('mark') and resource ('conversation') with the specific action 'as read/seen'. It distinguishes this from sibling tools like 'get_conversation' or 'get_conversations' which are read-only operations, but doesn't explicitly differentiate from other potential conversation-modification tools (though none are present in the sibling list). The purpose is specific but could be slightly more distinctive.
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. While it's the only conversation-marking tool among siblings, it doesn't mention prerequisites (e.g., needing an existing conversation), when not to use it, or what 'success status' entails. The WARNING about unofficial API is useful but doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation but doesn't mention permission requirements, whether changes are reversible, rate limits, or what happens when optional parameters are omitted. The description lacks crucial behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and economical. It starts with the core purpose, then provides a clean parameter breakdown with helpful annotations (like 'optional' and format requirements), and ends with the return value. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (though not shown here), the description doesn't need to detail return values. It covers the essential operation and parameters well. However, for a mutation tool with no annotations, it should ideally mention permission requirements or side effects to be 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 description provides clear semantic information about all four parameters beyond what the schema offers (which has 0% description coverage). It explains that 'job_id' identifies the scheduled post, 'content' is new content, 'scheduled_time' should be in ISO format, and 'visibility' controls post visibility. This significantly compensates for the schema's lack of descriptions.
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 ('Update') and resource ('a scheduled post'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar tools like 'update_draft' or 'edit_post' in the sibling list, which would require more specific context about what distinguishes scheduled posts from other content types.
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 like 'edit_post' or 'update_draft', nor does it mention prerequisites or constraints. While the required 'job_id' parameter is documented in the schema, the description doesn't explain how to obtain this ID or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what the tool returns ('availability status and feature capabilities'), which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a tool with no annotation coverage, this leaves significant 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 extremely concise at just two sentences. The first sentence states the purpose, and the second describes the return value. Every word earns its place with zero waste or redundancy. It's appropriately front-loaded with the core functionality.
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 that the tool has no parameters, an output schema exists (which should document return values), and no annotations, the description provides basic but incomplete context. It states purpose and return types but lacks behavioral details needed for full understanding. The output schema should cover return values, so the description doesn't need to explain those, but other contextual gaps remain.
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 (schema coverage 100%), so no parameter documentation is needed. The description appropriately doesn't discuss parameters. With zero parameters, the baseline is 4, as there's nothing to compensate for and no redundancy with schema descriptions.
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's purpose: 'Check if browser automation is available for profile updates.' It specifies the action (check), target (browser automation), and context (for profile updates). However, it doesn't explicitly differentiate from sibling tools, as none appear to be direct alternatives for checking automation status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for profile updates'), suggesting this tool should be used when preparing to update profiles via automation. However, it doesn't provide explicit guidance on when to use this tool versus alternatives or when not to use it. No sibling tools appear to offer similar functionality, so differentiation isn't needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: it mentions the return format ('list of conversations with participants and last message preview') and includes a WARNING about using an unofficial API and bot detection risks. However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a read operation.
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 appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are clear, and the WARNING is placed effectively. It could be slightly more concise by integrating the Args into the main text, but overall, it's efficient with minimal 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?
Given the tool's moderate complexity (a read operation with one parameter), the description is fairly complete. It explains the purpose, parameter, return value, and includes a risk warning. With an output schema present, it doesn't need to detail return values further. However, it lacks usage guidelines and some behavioral details like error cases.
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 description adds meaningful semantics for the single parameter 'limit', explaining it as 'Maximum conversations to return (default: 20)'. Since schema description coverage is 0% and there's only one parameter, this compensates well. However, it doesn't specify constraints like minimum/maximum values or if it's optional (implied by default).
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's purpose: 'Get your LinkedIn messaging conversations.' It specifies the verb ('Get') and resource ('LinkedIn messaging conversations'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_conversation' or 'get_conversation_details', which prevents a perfect score.
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 doesn't mention sibling tools like 'get_conversation' (singular) or 'get_conversation_details', nor does it explain prerequisites or contexts for usage. The WARNING about the unofficial API is a caution but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: the 'WARNING: Uses unofficial API' indicates potential risks like rate limits, instability, or authentication needs not covered elsewhere. However, it doesn't detail response format, error handling, or other behavioral traits (e.g., whether it's read-only or has side effects), leaving gaps in 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 appropriately sized and front-loaded, with the core purpose stated first, followed by parameter details and a warning. Each sentence adds value: the first defines the tool, the second explains the parameter, the third describes the return, and the fourth provides a critical warning. There's minimal waste, though the structure could be slightly more polished (e.g., integrating the warning more seamlessly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose, parameter semantics, and a key behavioral warning. However, with no annotations and reliance on an unofficial API, it could benefit from more guidance on usage scenarios or error cases to fully compensate for the lack of structured metadata.
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 description adds meaningful semantics beyond the input schema. The schema has 0% description coverage for the single parameter 'job_id,' but the description specifies it as 'LinkedIn job ID,' clarifying the expected format and source. This compensates well for the low schema coverage, though it could be more detailed (e.g., explaining how to obtain this ID).
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's purpose: 'Get skills required for a job posting.' It specifies the verb ('Get') and resource ('skills'), and distinguishes it from sibling tools like 'get_job' (which likely gets job details) and 'get_profile_skills' (which gets skills from a profile). However, it doesn't explicitly differentiate from 'search_jobs' or other job-related tools, keeping it from a perfect score.
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 minimal usage guidance. It mentions that the tool returns 'required and preferred skills for the job' and includes a 'WARNING: Uses unofficial API,' which hints at potential reliability or policy issues. However, it lacks explicit instructions on when to use this tool versus alternatives like 'get_job' (for general job info) or 'search_jobs' (for finding jobs), and doesn't specify prerequisites 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), which is safe, but doesn't mention potential limitations like rate limits, authentication needs, or data freshness. It adds some context about the return format ('categorized by endorsement count with top endorsers'), but lacks details on error handling or performance.
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 concise and well-structured: a clear purpose statement followed by brief parameter and return explanations. Every sentence adds value without redundancy. It could be slightly more front-loaded by integrating the return info into the main sentence, but overall it's 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?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It covers the purpose, parameter meaning, and return format. With no annotations, it could add more behavioral details, but the output schema likely handles return values, making this adequate for the context.
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 description adds meaningful context for the single parameter: 'profile_id: LinkedIn public ID.' Since schema description coverage is 0% and there's only one parameter, this compensates well by clarifying what 'profile_id' refers to. However, it doesn't specify format examples (e.g., URL vs. username), so it's not a perfect 5.
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's purpose: 'Get skills and endorsements for a LinkedIn profile.' It specifies the verb ('Get') and resource ('skills and endorsements for a LinkedIn profile'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_profile' or 'get_job_skills,' which keeps it from a perfect score.
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. For example, it doesn't mention when to choose this over 'get_profile' (which might include skills) or 'get_job_skills' (which is for jobs, not profiles). This lack of context leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns specific diagnostic information (LinkedIn client status, settings, cookie file, errors), which is useful behavioral context. However, it doesn't mention whether this operation is safe, has side effects, requires authentication, or has rate limits. For a debugging tool with zero annotation coverage, this leaves significant 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 perfectly concise and well-structured. The first sentence states the purpose, followed by a bulleted list of return information. Every sentence earns its place, with 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?
Given that this is a zero-parameter debugging tool with an output schema (implied by 'Returns information about'), the description is reasonably complete. It specifies what diagnostic information is returned, which complements the output schema. However, it lacks context about when and why to use debugging tools, which slightly reduces completeness for an agent.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on what the tool returns. This meets the baseline of 4 for zero-parameter tools.
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's purpose: 'Debug tool to check the internal state of the MCP server.' It specifies the verb ('check') and resource ('internal state'), and distinguishes it from all sibling tools which are LinkedIn operations, not debugging tools. It doesn't explicitly contrast with hypothetical other debugging tools, so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when debugging is appropriate, what symptoms might prompt its use, or whether it should be used proactively. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool returns but lacks critical behavioral details: it doesn't specify whose profile is assessed (e.g., the current user's or another's), whether it requires authentication, if it has rate limits, or how suggestions are generated. The description is functional but misses key operational 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 extremely concise and well-structured: a single sentence stating the action, followed by a bulleted list of three specific return items. Every element earns its place with zero waste, making it easy to scan 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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (so return values needn't be detailed), the description is reasonably complete. However, it lacks behavioral context (e.g., authentication needs, target profile) that would be helpful for an agent, especially with no annotations. It's adequate but has clear gaps in operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on outputs rather than inputs. A baseline of 4 is applied here since the description doesn't need to compensate for any parameter gaps, and it efficiently describes the return 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 clearly states the tool's purpose with a specific verb ('calculate') and resource ('profile completeness score'), plus it lists the three key return values. It effectively distinguishes this tool from its many siblings, which focus on analysis, creation, deletion, or retrieval of specific profile data rather than calculating an overall completeness metric.
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. While it implicitly suggests usage for assessing profile completeness, it doesn't mention prerequisites (e.g., whether a profile must exist), exclusions, or how it relates to sibling tools like 'get_my_profile' or 'get_profile_sections' that might provide overlapping or complementary data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get') and specifies the scope ('all editable profile sections'), but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or whether the data is real-time or cached. The description adds some context but lacks critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list of returned sections. It's efficient, with no wasted words, and the structure enhances readability by clearly separating the overview from details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, output schema exists), the description is reasonably complete. It states the purpose and outlines the return content, which aligns with the output schema. However, it could improve by addressing behavioral aspects like authentication or data freshness, especially since no annotations are provided.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the return value. It adds value by listing the sections included in the output, which complements the output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all editable profile sections with current content.' It specifies the verb ('Get') and resource ('editable profile sections'), and lists the types of sections returned. However, it doesn't explicitly differentiate from sibling tools like 'get_my_profile' or 'get_profile', which might provide overlapping or different profile data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_my_profile' or 'get_profile', nor does it specify contexts or prerequisites for use. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the browser automation requirement (important behavioral context) and mentions the 220-character limit for the headline parameter. However, it doesn't describe authentication needs, rate limits, whether the update is reversible, or what happens on failure. The 'Returns success status' is vague about output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three distinct sections: purpose statement, prerequisite, and parameter/return documentation. Each sentence earns its place. However, the 'Args:' and 'Returns' formatting could be more integrated, and the purpose statement is somewhat terse ('Update profile headline.' could be slightly more descriptive).
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 that this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema present, the description is moderately complete. It covers the prerequisite and parameter constraint, but lacks details about authentication, error conditions, and what 'success status' entails. The output schema existence reduces the need to describe return values, but more behavioral context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds crucial semantic information: the 'headline' parameter is 'New headline text' with a 'max 220 characters' constraint. This provides meaning beyond the bare schema type. However, it doesn't mention format requirements (e.g., plain text vs HTML) or validation rules beyond length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('profile headline'), making the purpose unambiguous. It distinguishes from sibling tools like 'update_profile_summary' by specifying the exact profile field being modified. However, it doesn't explicitly contrast with other profile update tools beyond naming the specific field.
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 provides one explicit usage guideline: 'Requires Playwright browser automation to be enabled.' This is a clear prerequisite. However, it doesn't specify when to use this tool versus alternatives like 'update_profile_summary' or other profile modification tools, nor does it mention any exclusions or complementary 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?
With no annotations provided, the description carries the full burden. It discloses that the tool returns 'basic info and success/failure status for each,' which adds useful behavioral context beyond the input schema. However, it lacks details on error handling, rate limits, authentication requirements, or what constitutes 'basic info,' leaving gaps for a mutation-free but data-sensitive operation.
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 well-structured and front-loaded with the core purpose, followed by specific parameter and return details. Every sentence adds value, with no redundant information. It could be slightly more concise by integrating the Args/Returns into the main text, but it remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameter semantics, and high-level return behavior. For a read-only batch tool, this provides sufficient context, though adding authentication or rate limit notes would enhance it.
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 description coverage is 0%, so the description must compensate. It adds crucial semantics: 'profile_ids' is a 'comma-separated list of profile public IDs (max 10),' clarifying format, type, and constraints not in the schema. This fully documents the single parameter, making it clear and actionable for the agent.
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's purpose: 'Get multiple LinkedIn profiles efficiently.' It specifies the resource (LinkedIn profiles) and the verb (get multiple), and distinguishes it from the sibling 'get_profile' tool by handling multiple profiles. However, it doesn't explicitly contrast with other profile-related tools like 'get_profile_articles' or 'get_profile_skills'.
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 through 'efficiently' and the parameter constraint 'max 10', suggesting this tool is for batch retrieval rather than single profiles. However, it doesn't explicitly state when to use this versus 'get_profile' or other profile tools, nor does it mention prerequisites like authentication or rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the required product enablement and default/max values for 'count' (default 25, max 100). However, it doesn't describe important behavioral traits like rate limits, authentication needs beyond the product requirement, pagination behavior, or what happens with invalid inputs. The description doesn't contradict any annotations (since none exist).
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 well-structured with a clear purpose statement, prerequisite note, and organized parameter/return sections. Every sentence adds value: the first states the purpose, the second provides critical prerequisite information, and the parameter/return sections document essential details. It could be slightly more concise by integrating the prerequisite into a single flowing paragraph, but overall it's 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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, prerequisite, parameter semantics, and return format. The existence of an output schema means the description doesn't need to detail return values. However, it lacks guidance on error conditions, rate limits, or sibling tool differentiation, which would make it more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It successfully adds meaning for all three parameters: clarifies 'advertiser_name' as the advertiser/company name, specifies 'country' uses ISO 3166-1 alpha-2 codes and is optional, and explains 'count' default and max values. This goes beyond the bare schema, though it doesn't provide examples or elaborate on format constraints beyond the country code standard.
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's purpose: 'Search for all ads by a specific advertiser/company.' It specifies the verb ('search') and resource ('ads'), and distinguishes it from sibling tools like 'search_ads' and 'search_ads_by_keyword' by focusing on advertiser-based filtering. However, it doesn't explicitly contrast with these siblings in the description text itself.
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 provides some usage context by stating the prerequisite: 'Requires "LinkedIn Ad Library" product enabled in your LinkedIn Developer app.' This implies when the tool can be used. However, it doesn't explicitly guide when to choose this tool over alternatives like 'search_ads' or 'search_ads_by_keyword', nor does it mention exclusions or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the prerequisite (Playwright browser automation) and the return value ('Returns success status.'), which adds useful context beyond the input schema. However, it doesn't cover other behavioral traits like authentication needs, rate limits, or what happens if the upload fails, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. It uses bullet points for prerequisites and parameters, making it structured and easy to scan. However, the 'Returns success status.' could be integrated more smoothly, and there's minor redundancy in stating the tool name implicitly.
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 1 parameter with 0% schema coverage, no annotations, but an output schema exists, the description does a decent job. It explains the parameter, mentions a prerequisite, and notes the return, which covers basics. However, for a mutation tool (upload), it could better address error handling or side effects to be 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 description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'photo_path' is an 'Absolute path to the photo file (JPG, PNG)', which clarifies the parameter's purpose and acceptable file types beyond the schema's basic string type. This is helpful, but it doesn't detail constraints like file size or dimensions, keeping it from a perfect score.
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's purpose: 'Upload a new background/banner photo.' It specifies the verb (upload) and resource (background/banner photo), which is clear and actionable. However, it doesn't explicitly differentiate from its sibling 'upload_profile_photo' beyond the photo type, missing a direct comparison that would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance: 'Requires Playwright browser automation to be enabled.' This implies a prerequisite but doesn't specify when to use this tool versus alternatives like 'upload_profile_photo' or other media upload tools. It offers basic context but lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the browser automation requirement and implies a write operation ('Add'), but lacks details on permissions, side effects, or error handling. It adds some context but not comprehensive behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by prerequisite and parameter details in a structured format. Every sentence adds value with zero waste, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a write operation with one parameter) and the presence of an output schema (handling return values), the description is fairly complete. It covers purpose, prerequisite, parameter, and return, though could improve on behavioral details like error cases.
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 description explicitly documents the single parameter ('skill_name: Name of the skill to add'), adding meaning beyond the 0% schema coverage. Since there's only one parameter and it's fully explained, this compensates well for the schema gap, though not perfectly (e.g., format constraints).
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 ('Add a skill') and target ('to your profile'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'get_profile_skills' or 'update_profile_headline', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires Playwright browser automation to be enabled'), which provides some usage context. However, it doesn't specify when to use this tool versus alternatives (e.g., 'update_profile_summary') or any exclusions, keeping it at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing 'posting history' and providing 'data-driven recommendations,' but does not specify whether this is a read-only operation, what permissions are required, how long it takes, or if there are rate limits. For a tool with no annotation coverage, this leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, elaboration on analysis scope, and a dedicated 'Args' section. It is appropriately sized at four sentences, with minimal redundancy. However, the 'Returns' statement could be integrated more seamlessly, and some sentences could be slightly tightened for efficiency.
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 (one parameter, output schema exists), the description provides a solid foundation. It explains the purpose, parameter semantics, and return value prioritization. With an output schema handling return details, the description does not need to elaborate on response structure. However, it could better address behavioral aspects given the lack of annotations.
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 description coverage is 0%, but the description includes an 'Args' section that documents the single parameter 'post_limit' with its default value and purpose ('Number of posts to analyze for recommendations'). This adds meaningful context beyond the schema, though it does not specify constraints like minimum/maximum values or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get personalized posting recommendations based on your content performance.' It specifies the verb ('Get'), resource ('posting recommendations'), and scope ('personalized...based on your content performance'). It distinguishes from siblings like 'analyze_optimal_posting_times' by focusing on personalized recommendations rather than general timing analysis.
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 by mentioning 'personalized posting recommendations based on your content performance,' suggesting it should be used when seeking data-driven advice for content strategy. However, it lacks explicit guidance on when to use this versus alternatives like 'analyze_my_content_performance' or 'generate_my_content_calendar,' and does not specify prerequisites 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?
With no annotations provided, the description carries full burden. It discloses that view count requires Partner API access (a behavioral constraint), and mentions the return format includes engagement metrics. However, it doesn't cover rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'get' implies it).
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 efficiently structured with a clear purpose statement, parameter documentation, return information, and an important note. Every sentence adds value with zero wasted words. The information is front-loaded with the core purpose first.
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 an output schema (so return values don't need explanation in description), one simple parameter, and no annotations, the description provides good context. It covers purpose, parameter meaning, return content, and a key access limitation. For a straightforward read operation, this is reasonably complete, though could mention authentication or rate limits.
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 description adds meaningful context for the single parameter: 'post_urn: LinkedIn post URN' clarifies what the parameter represents beyond the schema's basic string type. With 0% schema description coverage and only one parameter, this provides adequate semantic information, though it doesn't explain URN format or validation rules.
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's purpose: 'Get analytics for a specific post' with a specific resource (LinkedIn post) and verb (get analytics). It distinguishes from siblings like 'get_my_post_analytics' by specifying 'for a specific post' rather than 'my posts', though it doesn't explicitly name the sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the note about Partner API access for view count, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_my_post_analytics' or 'analyze_content_performance'. No when-not-to-use guidance or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the data source (LinkedIn via Professional Network Data API) and return format ('organized by category'), which adds useful context. However, it doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or error conditions, which are important for a read operation with external API dependencies.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by context about the API and insights, then clearly labeled 'Args' and 'Returns' sections. Every sentence adds value without redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameter semantics, and data context. However, for a tool with no annotations, it could better address behavioral aspects like permissions or limitations to fully compensate for the lack of structured metadata.
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 description adds meaningful semantics beyond the input schema: it explains that 'profile_id' is a 'LinkedIn public ID' with an example ('e.g., "johndoe"'), which clarifies the parameter's purpose and format. Since schema description coverage is 0% (no schema descriptions), this compensates well for the single parameter, though it doesn't detail validation rules or constraints.
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's purpose: 'Get profile interests including influencers, companies, groups, and topics.' It specifies the verb ('Get') and resource ('profile interests') with concrete categories. However, it doesn't explicitly differentiate from sibling tools like 'get_profile' or 'get_profile_sections' beyond mentioning this data is unique to the Professional Network Data API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating this data provides 'insights into what/who a person follows on LinkedIn,' suggesting it's for analyzing user interests. It doesn't provide explicit when-to-use guidance versus alternatives (e.g., when to use this over 'get_profile'), nor does it mention prerequisites or exclusions, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only partially discloses behavior. It mentions the API source ('Professional Network Data API') and return data structure, but doesn't address critical aspects like authentication requirements, rate limits, error conditions, or whether it accesses public vs. private data. For a tool with zero annotation coverage, this leaves significant 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 efficiently structured with a clear purpose statement, API context, and separate Args/Returns sections. Every sentence adds value without redundancy, and information is front-loaded with the core functionality stated first.
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 (single parameter, read operation), the description covers purpose, parameter meaning, and return content adequately. The existence of an output schema reduces the need to detail return values. However, the lack of behavioral context (authentication, errors, limits) prevents a perfect score despite good coverage elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by clearly explaining the single parameter's purpose ('Full URL of the LinkedIn article') in the Args section. It adds essential context beyond the bare schema type, though it doesn't specify URL format requirements or validation rules.
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 ('Get the full content'), target resource ('LinkedIn article'), and scope ('complete article content, author information, and engagement metrics'). It distinguishes this read operation from sibling tools that analyze, create, or modify content rather than fetching raw article data.
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 by specifying it fetches 'full content' from a URL, suggesting it's for retrieving existing articles rather than creating or analyzing them. However, it doesn't explicitly state when to use this versus alternatives like 'get_profile_articles' or 'analyze_content_performance', nor does it mention prerequisites 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?
With no annotations provided, the description carries full burden. It discloses the browser automation requirement and mentions a character limit (max 2600 characters), which adds useful behavioral context. However, it doesn't cover other important aspects like authentication needs, rate limits, whether the update is reversible, or what happens to existing summary content, leaving gaps in 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 appropriately sized with three clear sections: purpose statement, prerequisite, and parameter/return explanation. It's front-loaded with the main action. The only minor issue is that 'Returns success status' could be integrated more smoothly, but overall it's efficient with minimal 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?
Given this is a mutation tool with no annotations, 0% schema coverage, but with an output schema, the description does a good job covering the essential aspects: purpose, prerequisite, parameter details, and return indication. It could be more complete by addressing authentication or error scenarios, but it's substantially adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description adds significant value by explaining the parameter's purpose ('New summary text') and constraint ('max 2600 characters'). This compensates well for the schema gap, though it doesn't mention formatting requirements or examples, preventing a perfect score.
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 ('Update') and target ('profile summary/about section'), providing specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'update_profile_headline' or 'update_profile_contact_info' that also modify profile sections, so it doesn't reach the highest clarity level.
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 context about when to use it ('Requires Playwright browser automation to be enabled'), which is crucial guidance. However, it doesn't mention when NOT to use it or alternatives (e.g., when browser automation isn't available, or if other profile update tools might be more appropriate), preventing a perfect score.
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 no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns data including view count and viewer information, notes limitations based on LinkedIn subscription, and includes a critical WARNING about using an unofficial API (implying potential risks like rate limits or instability). This adds significant value beyond basic functionality, though it could mention authentication requirements or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return details and a critical warning. Every sentence earns its place: the first states what it does, the second clarifies output, and the third provides essential risk disclosure. It's appropriately sized with zero 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?
Given the tool's complexity (read-only data retrieval), no annotations, 0 parameters, and an output schema exists, the description is largely complete. It covers purpose, output semantics, and a key behavioral warning. However, it could briefly mention what the output schema contains (e.g., data structure) for full context, but the output schema likely handles that.
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 0 parameters with 100% coverage, so the baseline is 4. The description doesn't add parameter details (as there are none), but it doesn't need to—it efficiently focuses on output semantics and warnings. No points are deducted since it compensates appropriately for the lack of parameters.
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's purpose: 'Get profile view statistics for the authenticated user.' It specifies the verb ('Get') and resource ('profile view statistics'), and distinguishes it from siblings like 'get_my_profile' or 'get_profile' by focusing on view metrics. However, it doesn't explicitly differentiate from analytics siblings (e.g., 'analyze_engagement'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it's for the authenticated user's profile views, and the WARNING about the unofficial API suggests caution. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'get_my_post_analytics' for post-specific data) or provide clear exclusions. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the API source and lookup behavior, but doesn't mention error conditions, rate limits, authentication requirements, or whether this is a read-only operation. The description adds some behavioral context but leaves significant 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 efficiently structured with a clear purpose statement, API context, example, and separate Args/Returns sections. Every sentence adds value with no redundancy. The formatting makes it easy to scan and understand.
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 (single-parameter lookup), no annotations, but with an output schema present, the description provides adequate context. It covers the purpose, parameter meaning, return value examples, and API source. The output schema means the description doesn't need to detail return structure, which it respects.
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 description adds meaningful semantics beyond the schema's 0% coverage. It explains what the 'domain' parameter represents ('Company website domain'), provides an example format ('anthropic.com'), and clarifies the lookup logic. Since schema coverage is 0%, the description compensates well for the single 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 clearly states the tool's purpose with a specific verb ('Get'), resource ('company information'), and lookup method ('by website domain'). It distinguishes from the sibling 'get_company' tool by specifying the domain-based lookup approach rather than a general company lookup.
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 by mentioning the Professional Network Data API and providing an example, but doesn't explicitly state when to use this tool versus alternatives like 'search_companies' or 'get_company'. No guidance on prerequisites or exclusions is 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?
No annotations are provided, so the description carries full burden. It discloses the data source (Professional Network Data API) and return format, but doesn't mention rate limits, authentication requirements, or whether this is a read-only operation. The description adds some behavioral context but leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, implementation detail, and organized parameter/return sections. Every sentence adds value with no wasted words, and key 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?
Given the tool's moderate complexity (2 parameters, no annotations, but has output schema), the description is reasonably complete. It covers purpose, parameters, and return format. The output schema existence means return values don't need explanation, though more behavioral context would help given the lack of annotations.
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 0% schema description coverage, the description compensates well by explaining both parameters: 'profile_id' as a LinkedIn public ID with an example, and 'limit' with its default value and purpose. This adds significant meaning beyond the bare 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 purpose with a specific verb ('Get'), resource ('articles'), and source ('by a LinkedIn profile'). It distinguishes from siblings like 'get_article' (singular) and 'get_profile_posts' (different content type) by specifying long-form articles from profiles.
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 by mentioning the Professional Network Data API and specifying profile articles, but doesn't explicitly state when to use this tool versus alternatives like 'get_profile_posts' or 'get_article'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about API methods (Official vs. unofficial), TOS compliance, and required product enablement ('Share on LinkedIn'), which goes beyond basic functionality. However, it doesn't mention potential side effects (e.g., public visibility implications), error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, args, returns) and front-loaded key information. Every sentence adds value, though the API method details could be slightly condensed. No wasted words, but not perfectly minimal.
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 (API integration, visibility settings), no annotations, and an output schema (implied by 'Returns'), the description is reasonably complete. It covers purpose, parameters, return values, and API context. However, it lacks details on authentication requirements or error handling, leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively explains both parameters: 'text' (post content with 3000-character max) and 'visibility' (PUBLIC or CONNECTIONS with default). This adds crucial semantic meaning not present in the bare schema, though it doesn't detail format constraints beyond character limits.
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 ('Create a new LinkedIn post') and distinguishes it from sibling tools like create_image_post, create_video_post, and create_draft by specifying it's for creating a standard text post. It also mentions the resource (LinkedIn) and method (Official API or unofficial API).
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 about when to use this tool (for creating LinkedIn posts) and mentions the recommended API method (Official LinkedIn API with w_member_social scope). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (e.g., create_image_post for image-based posts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a destructive operation ('Delete'), mentions an API requirement, and states the return value ('Returns success status'), but doesn't specify permissions needed, rate limits, or what 'success status' entails. It adds some context but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, prerequisite, and parameter/return details. It's front-loaded with the core action and uses clear formatting for the Args section. One minor improvement could be integrating the prerequisite more seamlessly, but overall it's efficient with minimal 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?
Given this is a destructive mutation tool with no annotations, 1 parameter (0% schema coverage), and an output schema exists (implied by 'Returns success status'), the description does well: it explains the action, prerequisite, parameter, and return. However, for a destructive operation, it could better address safety considerations or error cases to be 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 schema description coverage is 0%, so the description must compensate. It provides the parameter name ('post_urn'), explains its purpose ('The URN of the post to delete'), and gives an example format ('e.g., "urn:li:share:123456"'), adding significant meaning beyond the bare schema. However, it doesn't explain where to find this URN or validation rules.
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 ('Delete a LinkedIn post') and resource ('using the Official API'), distinguishing it from sibling tools like delete_comment, delete_draft, and delete_reaction which target different resources. It provides a complete verb+resource+scope statement.
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 states when to use this tool ('Delete a LinkedIn post') and includes a prerequisite ('Requires "Share on LinkedIn" product enabled in your LinkedIn Developer app'), providing clear context. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings like delete_comment or delete_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Returns success status' and includes a 'WARNING: Uses unofficial API', which adds important context about reliability and potential risks. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter details and warnings. It uses bullet-like formatting for clarity but includes a redundant 'Args:' header that could be omitted for brevity without losing 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?
Given the tool's complexity (mutation with 3 parameters), no annotations, and an output schema present (implied by 'Returns success status'), the description is fairly complete. It covers purpose, parameters, and behavioral warnings, though it could benefit from more detail on error cases or side effects to achieve full 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?
Schema description coverage is 0%, so the description must compensate. It explains each parameter's purpose and source ('from get_invitations results') and specifies valid values for 'action' ('accept' or 'reject'), adding significant meaning beyond the bare schema. The default value for 'action' is noted in the schema but not in the description, slightly reducing the 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's purpose with specific verbs ('accept or reject') and resource ('a connection invitation'), distinguishing it from sibling tools like 'send_connection_request' or 'get_invitations'. It precisely defines the action without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by referencing 'get_invitations results' for parameter values, indicating when to use this tool (after retrieving invitations). However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'send_connection_request' for initiating connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the product requirement and parameter constraints, but doesn't address important behavioral aspects like rate limits, authentication needs beyond the product requirement, pagination behavior, or whether this is a read-only operation. The description provides some context but leaves significant behavioral questions unanswered.
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 well-structured with clear sections: purpose statement, context about the Ad Library, requirements, parameters, and return values. It's appropriately sized for a 4-parameter tool with no annotations. The only minor inefficiency is the slightly redundant 'Args:' and 'Returns:' headers when the content already flows logically.
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 (4 parameters, no annotations, but with output schema), the description provides good coverage. It explains the purpose, requirements, all parameters, and what the tool returns. The presence of an output schema means the description doesn't need to detail the return structure. The main gap is the lack of behavioral context that annotations would normally provide.
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 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. It successfully explains all four parameters: keyword ('Search term to find in ad content'), advertiser ('Company/advertiser name to search for'), country ('ISO 3166-1 alpha-2 country code'), and count ('Number of results to return' with default and max values). This provides meaningful semantic context beyond what the bare 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 clearly states the tool's purpose with a specific verb ('Search for ads') and resource ('in the LinkedIn Ad Library'), distinguishing it from sibling tools like search_ads_by_advertiser and search_ads_by_keyword. It explicitly mentions the Ad Library's transparency function, providing additional context about what the tool accesses.
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 by stating that at least one of keyword or advertiser must be provided, and mentions the requirement for 'LinkedIn Ad Library' product to be enabled. However, it doesn't explicitly differentiate when to use this tool versus the more specific sibling tools search_ads_by_advertiser and search_ads_by_keyword.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the API source ('Official API') and prerequisites, but lacks details on behavioral traits such as rate limits, authentication needs beyond the product requirement, error handling, or whether the operation is idempotent. It mentions the return format, which is helpful but not comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, prerequisites, args, returns) and uses bullet points for readability. It is appropriately sized, but could be slightly more concise by integrating the prerequisite into the main flow. Every sentence adds value, with 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?
Given the complexity of a mutation tool with no annotations, 4 parameters, and an output schema (which covers return values), the description is mostly complete. It explains prerequisites, parameters in detail, and hints at returns. However, it lacks full behavioral context (e.g., side effects, error cases), leaving a minor gap in completeness.
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 schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all parameters: text (max length, content type), image_path (multiple source options with examples), alt_text (purpose and recommendation), and visibility (options and default). This adds significant value beyond the bare schema, effectively documenting 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 clearly states the specific action ('Create a LinkedIn post with an image') and resource ('using the Official API'), distinguishing it from sibling tools like create_post, create_document_post, and create_video_post by specifying the image media type. It goes beyond just restating the name by detailing the platform and method.
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 prerequisites ('Requires "Share on LinkedIn" product enabled in your LinkedIn Developer app'), which gives clear context for when this tool can be used. However, it does not explicitly state when to use this versus alternatives like create_post or create_video_post, nor does it provide exclusions or comparative guidance with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses the Official API and requires a specific product enabled, adding useful context. It also clarifies that it 'removes your reaction,' indicating ownership and scope. However, it lacks details on permissions, rate limits, error handling, or what 'success status' entails, leaving gaps in behavioral understanding for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by prerequisites, parameter details, return info, and a clarifying note. Each sentence adds value without redundancy, such as the note reinforcing the action's scope. It efficiently covers key points in a compact format, making it 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?
Given the tool's complexity (a mutation with no annotations but an output schema), the description is mostly complete. It covers purpose, prerequisites, parameter meaning, and return indication ('Returns success status'), with the output schema likely handling return details. However, it could improve by addressing error cases or side effects, slightly reducing completeness for a deletion operation.
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 0% description coverage, but the description compensates by explaining the 'target_urn' parameter: it specifies the URN of the post or comment, provides examples (e.g., 'urn:li:share:123456'), and clarifies its purpose ('to remove reaction from'). This adds meaningful semantics beyond the bare schema, though it could detail format constraints or validation rules more explicitly.
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 ('Remove a reaction') and target resource ('from a LinkedIn post or comment'), using the Official API. It distinguishes itself from sibling tools like 'create_reaction' by specifying the opposite operation, and from other deletion tools (e.g., 'delete_post', 'delete_comment') by focusing on reactions rather than content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when needing to remove a reaction from LinkedIn content. It explicitly mentions the prerequisite ('Requires "Community Management API" product enabled'), which is helpful guidance. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as distinguishing from 'delete_post' or 'delete_comment' for content removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (generates a data-driven posting schedule) and mentions it returns a content calendar with suggested dates, times, and content prompts. However, it doesn't disclose important behavioral aspects like whether this is a read-only analysis tool or if it creates/schedules actual posts, what data sources it uses, or any rate limits/authentication requirements.
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 well-structured and appropriately sized. It starts with a clear purpose statement, provides specific details about what the tool does, then lists parameters with their semantics, and finally describes the return value. Every sentence earns its place with 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?
Given the tool has an output schema (so return values are documented elsewhere), no annotations, and 2 parameters with 0% schema coverage, the description does a good job of explaining the tool's purpose, parameters, and what it returns. However, for a tool that generates recommendations based on performance data, it could better explain the data sources used or how the optimization algorithm works.
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 0% schema description coverage and 2 parameters, the description adds significant value by explaining both parameters in the Args section: 'weeks: Number of weeks to plan (default: 4, max: 12)' and 'posts_per_week: Target posts per week (default: 3, max: 7)'. This provides clear semantics beyond the bare schema, though it doesn't explain what happens if values exceed the maximums or how the defaults affect the output.
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 ('generate', 'creates') and resource ('content calendar'), and distinguishes it from siblings by specifying it's based on performance data and optimizes for best performing days/times/content types. This differentiates it from other content-related tools like analyze_content_performance or create_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('based on your performance data', 'optimizes for your best performing days, times, and content types'), but doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools. The context is sufficient but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the API scope used (r_member_postAnalytics) and mentions that it fetches recent posts automatically if no URNs are provided. However, it doesn't address important behavioral aspects like rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'get' implies read-only).
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 well-structured with clear sections: purpose statement, API scope information, parameter explanations, and return value description. It's appropriately sized at 5 sentences, though the API scope detail could be considered slightly technical for some users. 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 an output schema (so return values don't need explanation in description), 2 parameters with good semantic coverage in the description, and no annotations, the description is reasonably complete. It covers purpose, usage context, parameters, and the type of analytics returned. The main gap is lack of behavioral details like authentication requirements or rate limits.
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 description provides excellent parameter semantics beyond the schema. The schema has 0% description coverage, but the description clearly explains both parameters: 'post_urns' as 'List of specific post URNs to analyze' with the behavior when not provided, and 'limit' as 'If no URNs provided, analyze this many recent posts (default: 10)'. This fully compensates for the schema's lack of 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: 'Get analytics for your own posts' with specific metrics listed (impression counts, engagement metrics, reach data). It distinguishes itself from sibling 'get_post_analytics' by specifying 'your own posts' and mentions the specific API scope used (r_member_postAnalytics).
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 about when to use this tool: for analyzing your own posts with the Official API. It distinguishes from the sibling 'get_post_analytics' by specifying 'your own posts' rather than general post analytics. However, it doesn't explicitly state when NOT to use it or mention all possible alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it 'retrieves' posts (implying read-only), mentions the data provider context, and specifies a maximum count constraint. However, it doesn't address permissions, rate limits, pagination, or error behaviors that would be important for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, implementation context, usage guidance, parameter explanation, and return value description in just four sentences. Every sentence adds value with zero 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?
Given the tool has an output schema (so return values don't need description), one simple parameter, and no annotations, the description provides good coverage of purpose, usage context, parameter meaning, and constraints. It could be more complete by addressing authentication or error handling, but it's reasonably comprehensive for this complexity level.
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 description adds meaningful context for the single parameter 'count' by explaining it's the 'Number of posts to retrieve' and specifying 'max 100'. With 0% schema description coverage and only one parameter, this provides good semantic clarification beyond the basic integer type 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 clearly states the specific action ('Get your own LinkedIn posts'), the resource ('your authored posts'), and distinguishes it from siblings by specifying it's for your own posts only (unlike get_profile_posts which could be for others). It uses a precise verb and resource combination.
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 about when to use this tool ('Get your own LinkedIn posts') and mentions a specific follow-up use case ('Returns post URNs that can be used with get_my_post_analytics'). However, it doesn't explicitly state when NOT to use it or name alternative tools for similar purposes.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it returns a list of matching job postings, mentions the use of an unofficial API, and includes a critical warning about bot detection with heavy use. However, it lacks details on error handling, pagination, or authentication requirements.
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 well-structured with a clear opening sentence, organized parameter explanations in bullet-like format, and a warning section. It is appropriately sized for an 8-parameter tool, though the parameter list is lengthy. Every sentence adds value, but some redundancy exists (e.g., 'Returns list of matching job postings' could be integrated more tightly).
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 (8 parameters, no annotations, but has an output schema), the description is largely complete. It covers purpose, parameters, returns, and critical warnings. The output schema existence means return values need not be detailed in the description. However, it lacks information on error cases or rate limiting specifics beyond the bot detection warning.
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 schema description coverage is 0%, so the description must fully compensate. It provides detailed semantic explanations for all 8 parameters, including examples (e.g., 'Python Developer'), enumerated value mappings (e.g., job_type: 'F=Full-time'), defaults (e.g., listed_at: 86400), and constraints (e.g., limit max: 50). This adds significant value beyond the bare 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 specific action ('Search for job postings') and the resource ('on LinkedIn'), distinguishing it from sibling tools like 'search_people' or 'search_companies' which search different LinkedIn entities. The verb 'search' is precise and the platform context is explicit.
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 through the parameter explanations (e.g., filtering by job type, location), but does not explicitly state when to use this tool versus alternatives like 'get_job' (which appears to fetch a specific job) or other search tools. No explicit when-not-to-use guidance or prerequisites are 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?
No annotations are provided, so the description carries the full burden. It discloses that browser automation is required, which is a key behavioral trait. However, it lacks details on permissions needed, whether the upload overwrites existing photos, rate limits, or error handling. The description adds some value but is incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by prerequisites and parameter details in a structured format. Every sentence adds value: the first states the action, the second specifies requirements, and the third explains the parameter and return. There is no wasted text.
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 that this is a mutation tool with no annotations, 1 parameter, and an output schema (implied by 'Returns success status'), the description is fairly complete. It covers the purpose, prerequisites, parameter semantics, and return indication. However, it could improve by detailing behavioral aspects like overwrite behavior or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'photo_path' is an 'Absolute path to the photo file (JPG, PNG)', clarifying the parameter's purpose, format, and allowed file types. This goes beyond the schema's basic type definition. However, it does not cover edge cases like file size limits.
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 ('Upload a new profile photo') with the resource ('profile photo'). It distinguishes itself from sibling tools like 'upload_background_photo' by specifying the target resource, and from other profile-related tools (e.g., 'update_profile_headline', 'update_profile_summary') by focusing on photo upload.
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 context for when to use this tool: 'Requires Playwright browser automation to be enabled.' This is a clear prerequisite. However, it does not mention when not to use it or name alternatives (e.g., using 'update_profile_headline' for text updates instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this creates content via the LinkedIn API and mentions a product requirement, but doesn't cover important behavioral aspects like rate limits, authentication needs beyond the product requirement, error conditions, or whether the operation is idempotent. It does state what gets returned ('Returns the created poll post details').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, prerequisite, parameter details in a readable format, and return information. Every sentence earns its place, and the information is front-loaded with the core functionality first.
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 an output schema (true), the description doesn't need to detail return values. It covers the creation purpose, prerequisites, and parameter semantics well. However, as a mutation tool with no annotations, it could benefit from more behavioral context about permissions, side effects, or error handling.
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?
With 0% schema description coverage, the description fully compensates by providing detailed semantics for all 4 parameters: question (purpose, character limit, dual use as post text), options (format, count range, character limits), duration_days (allowed values, default), and visibility (allowed values). This adds substantial value beyond the bare 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 specific action ('Create a LinkedIn poll') and resource ('using the Official API'), distinguishing it from sibling tools like create_post, create_image_post, or create_document_post. It specifies this is for polls specifically, not general posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Create a LinkedIn poll') and includes an important prerequisite ('Requires "Share on LinkedIn" product enabled in your LinkedIn Developer app'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the 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?
No annotations are provided, so the description carries the full burden. It discloses the prerequisite ('LinkedIn Ad Library' product enabled) and return format ('List of ads matching the keyword with full details'), which adds useful context. However, it lacks details on rate limits, authentication needs, or error behaviors, leaving some gaps in behavioral understanding.
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 appropriately sized and front-loaded, starting with the core purpose, followed by prerequisites, parameter details, and return information. Every sentence earns its place without redundancy, and the structure is logical 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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, prerequisites, parameters, and returns, but lacks behavioral details like rate limits or error handling. The output schema likely handles return values, so this is adequate but not exhaustive.
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?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: 'keyword' as the search term, 'country' as an optional ISO code filter, and 'count' with default and max values. This adds essential meaning beyond the bare schema, making parameters clear and actionable.
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 ('Search for') and resource ('ads'), and distinguishes it from sibling tools like 'search_ads' and 'search_ads_by_advertiser' by specifying it searches by keyword in ad content. This makes the purpose immediately understandable 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by stating it requires 'LinkedIn Ad Library' product enabled, which is a prerequisite. However, it does not explicitly mention when not to use it or name alternatives (e.g., 'search_ads' or 'search_ads_by_advertiser'), though the purpose implies keyword-based filtering.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes important behavioral traits: the search priority system (Fresh Data API vs linkedin-api), cost implications ('requires Pro plan $45/mo'), and technical limitations ('may be blocked by LinkedIn bot detection'). It also specifies what the tool returns ('list of matching profiles with name, title, location, and profile URL').
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 well-structured with clear sections (Args, Note, Returns, Search priority) and front-loads the core purpose. It's appropriately sized for a tool with 4 parameters and complex behavioral context. Some sentences could be more concise, but overall it's efficient and organized.
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 complexity (search with multiple filters, dual API backend, cost implications) and 0% schema description coverage, the description is remarkably complete. It covers purpose, parameters, limitations, return values, and implementation details. With an output schema present, it doesn't need to explain return format in detail, but still provides useful context about what fields are included.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains all 4 parameters: 'keywords' as 'General search keywords', 'limit' with default and max values, 'keyword_title' with examples, and 'keyword_company' as 'Filter by company name'. The description adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for people on LinkedIn.' It specifies the resource (people) and verb (search), but doesn't explicitly differentiate from sibling tools like 'search_companies' or 'search_jobs' beyond the resource type. The description is specific but lacks explicit sibling comparison.
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 about when to use this tool: for searching people on LinkedIn. It explicitly states limitations ('Location/region filters are not supported') which helps guide usage. However, it doesn't mention alternatives or when not to use it relative to sibling tools like 'get_profile' or 'batch_get_profiles'.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behavioral traits: the tool uses an unofficial API (implying potential instability), may trigger bot detection, and could result in account restrictions if overused. It also mentions the return value ('success status and message details'), though it doesn't detail error conditions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, parameter explanations, return value note, and a separate WARNING section. Every sentence adds value, but the warning could be slightly more concise (e.g., combining the last two sentences). It's appropriately sized for a tool with significant behavioral implications.
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 (mutating action with high-risk behavior), no annotations, 0% schema coverage, but an output schema present, the description does a good job covering purpose, parameters, returns, and critical warnings. It adequately informs the agent about risks and usage, though it could benefit from more specifics on error handling or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'recipients' as 'List of LinkedIn profile public IDs' with examples, and 'text' as 'Message content to send.' This adds essential semantic meaning beyond the bare schema types, though it doesn't specify format constraints like message length limits.
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 ('Send a LinkedIn message') and target resource ('to one or more recipients'), distinguishing it from sibling tools like 'send_connection_request' or 'create_comment' that involve different LinkedIn interactions. It provides a complete verb+resource+scope statement without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a WARNING section that provides clear context about when to use this tool cautiously (due to unofficial API risks and potential account restrictions), but it doesn't explicitly compare it to alternative messaging methods or specify exact thresholds for 'too many messages.' It offers responsible usage guidance without naming specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about using an 'unofficial API' (a WARNING), which informs about potential reliability or compliance issues. However, it doesn't describe authentication needs, rate limits, error conditions, or what specific details are returned beyond 'conversation ID'.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by usage context, parameter explanation, return value, and a warning. Every sentence earns its place with 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?
Given the tool's moderate complexity (single parameter, no annotations, but with an output schema), the description is reasonably complete. It covers purpose, usage, parameter semantics, and a behavioral warning. The presence of an output schema means it doesn't need to detail return values, but it could benefit from more behavioral context (e.g., error handling).
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 description adds meaningful semantics beyond the schema: it explains that 'profile_id' accepts 'LinkedIn profile ID or URN', clarifying the expected format. With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't provide examples or constraints.
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 ('Get conversation ID and details') and resources ('for a specific profile'). It distinguishes itself from sibling tools like 'get_conversation' and 'get_conversations' by focusing on retrieving details for a specific profile rather than general conversation data.
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 this tool ('Useful for finding the conversation ID to send a message to someone'), providing clear context for its application. It also implies an alternative workflow where this tool is a prerequisite for 'send_message', though it doesn't explicitly name alternatives.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key behavioral traits: it's a read operation (implied by 'Get'), requires specific permissions ('admin permissions for the organization'), has access requirements ('Community Management API access'), and provides accurate data ('accurate follower counts'). It doesn't mention rate limits or error handling, but covers the essential operational 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 efficiently structured with clear sections: purpose statement, API context, parameter explanation, return information, and access requirements. Every sentence earns its place, and the information is front-loaded with the core functionality stated first.
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 (single parameter read operation), no annotations, but with an output schema present, the description provides good context. It covers purpose, parameter details, access requirements, and return information. The output schema handles return value documentation, so the description appropriately focuses on operational context rather than output structure.
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 0% schema description coverage and only one parameter, the description adds significant value beyond the schema. It explains that 'organization_id' is a 'LinkedIn organization URN ID' with format details ('numeric, e.g., '12345678''), which the schema alone doesn't provide. This compensates well for the schema's lack of 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 purpose with specific verb ('Get'), resource ('follower count for an organization'), and method ('using the Community Management API'). It distinguishes itself from sibling tools by focusing on organization follower metrics rather than content analysis, profile operations, or posting functions.
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 about when to use this tool: for organizations where the user has admin access and Community Management API access. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for similar data retrieval.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a write operation (implied by 'Send'), mentions success status returns, warns about unofficial API usage and bot detection risks, and notes LinkedIn's rate limits. This covers critical aspects like mutation, authentication needs (implied by API), and usage constraints, though it could add more on error handling or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args' section for parameters, return info, and a WARNING block for critical context. Every sentence adds value without redundancy, 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.
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 (a write operation with API risks), no annotations, 0% schema coverage, but an output schema present, the description is largely complete. It covers purpose, parameters, returns, and warnings, but could improve by mentioning prerequisites (e.g., authentication status) or linking to sibling tools like 'get_invitations' for managing requests. The output schema handles return values, so that gap is mitigated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'profile_id' is explained as 'LinkedIn profile public ID' with an example ('john-doe'), and 'message' is clarified as optional with a character limit (~300) and purpose ('personalized message'). This goes beyond the schema's basic types, though it doesn't detail format constraints (e.g., URL-safe IDs) or validation rules.
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 ('Send a connection request') and target resource ('to a LinkedIn profile'), with specific verb+resource pairing. It distinguishes this from sibling tools like 'send_message' (for messaging existing connections) or 'reply_invitation' (for responding to incoming requests), 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 this tool (sending connection requests) and includes a WARNING about LinkedIn's bot detection and rate limits, which implicitly guides responsible usage. However, it does not explicitly state when NOT to use it or name specific alternatives among siblings (e.g., 'send_message' for existing connections), keeping it from a perfect score.
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 no annotations provided, the description carries full burden and does well by disclosing: the API requirement, what gets created (reaction details returned), and behavioral notes about deprecated reaction types. It doesn't mention rate limits, authentication specifics, or error conditions, but provides substantial operational context.
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?
Well-structured with purpose statement, prerequisite, parameter documentation, return information, and important note. Every sentence earns its place, though the reaction options list is somewhat lengthy but necessary. Could be slightly more front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, mutation operation), no annotations, but with output schema present, the description is remarkably complete. It covers purpose, prerequisites, parameter details, return information, and important behavioral notes about deprecated functionality - providing everything needed for effective use.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics: explains what target_urn represents with concrete examples, documents all reaction_type options with their display equivalents, and specifies the default value. This adds significant value beyond the bare 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 specific action ('Add a reaction') and target resource ('to a LinkedIn post or comment') using the verb+resource pattern. It distinguishes this tool from sibling tools like 'create_comment' or 'delete_reaction' by focusing specifically on reaction creation.
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 about when to use this tool (for adding reactions to LinkedIn content) and includes an important prerequisite ('Requires "Community Management API" product enabled'). However, it doesn't explicitly contrast when to use this versus alternatives like 'delete_reaction' or other engagement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses important behavioral traits: it requires specific LinkedIn Developer app configuration, uses LinkedIn's PARTIAL_UPDATE method (which updates only specified fields), and has a constraint that at least one of 'text' or 'image_path' must be provided. It also mentions the 3000-character limit for text. However, it doesn't cover rate limits, authentication requirements beyond the product enablement, or error handling.
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 well-structured and appropriately sized. It starts with the core purpose, then lists prerequisites, parameters with clear formatting, return information, and important notes. Every sentence adds value without redundancy, and information is front-loaded with the main purpose stated first.
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 (mutation operation with 4 parameters), no annotations, and 0% schema coverage, the description does an excellent job covering most essential aspects. It explains the purpose, parameters, constraints, and method used. However, it could benefit from mentioning authentication requirements beyond product enablement and potential side effects. The presence of an output schema means return values don't need explanation, which helps completeness.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter information. It explains each parameter's purpose: 'post_urn' identifies the post to edit, 'text' is new content with character limit, 'image_path' replaces existing media, and 'alt_text' is for the new image. It also clarifies that 'text' and 'image_path' are optional but at least one must be provided, and 'post_urn' is required.
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 verb ('Edit/update') and resource ('an existing LinkedIn post'), distinguishing it from sibling tools like 'create_post' (for new posts) and 'update_draft' (for drafts). It explicitly mentions using the Official API, which adds 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?
The description provides clear context for when to use this tool: for editing existing LinkedIn posts. It mentions the prerequisite 'Share on LinkedIn' product must be enabled. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., 'update_draft' for drafts vs. 'edit_post' for published posts).
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 no annotations provided, the description carries full burden and does well by detailing what information is returned (token expiry, cookie freshness, features, recommended actions). It clearly indicates this is a read-only diagnostic tool without side effects, though it doesn't mention rate limits, permissions needed, or error behaviors.
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 efficiently structured with a clear opening sentence stating the purpose, followed by a bulleted list of return details. Every sentence earns its place by adding specific value about what the tool provides, with no redundant or vague language.
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 simple nature (0 parameters, output schema exists), the description is complete enough. It explains the purpose, what status information is returned, and includes actionable output (recommended actions). With an output schema handling return structure, no additional detail about return values is needed.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter information, focusing instead on output semantics. A baseline of 4 is applied since zero parameters require no compensation.
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 ('Get') and resource ('LinkedIn authentication status'), distinguishing it from all sibling tools which perform content analysis, posting, profile management, or data retrieval operations. It explicitly covers both official and unofficial APIs, making its scope 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 usage context by specifying it returns authentication status for both API types, suggesting it should be used to check authentication state before performing other LinkedIn operations. However, it does not explicitly state when not to use it or name alternative tools for similar purposes, though no obvious alternatives exist 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by specifying it returns a list of pending invitations with sender info, mentions the default limit, and includes important warnings about API limitations (LinkedIn API restrictions) and unofficial status. It does not cover rate limits or error handling, but provides substantial 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 well-structured and front-loaded with the core purpose, followed by parameter details, return information, and critical notes. Every sentence adds value, with no wasted words, 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?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, parameters, behavioral notes, and warnings, leaving no significant gaps for an AI agent to understand and invoke the tool 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 has 0% description coverage, but the description compensates by explaining the 'limit' parameter's purpose ('Maximum invitations to return') and default value (50). This adds meaningful semantics beyond the schema's type and default, though it could elaborate on constraints like minimum/maximum 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('pending connection invitations you've received'), distinguishing it from sibling tools that focus on posts, profiles, or analytics. It explicitly notes the scope is limited to received invitations, not sent ones.
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 by specifying it fetches 'pending connection invitations you've received' and noting that 'Sent invitations are not available through this endpoint.' However, it does not explicitly mention when not to use it or name alternative tools for related functions.
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 no annotations provided, the description carries full burden and adds valuable behavioral context. It discloses that this 'Uses unofficial API' (a WARNING about reliability/rate limits) and specifies the return format ('job details including description, requirements, company info, etc.'). This goes beyond basic function to address implementation risks and output 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?
The description is perfectly structured and front-loaded: purpose statement first, then Args section with parameter explanation, then return details, and finally a WARNING. Every sentence earns its place with zero wasted words, making it highly scannable 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?
Given the tool's low complexity (single parameter), no annotations, but with an output schema present, the description is complete. It covers purpose, parameter semantics, return content, and important behavioral warnings. The output schema means return values don't need explanation in the description, making this appropriately comprehensive.
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 0% schema description coverage for the single parameter, the description fully compensates by explaining 'job_id: LinkedIn job ID (from search results or job URL)'. This provides crucial semantic context about the parameter's source and format that the schema's type:string alone doesn't convey.
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 ('Get detailed information') and resource ('about a specific job posting'), distinguishing it from sibling tools like search_jobs (which finds jobs) or get_job_skills (which focuses on skills). It precisely defines the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you have a specific job ID from search results or a URL. However, it doesn't explicitly mention when NOT to use it or name alternatives like search_jobs for finding jobs without an ID, leaving some room for improvement in sibling differentiation.
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 no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses the data returned (basic info, LinkedIn member ID), mentions API reliability (Official LinkedIn API with OAuth 2.0), and fallback behavior (unofficial API if official client not configured). It does not cover aspects like rate limits or error handling, but provides substantial transparency beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list of return data and API details. Every sentence adds value without waste, making it efficient and well-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?
Given the tool's low complexity (0 parameters), lack of annotations, and presence of an output schema (which handles return value details), the description is complete. It covers purpose, output examples, and API behavior, leaving no significant gaps for an agent to understand and invoke the tool 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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing on output and behavior instead. A baseline of 4 is applied as it effectively handles the zero-parameter case without redundancy.
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 verb ('Get') and resource ('the authenticated user's LinkedIn profile'), distinguishing it from sibling tools like 'get_profile' (which likely retrieves other users' profiles) and 'batch_get_profiles' (which handles multiple profiles). It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it retrieves 'the authenticated user's' profile, suggesting it should be used for self-profile access rather than others. However, it does not explicitly state when not to use it (e.g., vs. 'get_profile' for other users) or name alternatives, keeping it from a perfect score.
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 no annotations provided, the description carries the full burden and does well by disclosing behavioral traits: it explains the use of caching ('use_cache'), parallel data aggregation, and enrichment metadata. It could improve by mentioning rate limits or authentication needs, but it covers key operational aspects effectively.
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 well-structured with a purpose statement, implementation details, parameter explanations, and return value summary. It's appropriately sized but could be slightly more concise by integrating the 'Args' and 'Returns' sections more fluidly; however, every sentence adds 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?
Given the tool's complexity (5 parameters, no annotations, but with an output schema), the description is complete: it covers purpose, usage context, parameters, and return values in detail. The output schema exists, so the description needn't explain return values extensively, but it still provides a helpful summary, making it fully adequate.
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?
Given 0% schema description coverage, the description fully compensates by detailing all 5 parameters with clear semantics: it explains 'profile_id' as LinkedIn ID or URN, and each boolean parameter's purpose and default values, adding significant meaning beyond the bare 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 purpose with specific verbs ('get comprehensive LinkedIn profile data') and resources ('LinkedIn profile'), distinguishing it from sibling tools like 'get_my_profile' or 'get_profile_contact_info' by emphasizing multi-source enrichment and aggregation from multiple endpoints.
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 mentioning 'multi-source enrichment' and 'Profile Enrichment Engine,' suggesting it's for comprehensive data retrieval. However, it lacks explicit guidance on when to use this tool versus alternatives like 'batch_get_profiles' or more specific sibling tools, such as 'get_profile_contact_info' for limited data.
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 no annotations provided, the description carries the full burden of behavioral disclosure and does this well. It describes the visual presentation ('Documents appear as carousel-style slideshows in the LinkedIn feed'), technical requirements ('Supported formats: PDF (recommended), PPTX, DOCX'), and constraints ('Maximum file size: 100MB'). It also mentions the return value format. The only gap is lack of information about rate limits, error conditions, or authentication requirements beyond the product enablement note.
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 well-structured and efficiently organized. It starts with the core purpose, then provides context about presentation and use cases, followed by requirements, technical specifications, parameter details, and return information. Every sentence adds value with no redundancy or 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 4-parameter mutation tool with no annotations but with an output schema, the description is remarkably complete. It covers the tool's purpose, visual behavior, use cases, prerequisites, technical constraints, detailed parameter semantics, and return value information. The output schema existence means the description doesn't need to detail return structure, allowing it to focus on other important contextual information.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter information. It explains each parameter's purpose, constraints, and options: text (max 3000 characters), document_path (accepts local paths or URLs), title (optional, defaults to filename), and visibility (PUBLIC or CONNECTIONS with default). This adds significant value beyond the bare 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 specific action ('Create a LinkedIn post with a document') and distinguishes it from sibling tools like create_post, create_image_post, and create_video_post by specifying it's for document-based posts that appear as carousel-style slideshows. It explicitly mentions the resource (LinkedIn post) and the unique document 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 context about when to use this tool ('Great for sharing presentations, guides, reports, etc.') and mentions the prerequisite ('Requires "Share on LinkedIn" product enabled in your LinkedIn Developer app'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (like create_post for text-only posts or create_image_post for image posts).
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 no annotations provided, the description carries full burden and does well by disclosing important behavioral traits: the requirement for specific product enablement, video processing time ('may take a few minutes'), and the return format ('post details including post URN and video URN'). It doesn't mention rate limits or authentication details, but covers most critical operational 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?
The description is efficiently structured with clear sections: purpose, prerequisites, technical specifications, parameters, and returns. Every sentence adds value with no redundancy. The bullet-point formatting for video specs and parameter explanations enhances readability without wasting space.
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 complexity (video upload with specific requirements), no annotations, and the presence of an output schema, the description provides comprehensive context. It covers prerequisites, technical constraints, parameter semantics, return values, and processing behavior, making it complete enough for effective use despite the structured data gaps.
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?
With 0% schema description coverage, the description compensates fully by explaining all 4 parameters: text (max 3000 characters), video_path (local file or URL options with format details), title (optional), and visibility (PUBLIC or CONNECTIONS with default). It provides meaningful context beyond basic schema types, including constraints and options.
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 ('Create a LinkedIn post with a video') and distinguishes it from sibling tools like create_image_post, create_document_post, and create_post by specifying it's for video content. It uses precise language that identifies both the verb and resource.
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 about when to use this tool by specifying it requires the 'Share on LinkedIn' product enabled and listing technical requirements (video duration, formats, size). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools for non-video posts.
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 no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a destructive operation (implied by 'Delete'), requires specific API product access, has authorization constraints (only own comments), and indicates the return value ('Returns success status'). It doesn't mention rate limits or error conditions, but covers the essential safety and permission 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?
The description is efficiently structured with clear sections: purpose statement, prerequisites, parameter explanations, return value, and authorization note. Every sentence earns its place, and the most critical information (what the tool does) is front-loaded. No wasted words 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?
For a destructive operation with 2 parameters, 0% schema coverage, no annotations, but with an output schema, the description provides excellent completeness. It covers purpose, prerequisites, parameter meanings, return indication, and authorization constraints. The output schema handles return value details, so the description doesn't need to explain return format.
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 schema has 0% description coverage, so the description must fully compensate. It provides clear semantic explanations for both parameters: 'post_urn' is described as 'The URN of the post containing the comment' with format examples, and 'comment_id' as 'The ID or URN of the comment to delete'. This adds significant value beyond the bare 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 specific action ('Delete a comment'), the target resource ('from a LinkedIn post'), and the method ('using the Official API'). It distinguishes itself from sibling tools like 'delete_post' and 'delete_reaction' by focusing specifically on comments, not posts or reactions.
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 prerequisites ('Requires "Community Management API" product enabled') and authorization constraints ('You can only delete comments that you have authored'), which gives clear context for when to use this tool. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings (like 'delete_post' for posts instead of comments).
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 no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it requires a specific API product enabled, explains pagination defaults and limits (start: 0, count: max 100), and details the return structure. It also mentions using the returned URN for replies, adding practical context. However, it doesn't cover error conditions 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 well-structured and front-loaded with the core purpose, followed by prerequisites, args, returns, and usage note. Every sentence earns its place by providing essential information without fluff, 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?
Given the complexity (API-specific tool with prerequisites), 0% schema coverage, and no annotations, the description is highly complete. It covers purpose, prerequisites, all parameters with semantics, return values in detail, and a practical usage tip. With an output schema present, it appropriately explains return values to aid understanding, leaving no significant gaps.
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?
Schema description coverage is 0%, so the description must compensate fully, which it does excellently. It explains all three parameters: 'post_urn' with examples of URN formats, 'start' as pagination index with default, and 'count' with default and max value. This adds crucial meaning beyond the bare schema, making parameters fully understandable.
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 ('Get comments') and resource ('on a LinkedIn post') using the Official API. It distinguishes itself from sibling tools like 'get_post_comments' by specifying the API source and having a different name, though the sibling list shows both exist, indicating potential redundancy that the description doesn't address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for LinkedIn posts via the Official API with the 'Community Management API' product enabled. It explicitly links to 'create_comment' for replying, offering a clear next-step alternative. However, it doesn't explain when to use this versus the sibling 'get_post_comments' tool, which is a notable gap.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes authentication requirements, API product dependencies, permission constraints, and specific behavioral rules about image attachments in nested vs. top-level comments. It also mentions the return value format. The only gap is lack of rate limit or quota information.
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 well-structured with clear sections (purpose, requirements, args, returns, notes) and every sentence adds value. It could be slightly more concise by combining some of the LinkedIn API product notes, but overall it's efficiently organized with no wasted text.
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 complexity of LinkedIn API integration, 4 parameters with 0% schema coverage, no annotations, but with output schema present, the description provides comprehensive context. It covers prerequisites, constraints, parameter details, return values, and important behavioral notes about the LinkedIn platform's limitations. The output schema handles return value details, allowing the description to focus on operational context.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains each parameter's purpose, format examples for post_urn, character limits for text, optional nature of parent_comment_urn, and comprehensive options for image_path including local files, URLs, and base64 encoding. This adds significant value beyond the bare 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 purpose with specific verb ('Create a comment') and resource ('on a LinkedIn post using the Official API'). It distinguishes from sibling tools like 'create_post' by focusing specifically on commenting rather than post creation, and from 'create_reaction' by specifying comment creation rather than reactions.
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 guidance on when to use this tool, including prerequisites ('Requires "Share on LinkedIn" product enabled'), alternative products needed ('Community Management API'), and specific constraints ('LinkedIn only allows images in nested comments... not in top-level comments'). It also mentions permission errors and when to seek alternative access.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure and excels at this. It explicitly states the action is 'IRREVERSIBLE' with concrete consequences (person must re-request connection), discloses that it 'Uses unofficial API' (important for reliability expectations), and mentions what happens on success ('Returns success status'). This provides comprehensive behavioral context beyond what any structured fields would convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and economical: a clear purpose statement, parameter documentation, return value mention, and critical warnings—all in four focused sentences. Every element serves a distinct purpose with zero redundancy. The warning section is appropriately emphasized with capitalization and formatting.
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 destructive, single-parameter tool with no annotations but with an output schema, the description provides exactly what's needed: clear purpose, parameter meaning, behavioral warnings about irreversibility and API nature, and mention of return value. The output schema will handle return structure details, so the description appropriately focuses on the critical context without over-explaining.
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 0% schema description coverage for the single parameter, the description fully compensates by explaining that 'profile_id' represents the 'LinkedIn profile public ID of the connection to remove.' This adds crucial semantic meaning not present in the bare schema. The description doesn't provide format examples or validation rules, which prevents a perfect score, but it successfully clarifies what the parameter represents.
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 ('Remove') and resource ('existing LinkedIn connection'), distinguishing it from all sibling tools which focus on analytics, content creation, or profile updates rather than connection management. It provides a complete verb+resource statement that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to remove a LinkedIn connection) and includes a strong warning about irreversibility, which serves as implicit guidance about when not to use it casually. However, it doesn't explicitly mention alternatives or compare with other connection-related tools (like 'send_connection_request'), which prevents a perfect score.
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 MCP server](https://glama.ai/mcp/servers/southleft/linkedin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/southleft/linkedin-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/southleft/linkedin-mcp'

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