what2post

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

Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context beyond listing with optional filtering. No mention of side effects or auth needs.

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 concise sentences with no redundancy. It effectively conveys the core function, though a bit more detail could fit without losing 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?

Given the simplicity (2 params, output schema exists), the description covers the essential purpose and optional filter. It does not need to detail return values due to 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?

With 0% schema description coverage, the description partially compensates by mentioning optional status filtering and giving examples ('active, completed'). However, the 'limit' parameter is not explained, leaving ambiguity.

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

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

The description clearly states the tool lists growth goals with progress, using a specific verb and resource. It distinguishes itself from siblings like get_my_growth and list_my_posts by focusing on goals.

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

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

No guidance on when to use this tool versus alternatives. It does not mention exclusions or prerequisites, leaving the agent without decision-making context.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=false, so the description's contribution is moderate. It adds that the tool returns 'follower-growth statistics' over a time period, which is consistent but does not elaborate on other behavioral aspects like rate limits or data freshness.

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

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

The description is a single, concise sentence that efficiently communicates the core functionality. No redundant information or fluff.

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

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

The description covers the basic purpose and parameter defaults but lacks detail on the return format or what constitutes 'follower-growth statistics'. With no output schema, more specificity would improve completeness.

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 0%, so the description carries the burden. It clarifies that days_back specifies the time period and profile_id defaults to the primary profile when omitted. However, it does not explain the meaning of the values or how they affect the output, leaving some ambiguity.

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 it retrieves follower-growth statistics for a LinkedIn profile over a specified time period. The verb 'get' and resource 'follower-growth statistics' are specific, and the purpose is distinct from siblings like get_my_goals or list_my_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 provides some guidance by noting the default behavior for profile_id but does not explicitly state when to use this tool versus alternatives like get_my_profile_stats. No exclusion criteria or prerequisites are mentioned.

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

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

Annotations confirm readOnlyHint=true and openWorldHint=false, which the description does not contradict. The description adds behavioral context: subscription requirement and default profile behavior. It does not mention potential rate limits or pagination, but given annotations cover safety, the added value is 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 two concise sentences with no extraneous words. Information is front-loaded and 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?

While the description covers purpose and key constraints, it lacks detail on return content (what specific engagement stats or recent posts) and no output schema exists to fill this gap. For a tool with a single parameter and no nested objects, this is a noticeable 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 coverage is 0%, so the description must compensate. It explains profile_id is optional and defaults to primary profile, but does not clarify the format or how to find the ID. This is adequate for a single optional parameter but minimal.

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

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

The description clearly states the tool retrieves 'engagement statistics and recent posts' for LinkedIn profiles, distinguishing it from siblings like get_my_goals (goals) and list_my_posts (only posts). The defaulting behavior to primary profile is also specified.

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 indicates when to use the tool (for profile stats) and provides useful context (defaults to primary profile, requires subscription). However, it does not explicitly compare with siblings or state when not to use it.

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

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

Annotations already provide readOnlyHint=true, so the description does not need to reiterate read-only behavior. It adds value by stating the ordering ('newest first'), the synced nature of posts, and the subscription requirement. No contradictions with annotations.

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

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

Two sentences, front-loaded with the main action. Every sentence adds critical information: first sentence states the purpose and ordering, second sentence covers scoping and a requirement. No wasted words.

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

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

Given the presence of an output schema (not shown but indicated), the description does not need to cover return values. It sufficiently describes the functionality, scoping, ordering, and subscription requirement. The tool is simple (2 parameters, 0 required), and the description covers the essential behavioral aspects.

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 explains profile_id scoping but does not mention limit (default 50). Limit is a common parameter and its purpose is partially implied by 'newest first', but explicit detail is missing. The description adds some value but not full coverage.

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

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

The description clearly states the action ('List your synced LinkedIn posts'), the resource ('synced LinkedIn posts'), ordering ('newest first'), and scoping behavior ('Scoped to one profile...otherwise all your profiles'). This distinguishes it from siblings like get_my_goals, get_my_growth, and get_my_profile_stats.

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 explicitly mentions a prerequisite ('Requires an active subscription') and explains when to use the profile_id parameter. However, it does not provide explicit when-not-to-use guidance or alternatives, though these are not necessary given the clear sibling differentiation.

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