Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden of disclosing side effects. It mentions saving cookies but does not explain the consequences of closing the session (e.g., whether it terminates active operations, requires authentication, or is irreversible). This is a significant gap for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly states the action and its side effect. Every word is purposeful and it is perfectly front-loaded with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with complete schema coverage, the description sufficiently conveys the core action. However, it lacks a note about when to use this over the similar save_session_cookies tool, which slightly reduces completeness in the broader toolset.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully covers the only parameter (profile_id) with a clear description. The tool description adds no additional meaning, so the baseline score of 3 applies due to high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'close' and identifies the resource 'browser session' plus the side effect 'save cookies'. This clearly differentiates it from sibling tools like save_session_cookies, which only save without closing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 does not mention scenarios for closing a session or exclude related tools such as save_session_cookies, leaving the agent without decision-making context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only states the action without revealing side effects, authentication requirements, or potential failure modes, which is insufficient for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that directly conveys the core purpose without any wasted words. It is appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite full schema coverage, the description omits critical context such as required authentication, behavior on invalid URLs, and return values. The tool is a mutation operation, so more context is needed to be truly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no parameter-specific detail, but the schema already provides adequate semantics for each field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action and resource: 'Comment on a LinkedIn post.' It distinguishes from sibling tools like like_post and create_post, but doesn't explicitly mention differences like like_and_comment_post or reply behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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, nor does it mention prerequisites like being logged in or having cookies set. Usage context is only implied by the function name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 admin access requirement, but this is also stated in the schema for 'profile_id'. It does not disclose whether the post is published immediately, if there are limits on content length, or what the response contains. The description adds marginal value beyond the schema but not rich 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with clear front-loading of the action ('Create a post'), followed by the target ('company page') and a needed prerequisite. There is no filler or redundant information, making it concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's relative simplicity (4 params, 3 required) and full schema coverage, the one-sentence description is mostly adequate. It states the tool's purpose and a key condition. However, it lacks explicit comparison to 'create_post' and provides no information about return values or failure modes, so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage, with each parameter described, including 'profile_id (must have admin access)'. The tool description adds no additional parameter semantics—it merely restates the admin requirement already present in the schema. This matches the baseline of 3 when schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Create a post on behalf of a company page'. This is a specific verb+resource combination that distinguishes it from the sibling tool 'create_post', which likely handles personal posts. The mention of admin access further clarifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear context for use by indicating 'requires admin access', which is an important precondition. It does not explicitly name an alternative tool, but the distinction from 'create_post' is implicit in the phrase 'on behalf of a company page'. No explicit exclusionary guidance is given, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only says 'create a personal post' and does not disclose required authentication, potential side effects, default visibility, or failure conditions. This is minimal 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately conveys the tool's purpose. There is no fluff or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and the schema provides full parameter coverage, but the description lacks important context such as authentication requirements and side effects. Since there are sibling tools like 'login' and 'set_cookies', mentioning that an active session is needed would improve completeness. Overall, it is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema carries the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Create a personal post on LinkedIn.' The word 'personal' distinguishes it from the sibling tool 'create_company_post', making its purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates this tool is for creating personal posts, which differentiates it from the sibling 'create_company_post'. However, it does not explicitly state when to use this tool versus alternatives or mention prerequisites like being logged in.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states the action without mentioning authentication requirements, read-only nature, potential errors, or rate limits. This is insufficient for a tool that interacts with LinkedIn.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundant text. It is efficient and front-loaded, but it is so brief that it omits helpful details, though that is more a completeness issue than a conciseness issue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description omits essential context: what constitutes 'company details', whether authentication is required, expected response format, and error handling. Since there is no output schema, the description should at least outline the returned data. The lack of this information makes it incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters clearly described in the input schema. The description's 'by URL' adds no additional meaning beyond the schema's description of company_url, and it does not explain the role of profile_id. The schema already handles parameter documentation, resulting in a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' with resource 'LinkedIn company details' and specifies the input method 'by URL', clearly distinguishing it from sibling tools like get_profile and get_post. It unambiguously states what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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, no mention of prerequisites such as an active session or cookies, and no exclusions. It simply restates the function without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavior. The verb 'Get' implies a read-only operation, and the description adds specific context about the return value (whether the current account has liked or commented). It does not discuss authentication or error behavior, but for a simple getter the core traits are clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences long, front-loaded with the core action ('Get a LinkedIn post by URL'), and contains no redundant words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with no output schema, the description conveys the main purpose and a key return detail. It lacks explicit context about session prerequisites or error cases, but the full parameter schema and straightforward operation make it largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for both parameters (post_url and profile_id), so the schema already documents their meaning. The description adds no additional information about parameter formats or usage beyond what the schema provides, hence the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Get') and a specific resource ('a LinkedIn post by URL'), and it also describes what will be returned (post details including like/comment status). This distinguishes it from sibling tools like get_profile (fetches a profile) and read_feed (fetches feed posts).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool vs alternatives such as search_posts or read_feed. It does not mention prerequisites like having a valid session or cookies, nor any circumstances when this tool should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It only says 'Get LinkedIn profile details by URL,' implying a read operation, but does not mention any side effects, session requirements, or external network calls. It adds no context beyond what the tool name already implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant words. It is front-loaded with the core action and resource, making it very efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a moderate-complexity tool with 4 params and no output schema, the description is minimal. It does not clarify what 'details' includes or mention the optional activity fetching behavior (though the schema covers this). It is adequate but leaves the agent to infer expected output and prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is well-documented in the schema. The description adds only 'by URL,' which aligns with the linkedin_url parameter but does not explain max_posts or include_activity. This meets the baseline for high schema coverage without adding significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get LinkedIn profile details by URL' clearly states a specific action (get details) on a specific resource (LinkedIn profile) via a specific input method (URL). This distinguishes it from sibling tools like get_company and get_post by explicitly naming 'profile'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. There is no mention of prerequisites, exclusions, or comparison to sibling tools such as get_company or get_post. The only hint is the resource name, which is implicit, not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get status', which is implied by the name, and does not disclose return format, error behavior, or whether the operation is read-only. This is insufficient for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler or redundant detail. It is appropriately front-loaded and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should clarify what 'status' means (e.g., active, expired, not found) and possibly when it is relevant. The current description is too minimal to fully inform an agent, making it incomplete for the tool's context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter is described as 'Profile identifier' in the schema. The description adds no extra meaning about how profile_id is used, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb (Get) and resource (status of a browser session), which distinguishes it from sibling tools like close_session or get_profile. However, it does not elaborate on what 'status' entails, making it somewhat generic but still unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It adds the useful behavioral trait of a single page load, but does not disclose authentication requirements, side effects, or failure behavior. This is minimal but not empty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and resource, with zero wasted words. It is perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with full schema coverage and no output schema, the description adequately conveys what the tool does and the key single-page-load behavior. It omits prerequisites like login, but the sibling tools for authentication make this context implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all three parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics, leaving all meaning to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Like and comment') and resource ('LinkedIn post'), and the phrase 'in one operation' clearly distinguishes it from sibling tools like like_post and comment_post. It is unambiguous 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use this tool (when both like and comment are needed together) via 'in one operation (single page load)'. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 disclosing behavior. "Like a LinkedIn post" only states the action without mentioning authentication requirements, potential side effects, or any return value. This is a significant transparency gap 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with a single sentence and no unnecessary words. However, it is under-specified, lacking contextual details that would enhance usefulness. It earns points for brevity but loses for not providing enough substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description does not address prerequisites like authentication or existing session requirements. There is no output schema and no annotations, leaving the agent without critical context for invoking the tool correctly. The description is too minimal to be complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both post_url and profile_id having descriptive text in the input schema. The description itself adds no further parameter meaning, but since the schema fully covers the parameters, the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states "Like a LinkedIn post," which clearly identifies the action (like) and the resource (LinkedIn post). It distinguishes itself from sibling tools like comment_post and like_and_comment_post by specifying the exact action being performed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. For example, like_and_comment_post combines liking and commenting, and the description gives no indication of when to choose one over the other. It also fails to mention prerequisites such as being logged in or having an active session.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosure. It reveals the behavioral trait of attempting stored cookies before prompting for credentials, but does not describe session side effects, failure modes, or whether a session is established.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no waste, front-loading the primary action and adding a useful detail about cookie-first behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core login flow and parameter options, and the schema is complete. However, it lacks information about return values or session state, which could be important for an agent to proceed, but given the simple nature of login, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all four parameters. The description adds context by explaining that email/password are optional because stored cookies may suffice, and that 2FA is handled via a TOTP code, enhancing the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool logs into LinkedIn with credentials and optional 2FA, and mentions the cookie-first behavior. This distinguishes it from sibling tools like set_cookies or open_manual_browser, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for authentication and indicates that stored cookies are tried first, giving context for when credentials may not be needed. However, it does not explicitly mention alternatives or exclusions, such as using open_manual_browser for manual login.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 window is persistent and pinned, which goes beyond a bare 'open browser', but it does not mention side effects, permission requirements, or what the return value is. Minimal but some behavioral context is added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the verb and resource. Every word earns its place, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 parameters, no output schema), and the description gives a basic idea, but it leaves ambiguity about behavior after invocation—whether it blocks, whether it returns a handle, or how it integrates with profile actions. For an AI agent, more detail on the lifecycle of the browser window would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both url and profile_id are described). The tool description adds no parameter-specific meaning, but since the schema fully explains each parameter, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Open and pin a persistent browser window for manual profile actions' uses specific verbs (open, pin) and identifies the resource (persistent browser window) plus the scope (manual profile actions). This clearly distinguishes it from sibling tools that handle automated actions like login or read_feed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for manual profile actions' gives implied context that this tool is for human intervention, but it does not explicitly state when to use it over alternatives or provide exclusions. There is no mention of 'use this when' or 'instead of X'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the behavioral disclosure burden. It merely states 'Read LinkedIn feed posts' without indicating side effects, login requirements, pagination behavior, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but under-specified. It lacks any contextual structure or guidance beyond the basic function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a moderate schema (3 params) and no output schema or annotations. The description fails to explain return format, prerequisites (e.g., login required), or how parameters like 'scroll_count' affect results, making it incomplete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes all three parameters with full coverage, so the baseline is 3. The description adds no additional meaning about how the parameters affect the tool's behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's function clearly with a verb ('Read') and resource ('LinkedIn feed posts'). It is distinguishable from siblings like 'search_posts' and 'get_post' by its focus on the general feed, though it does not explicitly note these distinctions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 like 'search_posts' or 'get_post'. The description only states what it does without any context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the purpose and gives no information about side effects, whether messages are marked as read, pagination behavior, or authentication requirements. This is a significant gap for a tool that reads user data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasteful content. It is concise and to the point, although its brevity means it lacks supporting details. It earns a high score for conciseness but not perfect because it is under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and an output schema, the description is incomplete. It does not explain what the tool returns, how conversations are selected, or any side effects. Users would need to infer the behavior from the parameter names, which is insufficient for effective tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage of parameters with clear descriptions, including default behaviors for max_conversations and max_messages_per_conversation. Since the schema already documents the parameters thoroughly, the description is not required to add more, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Read' with the resource 'LinkedIn messages/conversations,' clearly stating the tool's function. It is easily distinguished from sibling tools like send_message and read_feed, which involve different actions or content types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where reading messages is appropriate, nor does it exclude other tools or mention any prerequisites, such as requiring an active login session.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the action 'save' but does not disclose whether it overwrites existing cookies, requires an active session, or has side effects beyond saving. This is a mutation tool with unknown 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the action and destination. No unnecessary words. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description adequately conveys the core function. It could be more complete with preconditions or side effects, but the essentials are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description covers profile_id as 'Profile identifier' with 100% coverage. The description adds no additional meaning to the parameter beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Save' with specific object 'cookies from active browser session' and destination 'profile storage'. Distinguishes from siblings like set_cookies and login by focusing on persisting existing session cookies rather than creating or setting them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this vs alternatives. Siblings include set_cookies and login which may be related, but the description does not mention them or state preconditions such as having an active browser session.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention any traits such as pagination behavior, rate limits, authentication requirements, or result formats, offering only the most basic intent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no wasted words, but it is under-sized for a tool with 6 parameters and no annotations or output schema. It lacks sufficient substance to be considered appropriately structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no annotations, no output schema), the one-line description is insufficient. It doesn't explain return values, filtering behavior, or any operational details that would help an agent use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter is already described in the schema. The description adds no additional meaning beyond the tool's overarching purpose, fitting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search for people on LinkedIn,' using a specific verb and resource. This distinguishes it from siblings like search_posts and get_profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions or lead users to other tools for different scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the search intent and does not clarify whether the operation is read-only, whether it requires an active session, or how scrolling and pagination work. This is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no redundant words. However, it is under-structured for a tool with four parameters, lacking any mention of the required profile_id or return behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is incomplete for a tool with no annotations and no output schema. It does not explain the role of profile_id, authentication requirements, the effect of scroll_count and max_posts, or how the results are returned. Given the sibling tools like read_feed and get_post, more context is needed to avoid ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides; it only restates 'keywords' which is already documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: searching LinkedIn posts by keywords. The verb 'search' is specific, the resource is 'LinkedIn posts', and the method 'by keywords' differentiates it from sibling tools like search_people (which searches people) and read_feed (which reads the feed without keyword filtering).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 does not mention any exclusions, prerequisites (e.g., authentication), or scenarios where read_feed or get_post would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention any side effects, authentication requirements, rate limits, or failure conditions (e.g., if the profile is not accessible or already connected). It provides zero behavioral transparency beyond the action itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is front-loaded with the action. However, its brevity limits its usefulness, so it does not earn a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the one-line description is insufficient for an agent to understand prerequisites, success/failure indication, or side effects. It is adequate for a trivial tool but incomplete for practical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage for all three parameters, so the description does not need to elaborate on them. Since the description adds no additional parameter context, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 the target ('a LinkedIn user'). It distinguishes itself from sibling tools like send_message by specifying the connection request resource, which is unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like send_message, nor any mention of prerequisites (e.g., being logged in or having a valid session). The description is a bare statement without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, but it only states the routing modes and does not disclose side effects, parameter precedence, or behavior when both routing params are provided. The existing_thread_only flag is also not explained, so the agent has limited understanding of what happens at runtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, front-loading the main action and routing options. Every word adds value and it is efficiently written.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters, no output schema, and no annotations, yet the description only mentions two routing modes. It does not explain required vs optional params, what happens if both conversation_id and participant_profile_url are provided, or what the response looks like. The description is inadequate for an agent to use this tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides detailed descriptions for each parameter (e.g., 'routes directly to thread', 'routes via profile compose flow'), and the description merely summarizes these. Since schema coverage is 100%, the description adds no additional semantic meaning beyond what is already structured, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Send a message') and specifies two distinct routing mechanisms ('conversation-id thread routing' or 'profile-url compose routing'), which differentiates it from the generic sibling send_message. It is concise and unambiguous about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage based on the two routing modes (conversation_id vs participant_profile_url), but does not explicitly say when to prefer this tool over the sibling send_message. It lacks exclusions or alternative guidance, leaving it up to the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description alone must convey behavioral traits. It only states the action, implying a side effect but omitting critical details such as authentication requirements, restrictions on recipients, or error/response behavior. This is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clean sentence that immediately conveys the tool's purpose. It is appropriately sized, with no unnecessary wording, and fully front-loaded. Although more content could be added to address other dimensions, the structure itself is excellent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, the presence of a similarly named sibling ('send_inbox_message'), and three required parameters, the description is insufficiently complete. It does not explain the tool's role relative to siblings, what constitutes a 'direct message,' or any operational context such as success/failure output. The single-sentence description is too minimal for a tool with this complexity and ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all three parameters with descriptions, so the baseline is 3. The tool description adds no further meaning and, notably, leaves the distinction between 'profile_id' and 'recipient_url' ambiguous. While the schema definitions are present, the description does not clarify the relationship or intended usage, but it also doesn't detract from the schema's coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'send' and the resource 'direct message to a LinkedIn connection,' making the core purpose understandable. However, it does not differentiate from the sibling tool 'send_inbox_message,' which likely performs a similar action, so it misses the highest mark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus 'send_inbox_message' or any other alternative. The description simply states the action without indicating prerequisites, exclusions, or context, leaving the agent uncertain about the appropriate scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It only states the basic action without covering side effects such as whether existing cookies are overwritten, whether the session persists, or any prerequisites or limitations. This is insufficient for a mutation tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with the core action front-loaded. There is no redundant information or filler; every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, the description is too sparse. It omits details about the optional parameters, the expected behavior after setting cookies, and the relationship to sibling tools like 'save_session_cookies'. This leaves the agent with significant ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by highlighting li_at as the primary cookie and connecting it to 'purchased accounts', but it does not explain how the optional 'cookies' array or 'jsessionid' relate to the core functionality beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Set', the resource 'LinkedIn authentication cookies (li_at)', and the target 'for a profile'. It also specifies 'for purchased accounts', which differentiates it from sibling tools like 'login' or 'save_session_cookies'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Use this for purchased accounts' provides a clear context for when this tool should be invoked. However, it does not explicitly mention alternatives or provide exclusion criteria (e.g., 'do not use for normal logins'), so it lacks full when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.