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

Beyond the annotations (which only declare non-readonly, idempotent, non-destructive, open-world), the description discloses a non-obvious side effect — opening the thread marks it read — plus the idempotency mechanism, post-action verification by reloading the thread, reversibility, and the fact that a new message returns the thread to the inbox. This is exactly the behavioral context an agent needs before mutating state.

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 action and target are front-loaded in the first sentence, followed by mechanics, idempotency, verification, and reversibility in that order. There is no filler; every sentence contributes operational 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?

For a one-parameter mutation tool with annotations and an output schema, the description covers the preconditions (thread ID), the side effect (marked read), the outcome (already_archived), and reversibility. Return-value details are unnecessary because an output schema exists.

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 single thread_id parameter is already documented with its source tools (get_inbox, search_conversations, get_conversation). The description adds only 'by thread ID', which restates the schema rather than extending it — baseline 3 for a fully documented single parameter.

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 opening sentence names a specific verb and resource — 'Archive one LinkedIn messaging thread, InMail included, by thread ID' — and scopes it to a single thread. An agent can distinguish it from get_inbox, get_conversation, and search_conversations without consulting the schema.

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 gives clear operational context: repeated calls on already-archived threads click nothing and return already_archived. It does not explicitly name which sibling to use instead when the goal is reading (get_conversation) or replying (reply_to_conversation), so routing is implied rather than spelled out.

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?

The destructiveHint annotation already signals this is a destructive action, and the description confirms it by saying 'Close' and 'clean up resources'. It adds some scope detail ('current browser session') but does not describe side effects such as invalidating cookies, logging out the user, or making the session unusable. Since the annotations carry much of the safety signal, a mid-range score is appropriate.

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

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

The entire description is a single, front-loaded sentence with no redundant words. It states the action and consequence efficiently, earning a top score for conciseness.

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 zero-parameter, destructive tool with an output schema and annotation coverage, the description is complete enough for an agent to know what will happen. The absence of an alternative, zero parameters, and existing destructiveHint mean no additional operational context is essential.

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 tool has zero parameters and the schema is empty with 100% coverage, so there are no parameter semantics for the description to clarify. With no params, the baseline is 4, and the description does not need to add parameter-level explanation.

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 ('Close') and names the resource ('current browser session') plus a clear secondary purpose ('clean up resources'). It is well-distinguished from all sibling tools, which focus on profiles, searches, messaging, and feed actions, not session lifecycle.

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 gives clear context that this tool ends the current browser session, implying it should be used when the session is no longer needed. There are no sibling tools providing an alternative session-close action, so explicit exclusions are unnecessary. A fully explicit 'use this when you are done' statement would improve clarity, but the context is already strong.

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?

The description mostly restates the destructiveHint annotation by saying MCP clients will prompt for confirmation. It does not add meaningful behavioral context beyond that, such as irreversibility, notification to the recipient, authentication requirements, or rate-limit implications.

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 short and front-loaded with the primary action. The second sentence about destructiveHint is slightly redundant with the annotations, but it communicates the user-confirmation behavior clearly and does not add much bulk.

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?

With two well-documented parameters and an output schema present, the description is mostly sufficient for invoking the tool correctly. It lacks explicit guidance on when to accept versus send, or on side effects, but these are not critical given the schema and annotations.

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 parameter docs already explain linkedin_username and note in detail. The description adds no additional parameter-level meaning beyond what the schema 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 clearly states the specific action: send or accept a LinkedIn connection request. It names the exact resource and distinguishes it from sibling tools like send_message or search_people.

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 makes it clear this tool handles connection requests and acceptances, which provides usable context for when to choose it. It does not explicitly name alternatives or exclusions, but the action is specific enough to avoid major ambiguity.

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?

Annotations already flag destructiveHint and openWorldHint, but the description adds substantial context beyond them: the mechanism (read title/company, click dismiss on the card, reload to confirm), the irreversibility ('LinkedIn offers no undo after a reload'), and the ambiguous-error case. This is exactly the operational detail an agent needs before a destructive call.

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?

Front-loads the purpose, then mechanism, then irreversibility, then error semantics — a sensible ordering with no filler. The middle sentence describing the click sequence is slightly verbose but carries real behavioral 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?

An output schema exists, so return values need no explanation, and the description still covers preconditions, irreversibility, and failure modes for a one-parameter destructive tool. Nothing an agent needs to call it safely is missing.

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% and the single job_id parameter is documented with format examples there, so the description does not need to explain it. The description adds no meaning about the parameter itself, which is the expected baseline when the schema does the work.

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?

Names a specific verb and resource (dismiss a job) plus the exact effect ('so later searches never show it'), which separates it cleanly from siblings like search_jobs, get_saved_jobs, and get_job_details. An agent can route to it without opening the schema.

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?

Explicitly scopes the tool to 'jobs already applied to or rejected', which is real when-to-use guidance, and adds an error condition for jobs not found on the first page. It stops short of naming sibling alternatives, so it is strong context rather than a full routing rule.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds meaningful behavioral context: the data comes from the /people/ page, demographics are unique to this view, and the company_name must be the exact URL slug, not the display name, with a concrete example. This goes beyond annotations without contradicting them.

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

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

The description is moderately long but every sentence earns its place: core purpose first, then usage routing, then keyword semantics, then the critical slug caveat. The Anthropic example is concrete and high-value, not filler. Structure is logical and front-loaded.

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 output schema exists, annotations cover safety, and the description covers purpose, routing, param semantics, and a caveat with an example, the definition is complete for an agent to select and invoke the tool correctly. No critical gap is evident.

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%, but the description adds substantial semantic value beyond the schema. It clarifies that company_name must be the exact LinkedIn URL slug, warns that display names often differ, gives the Anthropic example, and tells the agent to resolve ambiguity via search_companies. This is exactly the kind of parameter nuance that prevents incorrect calls.

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 'List employees at a company from the LinkedIn /people/ page' and uniquely identifies its value-add: the demographics aggregate (location, education, function breakdown). It distinguishes itself from siblings by noting these demographics are unique to this tool, so an agent can immediately tell it apart from search_people or get_company_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?

Explicit guidance is provided for when to use this tool vs alternatives: for filtered search by network degree or location, prefer search_people with current_company set. It even notes search_people returns more result pages, and instructs the agent to call search_companies first if the slug is uncertain. This is strong, actionable routing guidance.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the vague word 'recent' and says nothing about needing an active session (implied by the close_session sibling), how far back the feed is read, or how results are ordered — despite a scroll-budget parameter existing.

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?

A single tight sentence with no wasted words and the resource front-loaded. It is efficient, though its brevity is closer to under-specification than to optimal information density.

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?

An output schema exists, so return values need not be explained. However, for a session-based scraping tool the description omits the prerequisites (active session) and the sibling-routing context an agent needs, leaving it only minimally viable.

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%: company_name and max_scrolls are both fully documented in the schema, including the default of 10 scrolls and URL-to-slug reduction. The description adds no parameter meaning beyond that, 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?

States a specific verb and resource ('Get recent posts') and scopes it to 'a company's LinkedIn feed', which implicitly separates it from the personal-feed and search siblings. It does not, however, name get_feed or search_posts explicitly, so the differentiation must be inferred.

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 gives no when-to-use guidance at all. With siblings get_feed and search_posts present, an agent is left to guess whether this is the right tool for reading a company's activity versus searching or reading its own feed.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't note authentication/scope requirements, rate limits, or the fact that requesting `sections` changes cost/behavior. With annotations present the bar is lower, but this description contributes essentially no extra 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?

A single front-loaded sentence with zero waste. It is appropriately sized, though its brevity comes at the cost of substance rather than being maximally informative.

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?

Annotations and an output schema carry the return-value and safety burden, so much is delegated. However, for a tool with multiple overlapping company siblings, the description is too thin to help an agent route correctly, leaving a real gap in sibling differentiation.

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 both parameters are already fully documented in the schema, including the `sections` enum-like values and default. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb (get) and resource (a company's LinkedIn profile), making the core action unambiguous. It distinguishes the target as a company rather than a person, but does not differentiate from close siblings like get_company_posts, get_company_employees, or search_companies.

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 such as search_companies or get_company_employees. No prerequisites, no exclusions, and no mention of when the extra `sections` should be requested are provided.

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 only openWorldHint in annotations, the description carries the behavioral burden and does so well: it discloses that username resolution click-visits each row and 'may mark it as read' (a real side effect), describes the indexable-prefix limits, the refusal behavior for out-of-prefix indexes, and that search is only a fallback. This is exactly the kind of non-obvious operational context structured fields cannot convey.

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?

Purpose and the two lookup paths are front-loaded, which is good, but the middle paragraphs are dense and hard to parse (e.g. 'indexable sequence ends before the first unresolved click, missing matching click target, or admitted row'), and the LinkedIn-sidebar implementation rationale is arguably more internal detail than an agent needs. It is informative but not tight.

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?

An output schema exists so return values need not be described, and the description still covers resolution paths, side effects, failure/refusal conditions, and fallback ordering. For a 3-param read tool with light annotations, nothing material an agent needs to call it correctly is missing.

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 the baseline is 3, but the description adds genuine meaning: it explains the index resolution semantics, the prefix barrier that causes an index to be refused, and that a known thread_id bypasses resolution entirely. This goes beyond the schema's terse per-field notes.

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?

States a specific verb and resource ('Read a specific messaging conversation') and immediately specifies the two identification paths, which cleanly separates it from get_inbox (list) and search_conversations (search). It does not name those siblings explicitly, so the differentiation is implied rather than stated.

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?

Gives concrete guidance on when to use linkedin_username vs thread_id ('Pass thread_id directly to skip this enumeration') and points to search_conversations for enumerating thread IDs. It stops short of an explicit when-not-to-use or a direct contrast with get_inbox, so it is clear context without full routing.

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?

The description explains the otherwise puzzling readOnlyHint=false annotation: it opens the Easy Apply dialog and clicks Next while prefilled values are accepted, which is why it is not read-only. It further discloses that nothing is typed, Review and Submit are never clicked, and the dialog is closed with the draft discarded, plus the truncation rule (first step needing input ends the read) — all behavior not derivable from the annotations.

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

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

Front-loaded with the core action and scope in the first sentence, then a structured walkthrough of what is read and what is never done. It is slightly long for a single-parameter read tool and the 'Next is clicked only while…' sentence is dense, but nearly every clause carries behavioral 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?

With an output schema present, the description need not describe return values, and it covers the process, its stopping condition, and its side effects well. It is only marginally incomplete in not saying what happens when the posting has no Easy Apply form or how failures surface.

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% and the single job_id parameter is documented in the schema with examples, so the description adds no parameter-level meaning. Baseline 3 applies; nothing here compensates for or extends 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?

States a specific verb and resource ('Read the questions of a job posting's Easy Apply form') and immediately delimits scope with 'without answering them'. This clearly separates it from siblings like get_job_details and get_job_apply_url, which an agent could otherwise confuse with a form-reading tool.

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 'without answering them' clause and the note that the read stops at the first step needing input tell the agent exactly when this tool is applicable (inspection-only). It does not, however, explicitly name an alternative for the case where the agent actually needs to submit an application, so the routing is implied rather than spelled out.

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?

The description does not disclose behavioral traits beyond the annotations: it only says 'Get posts', which is consistent with readOnlyHint=true but adds no new behavioral context. Notable behavior like batched loading and count overshooting appears only in the schema property description, not in the tool description.

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?

A single short sentence with no filler, front-loading the action and resource. It is concise without sacrificing clarity.

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 read-only feed fetch with one optional parameter and an output schema, the description plus schema provide all necessary information. The feed scope is clear, and nothing critical is missing.

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 the num_posts parameter fully documented including default, range, and batch behavior. The tool description itself adds no parameter detail, but the schema already carries the full semantic burden, 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?

States a specific verb 'Get' and a specific resource 'posts from the authenticated user's LinkedIn feed', which clearly distinguishes it from sibling tools like get_company_posts and search_posts. The phrase 'authenticated user' pins the scope unambiguously.

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 intended use — fetching the current user's LinkedIn feed — is reasonably implied by the description, but there is no explicit guidance about when to choose this over alternative tools such as search_posts or get_company_posts. No exclusions or routing hints are provided.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description does add behavioral context (scan can stop, section_errors.inbox reports that stop, captured text is retained), but it is buried in scraped-page implementation jargon rather than stated as caller-relevant behavior.

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 first sentence is well front-loaded, but the remaining three-to-four sentences dwell on internal scraping mechanics (compose page, measured variant, click-derived references, scan stopping) that a caller does not need. Significant bloat for a one-parameter read 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?

An output schema exists, so return values need not be spelled out, and for a single-parameter read tool the definition is more than long enough. However, it spends its length on implementation detail while omitting the one thing an agent needs: how this tool relates to search_conversations and get_conversation.

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?

Only one parameter (limit) exists and schema coverage is 100%, including range and default, so the schema carries the full burden. The description adds nothing about the limit semantics, matching the baseline for a fully documented 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 opening sentence gives a clear verb+resource ('List recent conversations from the LinkedIn messaging inbox'), so the agent immediately knows what the tool returns. It does not distinguish itself from the siblings search_conversations or get_conversation, which list/fetch similar data, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus search_conversations or get_conversation. The only routing hint is an oblique trailing remark that 'a known thread_id can bypass row attribution when calling get_conversation,' which is not framed as guidance a caller can act on.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: it clarifies the call inspects the posting without triggering any click/navigation or application flow, which tells the agent there are no side effects on the employer's page.

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?

Two short sentences, front-loaded with the core purpose and followed by the behavioral qualifier. No filler or redundancy, though the second sentence is a minor stylistic flourish rather than essential 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?

An output schema exists, so return values need no explanation, and the single required parameter is fully documented in the schema. For a one-param read tool this is largely complete; only cross-tool routing guidance is missing.

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 a single job_id parameter, so the schema already carries the semantics. The description adds nothing about the identifier format or expected values, 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?

The description names a specific verb (Get) and resource (how a job posting takes applications / the employer's application link), which is more precise than the bare title. It implicitly distinguishes itself from the sibling apply_to_job by describing retrieval of the application method rather than performing the application, though it never names that sibling explicitly.

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?

Usage is only implied: an agent can infer this is a preview step before applying, but there is no explicit when-to-use, when-not-to-use, or comparison against get_job_details or apply_to_job. 'Reads the posting without clicking anything' hints at the read-only context but does not route the agent between tools.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate basic safety. The description adds no meaningful behavioral context beyond the annotations, such as what kind of details are returned or whether the job must be publicly accessible. It is consistent with the annotations, so no contradiction.

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

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

The description is one short sentence with no filler. It front-loads the action and resource, 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 the tool's simplicity—one parameter, full schema coverage, output schema present, and read-only annotations—the description is nearly complete. The only minor gap is lack of explicit guidance on when to choose this over search_jobs, but the 'specific job posting' wording covers the core usage 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?

The schema has 100% coverage for the single parameter, including an example format for job_id. The description does not add additional parameter meaning beyond what the schema already provides, but with full schema coverage the baseline 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 ('Get'), the resource ('job details'), and the scope ('for a specific job posting on LinkedIn'). It distinguishes itself from sibling tools like search_jobs and get_saved_jobs by emphasizing a specific job ID rather than searching or listing.

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 a specific job posting' implies this tool should be used when you already have a job_id and need details, as opposed to searching for jobs. However, it does not explicitly state when not to use it or name alternative tools.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a non-obvious implementation trait: it navigates to /in/me/ and resolves a redirect so the returned url is the real profile URL. That is genuinely useful context an agent could not infer from schema or annotations. It stops short of mentioning rate limits, login/session prerequisites, or cost of the extra navigation.

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?

Two short sentences, front-loaded with the purpose and followed by the one behavioral nuance that matters. No filler or repetition of schema content.

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?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The redirect-resolution note fills the main gap; only the relationship to get_person_profile (and any session precondition) is left 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?

Schema coverage is 100%, with sections and max_scrolls fully documented in the schema, including enum-like section names and a reference to get_person_profile semantics. The description adds no parameter information, 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?

States a specific verb and resource ('Get the authenticated user's own LinkedIn profile') and scopes it to the authenticated user, which cleanly separates it from the sibling get_person_profile that targets arbitrary people. An agent can select this without opening the schema.

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?

Usage is implied by 'the authenticated user's own profile', which suggests when to prefer this over get_person_profile, but the description never names that sibling or states an explicit when-to-use/when-not-to-use rule. Nothing tells the agent whether to use this first as a session/anchor step.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description adds nothing: no mention of authentication requirements, rate limiting or scraping throttling, behavior for nonexistent or private profiles, or cost of requesting heavy sections. The pagination guidance lives in the schema, not the description.

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

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

A single front-loaded sentence with zero filler. It is efficient, though its brevity borders on under-specification given the tool's scraping 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?

An output schema exists and parameters are fully documented, so return values needn't be explained. However, for an open-world scraping tool the description omits failure modes (invalid username, private profile, rate limits) that an agent would need to plan around.

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 detailed documentation of sections, max_scrolls, and linkedin_username, so the baseline is 3. The description contributes no additional parameter meaning, such as when to prefer a separate call for heavy sections, though the schema itself already states that.

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?

States a specific verb and resource ("Get a specific person's LinkedIn profile"), which distinguishes it implicitly from siblings like get_my_profile, search_people, and get_company_profile. It does not explicitly name or contrast with those siblings, so it stops short of a 5.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer from sibling names that search_people finds usernames first and get_my_profile covers the authenticated user's own profile.

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?

The readOnlyHint and openWorldHint annotations already establish that this is a safe read against external LinkedIn data. The description adds useful relational behavior (the returned job_ids are meant to feed get_job_details), but says nothing about ordering, page budget effects, or what an empty result means for a user with no jobs in that stage.

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?

Two short sentences, front-loaded with what it returns and followed by the actionable next step. Nothing is redundant or padded.

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 two-parameter read-only lister with a full schema and an output schema, this covers purpose, scope and follow-up. The only gap is not hinting at pagination/truncation behavior implied by max_pages, which matters if the agent must page through a large tracker.

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%, and the stage enum is documented in detail there, including the meaning of 'applied'. The description only echoes the stage concept ('at one stage') and adds no format, default, or interaction detail beyond the schema, so it sits at the baseline.

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 pairs a specific verb (List) with a specific resource (the authenticated user's jobs in LinkedIn's job tracker) and adds a scope qualifier (one stage). This clearly separates it from search_jobs (which searches the wider job corpus) and from get_job_details (which expands a single job).

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 states the intended workflow: list to obtain job_ids, then pass those ids to get_job_details for full info. That is genuine when-to-use guidance for the follow-up call, but there is no explicit exclusion such as 'use search_jobs instead when you don't know the employer/user's saved state'.

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?

Goes well beyond readOnlyHint/openWorldHint by disclosing that no browser is opened, no setup or login occurs, no LinkedIn contact is made, and the browser idle timer is not refreshed. It also flags the important semantic caveat that stored files do not prove current authentication and that in shared-browser mode observations belong to the owner rather than a frontend running a login.

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?

Front-loaded with the purpose, then layered caveats and the sibling-routing sentence. Every sentence carries information, though the idle-timer sentence is slightly awkwardly worded and the density of caveats makes it longer than strictly minimal.

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?

With an output schema present, return values need no explanation, and with no parameters there is nothing else to document. The description covers safety-adjacent semantics (auth proof, shared-browser ownership) plus the selection rule, leaving nothing an agent needs before calling it.

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 tool takes zero parameters, so the baseline is 4 and there is no parameter meaning the description could add. It does not waste space restating an empty 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?

States a specific verb and object: report local saved-session and serving-process state for diagnostics. It is immediately distinguishable from every sibling, which are all LinkedIn actions, and it explicitly disclaims LinkedIn interaction so the agent will not confuse it with a connectivity or auth check.

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?

Gives explicit when-to-use (requested diagnostics) and an explicit when-not-to-use: 'Use ordinary LinkedIn tools directly for their requested work rather than adding a status preflight.' That names the alternative behavior, which is the main mis-selection risk for a status tool in a browser-automation suite.

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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral detail beyond that: it follows 'Show all' links to return the full list rather than a truncated preview, and it silently skips sections that redirect to linkedin.com/premium. That extra fan-out behavior is exactly the kind of context an agent needs, though it doesn't mention rate limits or failure modes.

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

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

Three short sentences, front-loaded with what it returns and where it reads from, then the fan-out behavior, then the skip rule. No filler, no repetition of the title or schema.

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?

An output schema exists, so return payload shape need not be explained, and annotations carry the safety profile. The description covers source sections, expansion behavior, and skip logic, leaving only edge cases (e.g., empty sections, section ordering) unspecified — a minor gap.

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% and there is only one parameter, so the schema already documents linkedin_username (including the URL-or-handle form and examples). The description adds nothing about the parameter, which is the expected baseline 3 when the schema does the work.

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 names a specific verb+resource (get profile links) and narrows the scope precisely to sidebar recommendation sections on a profile page, enumerating the exact sections: 'More profiles for you', 'Explore premium profiles', 'People you may know'. This is enough for an agent to distinguish it from siblings like search_people or get_person_profile without inspecting their schemas.

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?

Usage is implied by the tightly scoped resource (sidebar recommendations only), but the description never states when to prefer this over get_person_profile, search_people, or get_feed, and gives no prerequisites or exclusions beyond the premium-redirect skip. Adequate but leaves routing to inference.

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?

Beyond the destructiveHint/openWorldHint annotations, the description discloses the verification gate (page must land on exactly the requested thread, composer must be the single visible editor in the main region with one submit button in its own form), the fail-closed policy, named failure statuses, and the fact that an existing draft is left untouched. It also scopes destructiveness precisely: it is a write operation only when confirm_send is True, which refines rather than repeats the destructiveHint annotation.

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?

Content is front-loaded with purpose first, then the verification and failure behavior, and nearly every sentence carries operational information. It is dense and long for a single tool, with some artifacts (double spaces, backticked status values) that slightly impede scanning, but there is no filler or repetition of the schema.

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 destructive, browser-driven write tool this covers what an agent needs: prerequisites (thread_id sources), safety gating, dry-run semantics, and enumerated failure outcomes. An output schema exists, so return-shape detail is correctly omitted while status meanings that affect the agent's next action are still explained.

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 the baseline is 3; the description earns a step above by adding acquisition guidance for thread_id (where to get it) and by clarifying that confirm_send=False is a dry run that still verifies the thread and composer, types nothing, and reports the recipient. Message formatting rules are left entirely to the schema, which 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 opening sentence states a specific verb and resource (reply inside an existing LinkedIn messaging thread) and immediately extends scope (InMail included). It also distinguishes itself from the profile-based path by explaining that the InMail sender may have no Message action, which is the concrete reason this tool exists separately from send_message.

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

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

It tells the agent where the required thread_id comes from (get_inbox, search_conversations, get_conversation) and gives explicit when-not conditions: quick-reply-only threads return composer_unavailable, threads with an existing draft return composer_occupied, and quick-reply buttons are never clicked. It also points to send_message for the enter_to_send_enabled case, so the alternative path is named rather than left to inference.

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?

The description discloses no behavioral traits beyond what 'search' and 'LinkedIn' naturally imply. Annotations already declare readOnlyHint and openWorldHint, but the description adds no further context about result limits, matching behavior, or ordering. It is not contradictory, but it is also not informative beyond the basic action.

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 compact sentence that wastes no words and immediately states the core action and target resource. 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?

For a one-parameter tool with an output schema and safety annotations, the description is minimally adequate. However, it does not clarify edge behavior, result scope, or how it differs from nearby company-related tools, so an agent may still need to infer intent.

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 fully documents the only parameter, keywords, with a useful example. The description adds no additional semantic detail beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the verb ('Search') and resource ('companies on LinkedIn'), so an agent can understand the basic function. However, it does not differentiate itself from sibling tools like get_company_profile or search_people, leaving some ambiguity about scope or result type.

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 instead of search_people, get_company_profile, or get_company_employees. The description implies keyword-based discovery but provides no explicit context, prerequisites, 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?

Annotations supply only openWorldHint=true, so the description must carry the behavioral load, and it does disclose two real traits: row clicks may mark conversations read, and an unverifiable click halts further enumeration with diagnostics in section_errors.search_results. However, this is expressed in opaque internal jargon ('click-derived references', 'observed different thread path') that an agent cannot readily act on, and it omits permissions or rate-limit 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 first sentence is properly front-loaded, but the second paragraph is long, jargon-heavy, and largely about the scraper's internals rather than what the caller needs. Those sentences do not earn their place for an agent selecting or invoking the 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?

An output schema exists, so return values need not be explained, and the description correctly gestures at where errors surface. Still, it leaves the agent without a clear picture of result shape, ordering, or how this tool relates to get_inbox/get_conversation, which is a meaningful gap for a search tool with a truncation caveat.

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%, and both parameters are already well documented in the schema, including the read-marking side effect of the limit parameter. The description adds no additional syntax, format, or matching semantics (e.g., how keywords are combined) beyond what the schema provides, 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 opening sentence gives a verb and resource ('Search messages by keyword'), but it names 'messages' while the tool is 'search_conversations', creating a small mismatch. It never distinguishes this tool from the closely related get_inbox and get_conversation siblings, and the rest of the description drifts into internal scraping mechanics rather than clarifying purpose.

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 when-to-use guidance and no named alternative, despite three plausible siblings (get_inbox, get_conversation, search_posts). The only quasi-guidance is the schema note about preferring a low cap for noisy queries, which lives in the schema, not the description.

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?

Annotations only declare readOnly and openWorld; the description adds substantial behavioral context beyond them — the LinkedIn redesign, which filters are dropped, that drops are surfaced in section_errors as filters_dropped, and that quotes do not force exact phrases. This is exactly the kind of degradation and error-reporting behavior an agent cannot infer from structured fields.

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?

Front-loads purpose and the job_id handoff in two short sentences, then a single focused paragraph on the redesign caveat. Slightly wordy in places ('keep doing so'), but every sentence carries actionable 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?

An output schema exists, yet the description still adds the useful job_ids-to-get_job_details linkage. For a nine-parameter search tool with a nontrivial fallback path, the description covers the failure mode, the workaround, and the error field an agent should inspect.

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 the schema already documents all nine parameters and their values. The description still adds meaning by explaining that several filters are 'Classic search only' and will be dropped on redesigned search, plus keyword syntax caveats (words narrow results, quotes are not exact).

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?

States a specific verb and resource ('Search for jobs on LinkedIn') and immediately clarifies the output relationship: returns job_ids that feed get_job_details. This distinguishes it from the sibling detail-fetch tool without the agent needing to open either schema.

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?

Gives concrete guidance for the redesigned-search case: when filters are dropped, re-run with location/work type folded into keywords, and notes that words like 'senior' narrow results. It does not discuss when to prefer this over neighboring tools such as search_people, but the domain is clear enough that this is a minor gap.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, open-world read. The description adds nothing beyond that: no mention of result caps, pagination behavior, throttling risk, or that LinkedIn silently ignores plain-text location and company filters. That filter-failure behavior is detailed in the schema, but the description itself contributes no 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?

A single sentence with no wasted words, front-loaded with the verb and resource. It is efficient but under-specified; concision here comes at the cost of useful detail rather than from careful editing.

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 four parameters, full schema coverage, an output schema, and read-only annotations, so much of the burden is already carried by structured fields. Still, a search tool with filters and an output schema deserves at least a note on result shape or filtering caveats. The description supplies none of that, leaving it minimally adequate for its complexity.

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 schema already explains the network tokens (F/S/O), the numeric geo URN for location, and the company URN lookup path in detail. The description repeats none of this and adds no meaning beyond 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 states a specific verb and resource: 'Search for people on LinkedIn.' This distinguishes it from search_companies, search_jobs, and search_posts by resource even though those siblings are never named. It stops short of the sibling-differentiation required for a 5.

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 rather than alternatives such as get_person_profile, get_company_employees, or get_sidebar_profiles. No prerequisites, no mention of connection limitations, and no note on when a keyword search is the right approach instead of a direct profile lookup.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and reach profile is covered. The description adds that results are an open global content search, but says nothing about result volume, pagination behavior, or rate limits beyond what the schema's max_pages note already provides.

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?

Front-loads the verb, resource, and scope in the first clause, then justifies the use case and the sibling distinctions. Every sentence earns its place; only minor tightening is possible.

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?

With an output schema, full schema coverage, and read-only/open-world annotations, the description covers what an agent needs to select the tool. It could be richer about expected result volume for a scroll-based search, but nothing essential to correct invocation is missing.

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%, including enum-like values for date_posted and content_type and the infinite-scroll semantics of max_pages, so the schema carries the parameter burden. The description adds no keyword syntax, quoting, or filtering guidance beyond 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?

States a specific verb and resource ("Search LinkedIn posts/content") plus the scope "globally by keyword" and identifies the UI counterpart (the "Posts" tab). An agent can distinguish this from get_feed and get_company_posts purely from the description.

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?

Gives an explicit use case (catching informal hiring posts before a formal listing exists) and names two alternatives with the condition that selects against them: get_feed for your own home feed and get_company_posts for a single company's page. Nothing about routing is left to inference.

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?

Annotations declare destructiveHint=true and openWorldHint=true, and the description is fully consistent, explicitly scoping the write behavior to confirm_send=True. Beyond the annotations it discloses failure modes not visible in structured fields: the enter_to_send_enabled status and what to tell the user, the fail-closed recipient authorization rule, the absence of any private/Voyager API, and retry_safe as the authority for retrying.

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?

Front-loaded with purpose and the reply-alternative routing, then the connection-prerequisite, then status/failure handling — a sensible priority order. It loses a point for the dense implementation aside about validating a Message action, following browser navigation and pinning the final route, and for a return-value paragraph (thread_id, retry_safe) that partly duplicates the output schema.

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 destructive, open-world write tool with four parameters, this covers purpose, alternatives, prerequisites, authorization behavior, dry-run behavior and the one non-obvious account setting that blocks sending. Nothing an agent needs in order to decide or retry is missing.

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 the baseline is 3, but the description adds real meaning the schema lacks: confirm_send=False is framed as a dry run that still reports the Enter-to-Send status, and profile_urn is characterized as corroboration only that never bypasses recipient verification. The message-formatting details are left entirely to the schema, which is fine given the 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?

Opens with a specific verb+resource+scope ("Compose and send a new message to a LinkedIn user") and immediately distinguishes itself from reply_to_conversation by naming the sibling and the exact situation each covers. An agent can route between send_message and reply_to_conversation without opening either schema.

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?

Gives explicit when-to-use and when-not-to-use rules: existing recruiter/InMail threads go to reply_to_conversation with the thread id, and non-messageable recipients require connect_with_person first with a retry only after acceptance. It also documents the dry-run path (confirm_send False) as the pre-flight check, which is exactly the decision support an agent needs.

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