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 usefully names the required OAuth scope ('w_member_social'), but says nothing about the fact that this creates publicly visible content, whether duplicate comments are allowed, rate limits, or failure behavior for an invalid URN.

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 one-line purpose, then scope, then a clean arg list. Slightly redundant that the args list restates parameter names already in the schema, but every line is short and earns its place for an undocumented 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 4-parameter mutation tool with no annotations and no output schema, the description covers the auth scope and all parameters, which is the essential core. It stops short of return value, error semantics, and visibility consequences, so an agent knows how to call it but not fully what to expect.

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 0%, so the description must compensate, and it does: all four parameters are explained with meaning ('Who is commenting', 'The post URN being commented on', 'The comment body', 'If replying to a comment'). It even gives a format exemplar (`urn:li:person:...`), though it omits that parent_comment_urn defaults to null.

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 pair ('Comment on a post') and adds a second distinct mode ('reply to a comment'), which an agent can immediately distinguish from siblings like linkedin_create_post or linkedin_reshare_post. The scope line and arg list reinforce exactly what the tool operates on.

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, no exclusions, and no named alternative (e.g. when to comment vs reshare vs post). The only routing hint is the conditional phrase 'If replying to a comment' for parent_comment_urn, which is parameter-level, not tool-selection-level.

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, and it delivers real behavioral traits: poll content is immutable after creation, and content must comply with LinkedIn policy. It omits auth/permission requirements and any rate or return-value behavior, keeping it short of a 5.

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, then immediately the two most important warnings, then a compact args list. The args list duplicates schema keys, but with 0% schema coverage that duplication 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?

For a mutation tool with no annotations and no output schema, the description covers immutability and policy limits but leaves 'visibility' undocumented and says nothing about permissions or what a successful call returns. Adequate, but with clear gaps.

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 0%, so the description must compensate, and it documents four of five parameters with meaning ('question' is used as post commentary, 'options' must be 2–4, allowed 'duration' values). It omits the 'visibility' parameter entirely, which is the remaining gap.

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 ('Create a poll post') plus a distinguishing constraint ('2–4 options'), which separates it from the generic linkedin_create_post sibling. It does not explicitly name an alternative, so it is clear but not fully sibling-differentiating.

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 content-policy constraints ('Do not ask for political opinions, health status, or other sensitive data'), which is a 'when-not' rule of sorts. However, it never says when to choose this tool over linkedin_create_post, nor any prerequisites, so usage 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 burden, and it does well: it discloses the media-type mutual exclusion, the upload-first prerequisite chain, and the non-obvious coercion that an empty commentary becomes a single space. What it does not disclose is the return value (post URN?), any permission/auth requirements for posting to an organization page, or error behavior on conflicting URNs.

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 one-line purpose followed by a scannable per-media bullet list; each bullet carries distinct routing information. The trailing 'Args:' block partially restates the bullets and the schema, adding some redundancy, but it is short and still load-bearing for the URN formats.

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 12-parameter, no-annotation, no-output-schema mutation tool, the description covers every media path, the required parameters, and cross-tool prerequisites. The remaining gap is the response contract and failure modes, which is modest given no output schema exists to defer to.

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 0%, so the description must compensate, and it documents author_urn (with person vs organization URN form), commentary, visibility values, all media URNs, alt-text ordering, and article title/description. It leaves video_title and document_title unexplained, but those are self-evident given their sibling fields.

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 ('Create a LinkedIn post') and immediately enumerates the six supported post shapes, so an agent knows exactly what this tool produces versus siblings like linkedin_reshare_post or linkedin_create_poll. The per-media routing rules make it distinguishable from the upload tools it depends on.

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 states the mutual-exclusion rule ('pick ONE media type per call') and gives a when-to-use path per media type, including the required ordering with linkedin_upload_image, linkedin_upload_video, and linkedin_upload_document. It even notes which paths need no upload (article/link), which is exactly the kind of routing guidance most definitions omit.

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 it says almost nothing. It does not disclose that the operation is destructive and irreversible, what permissions/ownership are required, or what happens on failure (e.g., post not found). 'Delete' implies mutation but no safety context is provided.

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?

It is short and front-loaded, but the Args block is pure boilerplate that repeats the schema without adding information. Brevity here reflects under-specification rather than earned 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 destructive mutation with no annotations, no output schema, and 0% schema coverage, the definition is inadequate: no confirmation semantics, no error conditions, no ownership/permission prerequisites are described.

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 0% and there is one required parameter. The description only restates the parameter name ('post_urn: The post URN to delete'), adding essentially nothing about the expected URN format (e.g., 'urn:li:share:...') or where to obtain 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 states a specific verb+resource ('Delete a post'), which is clear. However, it does nothing to distinguish itself from the sibling linkedin_update_post, which could plausibly be confused with delete for an agent managing post 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?

There is no guidance on when to use delete versus update, nor any mention that deletion is typically irreversible or requires the post to belong to the authenticated user. The agent must infer all of this.

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 discloses the return contents (name, email, picture, locale, person URN) and the key cross-tool behavioral fact that the URN is required as author_urn elsewhere. It does not mention token/permission prerequisites or rate limits, which is a minor remaining gap for a read-only profile 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?

Three short sentences, front-loaded with the action, then the return payload, then the imperative next step. The em-dash emphasis on the URN prioritizes correctly and no sentence is 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?

No output schema exists, so the description must describe returns, and it does. Combined with the zero-parameter schema and the explicit reuse instruction, an agent has everything needed to call it and use the result.

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 and the baseline is 4. No parameter information is 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?

States a specific verb+resource (get the authenticated member's LinkedIn profile) and enumerates the returned fields. It is unambiguously the read/bootstrapping tool among a sibling set that is otherwise all write operations (create_post, upload_*, delete_post).

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 instructs ordering ('Call this first and reuse the URN') and explains the reason: the person URN is the author_urn required by all post-creation tools. That is a concrete when-to-use rule tied to the sibling set, not inferred 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?

No annotations are provided, so the description carries the full burden. It discloses only that commentary is optional; it says nothing about the fact that a reshare creates a new feed item, whether it requires prior access to the source post, or the fact that visibility defaults to PUBLIC. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

One-line summary followed by a compact Args list; nothing is padded or redundant. The purpose statement is front-loaded ahead of the parameter details, making it easy to scan.

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 four parameters, no annotations, and no output schema, the description should cover the safety and visibility profile, yet the visibility default (PUBLIC) and the resulting publishing behavior are never stated. An agent could reshare publicly by accident. Coverage of URN formats is good but the tool's side effects remain underspecified.

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 0%, so the description must compensate, and it documents three of four parameters — including a genuinely useful format hint for reshared_post_urn (urn:li:share:... or urn:li:ugcPost:...). However, the visibility parameter, which has an enum and defaults to PUBLIC, is never mentioned, leaving a behaviorally consequential parameter undocumented in both schema and description.

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: 'Reshare an existing post', which is distinct from siblings like linkedin_create_post (new post) and linkedin_update_post (edit existing). The optional-commentary clause clarifies the operation's shape without needing to open a sibling. It does not explicitly name a sibling it is not, 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?

There is no statement of when to reshare versus creating a new post or commenting, no prerequisites, and no named alternatives among the many sibling tools (create_post, comment, update_post). Only the incidental 'optionally with your own commentary' hints at usage. Guidance is largely absent.

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 does disclose a genuinely useful behavioral trait — that the update is a partial update limited to commentary — but says nothing about permissions/auth requirements, error behavior, or reversibility for a mutation 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?

Front-loads the core action, follows with the key constraint, then an Args block. Every sentence adds information; the only mild redundancy is restating 'commentary (text)' in the args.

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 2-param mutation tool with no annotations and no output schema, the description covers the action, its scope limitation, and both parameters with format hints. Missing permission and failure-mode detail, but otherwise adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It documents both parameters and, notably, gives the accepted URN formats (urn:li:share / urn:li:ugcPost) for post_urn, which the schema does not, plus clarifies commentary is the 'new post text'.

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 ('Edit an existing post's commentary') and immediately bounds the scope by naming what cannot be changed (author, media, poll). This clearly separates it from siblings like linkedin_create_post and linkedin_delete_post without needing 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?

The description gives clear context for use: editing the text of an existing post. It also negates other edits ('author, media, and poll content cannot be changed'), but does not explicitly name alternative tools (e.g. delete vs create) or state when this tool should not be invoked at all.

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 usefully discloses the return value (a urn:li:document URN) and the downstream consumption path. It says nothing about permissions/auth needed for the author URN, file size or type limits, idempotency, or failure modes of the upload, which are material for a network-bound mutation.

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 purpose and workflow value are front-loaded in the first two sentences, with parameters listed afterward in a compact Args block. Reasonably tight, though the Args block slightly restates the schema's property names.

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 upload with no output schema, the description covers the essential loop: what to pass, what comes back, and where the result is used next. It omits file constraints and auth requirements, which is the main remaining 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 0%, so the description must compensate, and it only partially does: file_path is enriched with 'absolute path' and 'PDF', but author_urn is described tautologically as 'The owner URN' without stating the expected URN form (person vs. organization).

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 ('Upload a local document (e.g. PDF)') plus the output ('return its document URN'), which cleanly separates it from linkedin_upload_video and linkedin_upload_image. An agent can tell what this tool does 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?

It gives clear context: the returned URN is referenced via document_urn on linkedin_create_post to publish a document/carousel post, so the agent knows this is a preparatory step in a specific workflow. However, it names no exclusions or alternate paths (e.g. what to do for images/videos), so it falls short of explicit when-not guidance.

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

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 value semantics, which is useful, but says nothing about auth/permission requirements, file size limits, or failure behavior for a network upload. Adequate but thin given zero annotation coverage.

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

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

Front-loaded one-line purpose followed by the chaining instruction and an Args block. No filler sentences; every line 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?

With no output schema, the description correctly explains the returned URN and how to consume it, and it documents both required parameters despite 0% schema coverage. Missing only peripheral details like size limits and auth, which don't block correct 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 description coverage is 0%, so the description must compensate and it mostly does: author_urn is explained as the owner URN with both 'urn:li:person:...' and 'urn:li:organization:...' forms, and file_path is specified as an absolute local path restricted to PNG/JPG/GIF. Only the size/format constraints are left implicit.

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 ('Upload a local image file') and the output ('return its image URN'), which cleanly separates it from the upload_video and upload_document siblings. An agent can identify the tool 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?

The description gives a clear downstream contract: pass the returned 'urn:li:image:...' into linkedin_create_post as one of 'image_urns', and encodes the cardinality rule (1 = single-image post, 2-20 = multi-image). It does not explicitly say when to prefer this over upload_video/upload_document, but the sibling names make the selection obvious.

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 one important trait: processing is asynchronous and a post may not go live immediately. It omits auth/permission requirements, file size or duration limits, and any rate-limit or overwrite behavior, so the disclosure is partial.

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 action and return value, followed by a useful async caveat and a clean Args block. No wasted sentences, though the Args section largely restates short schema titles.

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 2-param mutation with no annotations and no output schema, the description helpfully names the returned URN and the async behavior, but it leaves auth requirements and success/failure conditions unstated. Adequate but with clear gaps.

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 0%, so the description must compensate; it adds format detail ('absolute path to a local video (MP4)') for file_path, but author_urn is explained only as 'The owner URN', which is barely more than the schema. It adds meaning for one parameter and not the other.

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 ('Upload a local video file') plus the return artifact ('video URN'), which is enough for an agent to pick it over unrelated siblings. It does not, however, explicitly distinguish itself from linkedin_upload_image or linkedin_upload_document beyond the word 'video'.

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: the async note suggests uploading here before referencing the video in a post, but the description never names a when-to-use condition or an alternative tool. An agent must infer the pipeline from sibling names.

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