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

No annotations are provided, so the description carries the burden, and it does disclose useful access context: a cookieless guest surface that works even for logged-off captures. That is real behavioral value, but permissions, rate limits, and failure modes (e.g., missing/invalid slug) are unstated.

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 tight sentences, front-loaded with the action and resource, and the field list is compact. The second sentence about the guest surface is relevant but slightly tangential to selection.

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 single-parameter read tool with no output schema, the description usefully enumerates the returned fields and explains the access path, covering the two biggest gaps. It falls short only on error/edge-case behavior and sibling routing.

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 a single required parameter, so the baseline is 3. The description's phrase 'universalName slug' merely echoes what the schema already documents with examples ('stripe', 'vercel'), adding no new syntax or constraint detail.

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 (Fetch) and resource (LinkedIn company entity) and enumerates the returned fields, plus the input key (universalName slug). It's clear what the tool does, though it never explicitly contrasts itself with siblings like linkfetch_search_companies or linkfetch_get_company_employees.

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

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 linkfetch_search_companies (find by query) or linkfetch_get_company_employees. The slug-based lookup implies a direct-entity fetch, but that inference is left entirely to the agent.

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 and does so well: it discloses the cache-first behavior, the specific failure mode (`extension_required` on miss) and the user action it demands, plus the exact cost model (3 credits + 1 per result scaling with page size). This is unusually rich operational context for a data-fetch 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?

Three dense sentences, front-loaded with purpose before moving to pagination, the capture fallback, and cost. Every clause carries information an agent needs; nothing is padding.

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 no output schema, the description compensates by naming the returned fields, and it also covers pagination, the error path, and cost. An agent has everything needed to call this correctly and to interpret a miss.

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 slug, limit, and offset are already fully documented in the schema (including the ~1000 LinkedIn cap). The description's 'Paginated' only restates limit/offset without adding syntax or semantics, 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 (list) plus resource (people currently working at a company) and enumerates the returned fields (name, headline, location, profile URL). This clearly distinguishes it from linkfetch_search_people, which searches across people rather than enumerating a single company's employees.

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 a clear operating context: you need a company slug, results are paginated, and cache misses require the user to capture the page via the extension. However, it never explicitly contrasts this with search_people or states when-not to use it, so the alternative-selection guidance is only implied.

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 disclosure burden, and it discloses almost nothing beyond the name: no auth/credential requirements, no rate-limit or quota behavior, no pagination semantics, and no definition of what 'recent' means. Only the read-only nature is implicit in the verb 'get'.

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 fragment with zero filler; the resource and the keying parameter are both stated in the first clause. It is efficient, though so terse that it borders on under-specification.

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?

There is no output schema and no annotations, so the description is the only place to explain return shape, ordering, and pagination interaction ('recent' with limit/offset). For a simple 3-param read tool with full schema coverage this is minimally acceptable, but 'recent' is left undefined and no behavioral context is supplied.

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 slug, limit, and offset are all documented in the schema itself. The description only echoes the slug requirement ('by company slug') and adds nothing about pagination behavior or ordering, so it hits the baseline of 3 without exceeding it.

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/list), resource (posts), and scope (published by a LinkedIn company page), which separates it from the profile-posts and single-post siblings. It never names those siblings explicitly, so differentiation is inferable 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?

The description implies you call this to read a company page's posts, but gives no when-to-use condition, no exclusions, and no pointer to alternatives such as linkfetch_get_profile_posts, linkfetch_search_posts, or linkfetch_get_post. An agent must open the sibling schemas to route correctly.

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 disclosure burden, and it discloses almost nothing: no indication of read-only nature, auth requirements, rate limits, or what happens on an invalid/missing id. For a simple fetch this is a modest but real 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?

A single tight phrase with no filler, and the identifying parameter is front-loaded. Slightly under-specified rather than over-long, but nothing is wasted.

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 a simple one-parameter lookup, and the schema covers the only input, so the definition is minimally adequate. However, with no annotations and no output schema, the description does not say what details are returned or how errors 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 coverage is 100%, and the schema already documents the numeric pattern and where to find the id, so the description's 'numeric group id' is nearly redundant. Baseline 3 applies 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?

States the resource (a LinkedIn group) and the action (retrieve details) keyed by numeric id, which is enough to distinguish it from sibling fetches like get_profile and get_company. It is a noun phrase rather than an explicit verb+resource sentence, but the intent is 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?

There is no guidance on when to use this versus linkfetch_search_groups or any sibling, nor any stated prerequisites. The reader must infer that this is the single-record lookup counterpart to the search 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the returned payload fields (description, salary, workplace type, company, application links), compensating for the absent output schema. But it says nothing about auth requirements, rate limits, or behavior on a missing/invalid ID.

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 sentences, each earning its place: purpose, return payload, and alternative routing. The most important information (what it does and how to key it) is front-loaded with zero filler.

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, the description compensates well by enumerating the return payload, and the single parameter is fully documented in the schema. Only the lack of auth/error behavior keeps it short of 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?

Schema description coverage is 100% and there is a single required parameter, so the schema already documents format and example. The description reinforces 'numeric LinkedIn job ID' but adds no syntax or constraint beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource ('Fetch a single job posting') plus the keying mechanism ('numeric LinkedIn job ID'). It also names the sibling it is distinct from (linkfetch_get_job_by_url), so an agent can differentiate it without opening a 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 routes the agent to linkfetch_get_job_by_url 'if you only have a LinkedIn URL', which is a concrete when-to-use-the-alternative rule. It does not, however, address when to prefer this over linkfetch_search_jobs, so guidance is strong but not exhaustive.

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 and does usefully disclose per-call credit cost (1 credit) and the observation window ('since LinkFetch started watching it'). It does not cover behavior when a posting was never observed, error cases, or auth/rate-limit constraints, so the disclosure is good but incomplete.

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

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

The what-it-returns and why-to-use-it content is tightly front-loaded in the first two clauses. The closing sentence is longer and doubles as a sales pitch for the paid dataset, though it does carry actionable routing 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 single-parameter read tool with no output schema, the description adequately conveys what comes back (timestamped count history plus velocity) and the cost of the call. It stops short of describing the response shape or the behavior for postings with no observed history.

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 `id` parameter is fully documented with a regex pattern and an example LinkedIn URL. The description adds no format or validation detail beyond 'one job posting', so the schema does all the work — 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 ('Fetch') and a precisely scoped resource: the observed applicant-count time series for one posting, including every timestamped change plus derived velocity. This is clearly distinguishable from sibling posting tools like linkfetch_get_job, which return the posting itself rather than its applicant history.

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 analytic intent ('judge how contested a role is, whether interest has stalled, how fast the funnel is filling') and names the bulk alternative (the jobs dataset) with its own pricing. It does not, however, contrast itself against the closest sibling, linkfetch_get_job, so the agent must infer the boundary.

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 usefully discloses input-robustness behavior (canonical slugs, locale-prefixed hosts, bare /jobs/view paths, urn:li: strings), which goes beyond a plain restatement, but says nothing about auth requirements, rate limits, failure behavior for malformed or non-LinkedIn URLs, or what is returned.

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 sentences, front-loaded with the action and resource, with the input-format detail following. Every clause earns its place and nothing is 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 one-parameter fetch with full schema coverage, the description adequately covers what the tool does and what inputs it accepts. It is still incomplete on the sibling relationship (linkfetch_get_job vs. this URL-based variant) and on any error or return-shape expectations, which matters since there is no output schema.

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 schema's example already shows URL, URN, and bare-ID forms. The description adds the locale-prefixed host and /jobs/view/<id> variants, but this overlaps heavily with the schema, so the 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?

States a specific verb and resource ('Fetch a single job posting') plus the exact input domain (LinkedIn job URL or URN), so the agent knows what it returns and what it consumes. It does not explicitly differentiate itself from the sibling linkfetch_get_job, which likely also fetches a job, leaving that routing decision to the agent.

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: use it when you have a URL/URN rather than an ID, since the accepted input forms are enumerated. There is no explicit when-to-use vs. when-not, and the near-identical sibling linkfetch_get_job is never named as the alternative.

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 behavioral burden. It discloses the return payload (text, author, counts) but says nothing about read-only status, authentication requirements, rate limits, or error behavior for a read operation.

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

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

One sentence that front-loads the resource and payload before giving the identifier's format and source. 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?

For a simple one-parameter read tool with no annotations and no output schema, the description covers the resource, the return fields, and the id's origin. It omits authentication and usage routing, but those are not critical for an agent to call this GET 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% and the single parameter is documented as 'Numeric activity id.' The description goes beyond the schema by explaining where the id comes from (the number in the LinkedIn activity URL), adding useful lookup context.

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 identifies the specific resource (a single LinkedIn post) and its key (activity id), and lists the payload (text, author, counts). It does not name a sibling tool to contrast against, but the singular 'a single post' distinguishes it from list/search siblings like search_posts or get_profile_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?

No explicit when-to-use statement, no when-not, and no alternative tools are named. The only guidance is implicit in the identifier format, which tells the agent what input is needed but not when to choose this tool over search_posts or get_post_reactions.

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 only implies a read operation. It omits auth requirements, rate limits, pagination behavior (despite limit/offset params), or what the response contains, leaving significant behavioral gaps.

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

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

The description is a single front-loaded sentence with no wasted words, which is efficient for a simple read tool. However, it is arguably too terse for the tool's behavioral complexity, keeping it from 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 no output schema and no annotations, the description should explain what is returned (e.g., list of profiles with pagination) and any behavioral constraints. It provides none of this, leaving the agent under-informed for 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?

Schema coverage is 100%, so all parameters are fully documented in the schema itself. The description mentions only the required activity_id and adds no meaning 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-resource pair ('Who reacted to a LinkedIn post') and scopes it by activity id, making it distinguishable from siblings like get_post. However, it does not explicitly name or differentiate from alternative tools, so it falls short of a 5.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. The agent must infer that this is the right tool for reactions rather than, say, get_post, with no help from 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?

With no annotations, the description must carry the behavioral burden, and it discloses a genuinely important failure mode: cache-first with an `extension_required` error on miss instructing use of the Chrome extension. It omits auth prerequisites and any rate-limit behavior, which is notable given sibling safety tools exist.

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 sentences, zero filler. The capability and input contract come first, the cache/error caveat second — correctly 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?

Enumerates the return payload in lieu of an output schema and covers the error path, so an agent can act correctly. Missing only prerequisite/permission context and rate-limit awareness, which matter for a scraper-style tool in this 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?

Schema coverage is 100%, so 3 is the baseline, but the description adds real value the schema cannot express: the mutual-exclusivity constraint 'exactly one of url or slug', which is not encoded as a oneOf in 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?

Specific verb+resource ('Fetch a full LinkedIn profile') with an explicit enumeration of the returned fields and the two accepted identifiers. It is trivially distinguishable from siblings like linkfetch_search_people or linkfetch_get_company.

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 clear invocation context ('Provide exactly one of `url` or `slug`') and states the cache-first path. It does not, however, tell the agent when to prefer this over linkfetch_search_people (search vs. direct fetch) or what happens on a cache hit.

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 disclosure burden. It adds only the 'recent' temporal qualifier; it says nothing about pagination behavior (despite offset/limit params), rate limits, auth requirements, or what a returned post contains.

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 the resource and the identifying input front-loaded; the parenthetical clarifying 'activity feed' is the only addition and it earns its place. No filler.

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 tool with fully documented params this is minimally adequate, but with no annotations and no output schema the description leaves the response shape (what fields a 'post' includes) and pagination semantics entirely unexplained.

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 all three parameters are already documented in the schema, which sets the baseline at 3. The description's 'by profile slug' reinforces the required parameter but adds no format or constraint detail 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 ('get posts') and resource ('recent posts by a LinkedIn member / their activity feed'), scoped by profile slug. The 'member' qualifier implicitly separates it from linkfetch_get_company_posts, but no sibling is named explicitly, 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 phrase 'recent posts... activity feed' hints at the use case but gives no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as linkfetch_search_posts or linkfetch_get_post. An agent must infer selection 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 behavioral burden. It discloses that no credits are consumed and describes the return content (scale, schema, sample URL, SQL access), which is useful context. It does not mention permissions or rate limits, but for a zero-parameter informational tool this is largely sufficient.

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 front-loaded with the core purpose and return details, and each sentence contributes value. The long list of use cases is slightly run-on but still efficient and well-structured overall.

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 informational tool with no output schema, the description is complete: it explains what the tool returns, when to use it, and that no credits are consumed. Nothing essential for calling the tool 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?

The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it appropriately focuses on what the tool returns and when to use it.

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 ('Describe') and resource ('LinkFetch's bulk LinkedIn jobs database') and clearly differentiates it from metered job-data APIs. It also distinguishes itself from sibling tools like search_jobs by emphasizing bulk data, SQL access, and a free sample.

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 a detailed list of when to call this tool, covering bulk job postings, hiring-signal analysis, applicant-count trends, dataset creation, and SQL queries. However, it does not explicitly state when not to use it or name sibling alternatives like search_jobs for smaller queries.

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 and no output schema, the description carries the full burden. It does disclose the meaningful states (connected / not connected / expired) and the recovery path via the connect link, which is good behavioral context. It stops short of describing auth prerequisites, the exact shape of the response, or what 'Cloud mode' implies, so it remains mid-tier for a tool with zero structured 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?

Two sentences, front-loaded with the core purpose and followed by the failure-path instruction; nothing is padded. The colloquial 'as whom' and the parenthetical fallback URL are slightly loose but not wasteful.

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?

There is no output schema, so the description must carry the return-value semantics, and it does so only at a high level ('whether connected, as whom, and its state'). It never names the response fields, the connect-link field, or what 'Cloud mode' distinguishes, leaving an agent to inspect the raw response to act on 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 there is nothing for the description to disambiguate. Baseline 4 applies; no syntax, defaults, or formats need explaining.

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 this is a status-check tool that reports whether the LinkedIn account is connected, the identity behind it, and its state. It is trivially distinguishable from the data-fetching siblings (get_profile, search_jobs, etc.), none of which report connection status. It is phrased as a returned fact rather than an explicit verb+resource, which keeps it just 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?

It gives an actionable branch for a negative result ('if not connected or expired, give the user the connect link'), which is useful handling guidance. However, it never says when an agent should call this tool (e.g., as a precondition before other LinkFetch calls), so usage is only implied rather than stated.

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 behavioral burden. It usefully discloses the Cloud-mode/authentication prerequisite, but says nothing about pagination behavior, result ordering, rate limits, or the fact that the call is read-only.

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

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

A single tight sentence with the resource front-loaded and the prerequisite in a parenthetical. No waste, though it is arguably under-specified rather than genuinely 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?

There is no output schema and no annotations, and the description does not say what a conversation record contains or how cursoring works. It is adequate for selection but thin for confident invocation of a paginated, multi-category listing tool.

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 only 33% (just next_cursor is documented), so the description must compensate and does not. It never mentions count (max 50), the category enum with its inbox/spam/inmail variants, or default paging semantics.

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 gives a specific verb and resource: 'List the user's LinkedIn inbox conversations'. It is clearly distinguishable from the sibling linkfetch_read_conversation (list vs. read a single thread), though it does not name 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?

It states a required context ('needs Cloud mode — LinkedIn connected in LinkFetch'), which tells the agent when the tool is callable. However, it gives no guidance on when to prefer this over linkfetch_read_conversation or what to do when the prerequisite is unmet.

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 partially discharges it by disclosing the Cloud-mode requirement for the URN input form. It says nothing about read-only/rate-limit behavior, whether messages come newest-first, or how results relate to the `before` cursor's paging direction.

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 zero padding; the core action is front-loaded and the two accepted identifier forms plus the mode caveat are packed into one line.

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 tool with no output schema and no annotations, the description covers the input contract adequately but leaves the return shape (individual messages, ordering, cursor behavior) and the thread-id vs URN trade-off largely for the agent to assume.

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 documents both `thread` and `before` with formats and semantics. The description adds only the Cloud-mode caveat for URNs, which is real but marginal added meaning.

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: read messages in one LinkedIn conversation, plus the accepted identifier formats (`2-…` thread id or full URN). It is distinguishable from linkfetch_list_conversations by the word 'one', but it never names that sibling or states the relationship 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 infers this is the follow-up to listing conversations, but no when-to-use or when-not-to-use guidance is given. The one concrete constraint offered is that the URN form requires Cloud mode, which is a genuine prerequisite but not a 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?

With no annotations, the description carries the full burden, and it does disclose the informational, reference nature of the tool (published limits plus the reasoning behind them) which implies a non-mutating read. It never explicitly states that it is side-effect free or whether the values are static documentation versus live account state. For a zero-parameter reference tool the residual risk is low, hence 4 rather than 3.

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 sentences with zero padding. The content summary is front-loaded and the usage instruction follows immediately; every clause (limits, rules, rationales) earns its place by telling the agent what the response holds.

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?

There is no output schema, so the description must describe the return content, and it does so concretely (numeric limits with examples, behaviour rules, and per-rule rationale). It omits any indication of response shape or whether limits are global or per-account, which is the only shortfall for a no-parameter tool.

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 defines zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies: no parameter semantics are needed and none are missing.

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 concrete resource (the published LinkedIn safety limits LinkFetch enforces) and enumerates what it contains: numeric limits, behaviour rules (working hours, spacing, warm-up), and their rationales. An agent knows exactly what comes back. It does not, however, differentiate itself from the closely named siblings linkfetch_safety_status and linkfetch_safety_resume, which is the one gap.

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 a clear triggering condition: 'Use it to explain a safety_limit error to the user.' That is a real usage context, not an implied one. It stops short of naming the alternative tools (safety_status, safety_resume) or stating when not to use it, so it lands below the explicit when/when-not bar.

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 behavioral burden and does well: it names the trigger error (challenge_unresolved), the user-confirmation precondition, and a rate/pause constraint. It doesn't state what the call mutates or returns, but the operational warnings are meaningful.

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

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

Three short sentences, front-loaded with the action and trigger, then the precondition, then the constraint. No waste.

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 resume tool with no output schema and full schema coverage, the description supplies the trigger, precondition, and lingering pause constraint needed to invoke correctly. Minor gap: no indication of what success looks like or side effects.

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 a single self-documented account_urn parameter, so the schema does the heavy lifting. The description adds no syntax or format detail beyond it, making the baseline 3 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?

States a specific action (confirm/resume the safety flow) and the triggering condition (challenge_unresolved error), distinguishing it from generic siblings like safety_status and safety_limits. The verb 'Confirm' vs the name 'resume' is slightly ambiguous but the intent is 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?

Explicit when-to-call guidance: 'Only call after the user says they did it,' plus the constraint that any time-based pause still applies. This tells the agent both the precondition and the continuing restriction, leaving little 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?

No annotations are provided, so the description carries the full burden; it discloses the return contents in detail (per-action used vs. limit, window reset times, tier, warm-up week, LinkedIn-triggered pauses) and implies a non-mutating read. It stops short of stating permission/auth requirements or explicitly labelling itself read-only.

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

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

Two sentences, with the return-content summary front-loaded and the usage trigger second. The first sentence is dense with an enumerated list but every element is informative rather than filler.

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 no output schema and no annotations, the description does the necessary work of enumerating what comes back and when to call it. It is nearly complete for a read-only status tool; only the absence of any auth/permission note leaves a small 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?

The single account_urn parameter is fully documented in the schema (100% coverage), including the omit-to-list-all behavior, so the description adds no meaning beyond it. Baseline 3 is correct when the schema does 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?

States a specific verb+resource ('Show how much of the user's LinkedIn safety budget is used') and enumerates the tracked actions, so the agent knows exactly what this returns. It does not explicitly contrast itself with the nearby siblings linkfetch_safety_limits and linkfetch_safety_resume, which is the only thing keeping it from 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?

Gives an explicit usage trigger: 'Call before planning bulk outreach so you can tell the user what fits today.' That is clear context for when to reach for it, but it names no alternatives and states no when-not condition (e.g., how it differs from safety_limits).

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 and does well: it discloses cache-first behavior, live fallback execution on the user's account, safety-limit enforcement, and the specific error states. It omits rate-limit specifics and result/pagination behavior, but the disclosure of prerequisites and failure modes is substantial.

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 tightly packed sentences with the core purpose front-loaded and the routing/fallback behavior immediately after. Every clause carries information; nothing is redundant.

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 search tool with no output schema, it covers the essential context: what it searches, the cache-vs-live execution path, and the failure modes. It stops short of describing the return payload shape and pagination semantics, but an agent has enough to call 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 description coverage is 100%, so the schema already documents q, limit, and offset. The description adds no parameter-level 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?

Specific verb+resource ('Search LinkedIn companies by keyword') with a concrete analogy to the LinkedIn search bar. It is clearly distinguishable from siblings like search_people, search_jobs, and get_company.

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?

Explains the cache-first flow and the conditions under which it runs live (LinkedIn connected, Cloud mode, within safety limits) versus returning linkedin_not_connected / extension_required. It gives clear operational context but does not explicitly name alternatives or when-not to use it (e.g., vs. get_company).

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 behavioral burden. It discloses key operational traits: cache-first lookup, live execution on the user's account in Cloud mode, safety limits, and specific error codes (linkedin_not_connected, extension_required). This is valuable operational context beyond a bare 'search' statement. It doesn't cover rate-limit specifics or result-freshness guarantees, but for a read/search tool this is solid transparency.

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 dense sentence front-loads the purpose and adds operational context via a semicolon. Every clause earns its place without 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?

Covers purpose, caching behavior, authentication precondition, and failure modes, which is complete enough for an agent to call correctly. It stops short of describing pagination semantics or result-shape expectations, but the absence of an output schema and the concise error-code disclosure leave it well-aligned with the tool's scope.

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 explains that 'q' maps to keywords, but adds no syntax, query-language, or pagination interplay details beyond what the schema provides for limit and offset.

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 (Search) and resource (LinkedIn groups) with the target domain clearly identified. The analogy to 'the LinkedIn search bar' makes the retrieval semantics immediately intelligible. It is distinguishable from siblings like search_people, search_companies, and search_posts by the explicit 'groups' resource.

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?

Provides clear contextual guidance on cache-first behavior and live fetch fallback, which tells the agent when a result is fresh vs. cached. It doesn't explicitly name alternative tools or state exclusions (e.g., when to prefer search_posts over groups), leaving some routing inference to the agent.

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 and does disclose meaningful behavior: the non-obvious constraint that at least one filter must be supplied (the schema declares zero required params, so this cannot be inferred), plus paginated compact summaries. It omits auth expectations and rate-limit behavior, which sibling safety tools hint are relevant here.

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 sentences, no filler, and the capability summary is front-loaded before the two operational constraints. Nothing could be removed without losing 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 an 18-parameter search with no output schema and no annotations, the description covers the required-filter rule, the return shape (paginated compact summaries) and the geo-resolution dependency. Remaining gaps are auth and rate-limit context, which adjacent safety tools appear to own.

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 each of the 18 params carries its own description, so the baseline is 3. The description's filter list and geo_id-precedence note largely restate what the schema already documents for geo_id and location.

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 job postings') and enumerates the exact filter dimensions available, making it immediately distinguishable from read-one siblings like linkfetch_get_job, linkfetch_get_job_by_url and linkfetch_get_job_applicants.

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 two concrete operating rules: 'At least one filter is required' and the routing advice to resolve geo via linkfetch_search_locations or fall back to free-text location. It stops short of naming when to use this tool versus the get_job siblings, but the search-vs-fetch split is self-evident from the resource 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, so the description carries the full burden and largely meets it: it discloses the cache policy ('per-query cached globally for a week'), the implied cheapness/no-auth nature of a public typeahead call, and the upstream data source. It omits failure behavior (no-match cases) and any rate-limit or safety-tool interaction, which matters given the linkfetch_safety_* siblings.

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, each earning its place: identity/mechanism, routing guidance, then cost. Front-loaded with the core action and free of filler.

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 no output schema, the description does state what is returned (Bing Geo IDs) and that results come from LinkedIn's typeahead, but it doesn't hint at result shape (multiple candidate matches, display names) an agent would need to pick among them. Adequate for a simple 3-param lookup but not exhaustive.

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 all three parameters (q, fresh, limit) are already fully documented, including the 'rarely needed' guidance on fresh. The description's cache remark loosely motivates fresh but adds no syntax or format detail beyond the schema. Baseline 3 is correct.

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+resource ('Resolve a free-text place name to Microsoft Bing Geo IDs'), names the exact mechanism (LinkedIn's public typeahead), and distinguishes itself from siblings by naming the downstream tool linkfetch_search_jobs. An agent can tell immediately what this does and what it produces.

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 sequencing guidance: 'Call this first when you need a precise geo_id for linkfetch_search_jobs.' It names the condition that triggers use and the consumer of the output, so an agent knows both when to call it and why. No ambiguity about the prerequisite relationship.

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 behavioral burden and does well: it discloses cache-first lookup, live account execution in Cloud mode, safety limits, and the linkedin_not_connected / extension_required error outcomes. It omits return-shape details and leaves 'safety limits' unquantified.

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 sentences, both front-loaded and dense with useful information. No filler or redundancy; the scoping and fallback behavior are stated before the error cases.

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 tool with moderately complex cache/live/auth behavior, 100% parameter coverage, and no output schema, the description covers the behavioral essentials well. The main gap is that it does not describe the response shape, which the absent output schema would otherwise require.

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 only 'by keyword' (mapping to q) and provides no syntax, format, or exclusion details for q, limit, or offset beyond what the schema already documents.

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+resource ('Search LinkedIn people by keyword') and distinguishes itself from siblings like search_companies, search_jobs, and get_profile. The 'like the LinkedIn search bar' analogy makes the retrieval model 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?

Gives clear operational context and prerequisites: cache-first behavior, live fallback only in Cloud mode, and specific error responses otherwise. It does not name alternative sibling tools or explicitly say when not to use it, so it falls short of the top score.

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 and does well: it discloses cache-first behavior, the live-on-account fallback gated on Cloud mode, 'within safety limits', and the concrete failure tokens linkedin_not_connected / extension_required. It omits rate-limit specifics, but the safety-limit reference and error codes are meaningful 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?

Two sentences, purpose front-loaded before the caching/auth mechanics, with no filler. It is dense but every clause earns its place; only minor room to tighten the conditional clause.

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 search tool with no output schema and no annotations, the description covers the important non-obvious behavior: caching, account-scoped live fallback, safety limits, and failure modes. Result shape is left unstated, but the schema and absence of an output schema make that 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%, so all three parameters are already documented with types, defaults, and bounds. The description only echoes the keyword ('q') intent and adds nothing about the limit/offset paging semantics, so the schema does the heavy lifting and 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 (Search) and resource (LinkedIn posts) with the retrieval dimension (by keyword), and the 'like the LinkedIn search bar' analogy pins the scope. It is clearly distinguishable from siblings like linkfetch_search_people, linkfetch_search_companies, and linkfetch_get_profile_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?

The description explains the cache-first resolution flow and the Cloud-mode fallback conditions, which implicitly tells the agent when a call will succeed. However, it never routes the agent between alternatives, e.g. linkfetch_get_profile_posts or linkfetch_get_company_posts for author-scoped posts, leaving sibling selection to inference.

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