Socify-mcp

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 two useful operational facts: a cost of 1 credit and the Authorization: Bearer <api_key> requirement. It adds pagination and author-identity context, but says nothing about rate limits, private/deleted media behavior, or error handling.

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 core clause is front-loaded and short, but there is a doubled period typo ('pagination..') and the boilerplate 'Platform=instagram resource=comments' restates the tool name, adding length without 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 usefully summarizes the return content (author identity) and pagination behavior, plus cost and auth. For a three-parameter read tool this is nearly complete, with only error and edge-case behavior left uncovered.

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 media_id, cursor, and sorting including defaults and examples. The description only gestures at pagination ('cursor') and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description states a specific verb and resource: fetching public comments for a media id, including author identity and pagination. It is clear what the tool returns, though it never names how it differs from sibling endpoints like instagram_post or instagram_detailed.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer from the tool name alone that this is the comments endpoint rather than the post or user endpoint, which is thin routing guidance in a 40-sibling namespace.

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 does disclose two operationally important facts — a 10-credit cost and the required Authorization: Bearer <api_key> header — plus that only public profiles are fetched. It says nothing about behavior for private, suspended, or nonexistent accounts, or about rate limits.

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

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

Three short sentences, front-loaded with the core purpose and fields, with cost and auth trailing appropriately. Minor sloppiness: a doubled period after 'media..' and boilerplate 'Platform=instagram resource=detailed' phrasing.

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 usefully enumerates the returned fields, which partly compensates. But for a paid, authenticated call sitting alongside a near-identical sibling, the absence of selection guidance and of error/private-account behavior leaves real 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 coverage is 100% and the single 'username' parameter is documented in the schema as 'Instagram username without @'. The description only restates 'for a username' and adds no format or edge-case semantics beyond what the schema already provides.

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

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

States a specific verb (Fetch) and resource (full public profile for a username) and enumerates the returned fields: bio, follower/following counts, category, business fields, timeline media. However, it never distinguishes itself from the sibling instagram_user, which an agent would plausibly confuse with this 'detailed' variant.

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 is given. With instagram_user, instagram_followers, and instagram_posts all in the sibling set, the agent gets no signal about when this costlier detailed profile is preferable to those alternatives.

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 disclose two concrete traits: it costs 1 credit and requires a Bearer api_key authorization header. That is useful operational context, but it omits rate limits, error behavior, and whether the count reflects only public followers versus something else.

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

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

Purpose is front-loaded in the first clause and the total length is short. There is minor noise (a doubled period after 'user id..') and semi-redundant metadata boilerplate, but no sentence 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?

For a single-parameter read tool with no output schema or annotations, the description covers what it returns (a follower count), the credit cost, and the auth requirement. The absence of sibling differentiation detail is the main residual 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 the sole user_id parameter is already fully documented (numeric Instagram user id sourced from User Info / Detailed Info). The description adds no format, sourcing, or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Fetch the public follower count for a user id'), and the 'resource=followers' tagging along with the name makes it distinguishable from siblings like instagram_user or instagram_detailed. It clearly conveys scope (public follower count) without needing to open 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?

No when-to-use or when-not-to-use guidance is given. The 'Platform=instagram resource=followers' line is metadata restatement, not a routing instruction, and no sibling tool is named as an alternative for related data.

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

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

With no annotations provided, the description does some of the disclosure work: it states the operation is limited to public posts, costs 1 credit, and requires an Authorization: Bearer header. However, it omits error behavior for invalid shortcodes, rate limits, and any mention of pagination or caching.

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 returned fields are front-loaded, and the credit and auth boilerplate is short. It is slightly marred by the stray double period after 'sample..' and dense appended 'Platform=instagram resource=post' metadata, but nothing is meaningfully 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 convey return values, and it does so by listing the main fields returned. Cost and authentication requirements are also covered. Remaining gaps (failure modes, pagination for larger comment samples) are minor for this tool's complexity.

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

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

Schema description coverage is 100%, so both parameters (code, n_comments_to_fetch) are already documented in the schema. The description's reference to a 'shortcode' and a 'small comments sample' only loosely restates that, adding no format or bounds detail beyond the schema's 0-50 range.

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 resource (public post details by shortcode) and enumerates the returned fields (caption, owner, likes, comments count, media URLs). It implicitly distinguishes itself from the plural sibling instagram_posts by operating on a single shortcode, but it never names or contrasts siblings like instagram_detailed, which could also plausibly return post details.

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 only implies usage via the required shortcode; it never states when to call this tool versus instagram_posts, instagram_detailed, or instagram_comments. There are no exclusions, prerequisites, or alternative-naming 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the return payload (captions, media URLs, like/comment counts, cursors), the pricing model (per page, 1 credit per page, defaults to 1 page), and the required Authorization: Bearer header. It omits rate limits, error behavior, and post ordering/recency semantics, 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?

The payload description is front-loaded and useful, but pricing is stated twice ('Priced per page; defaults to 1 page' and 'Costs 1 credit(s)... Credits unit: page'), and a stray double period plus machine-generated metadata fields add noise. It earns its place but is not tight.

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

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

For a read-only fetch tool with no output schema and no annotations, the description covers what an agent needs to call it: resource scope, returned fields, auth, and cost model. Only rate limits and pagination termination behavior are unaddressed.

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 depth, user_id, chunk_size, and start_cursor are already documented with examples and defaults. The description only reinforces the page/credit relationship and pagination cursors, adding little beyond the schema — the baseline 3 for full coverage 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 recent public posts for a user id'), which clearly separates it from a single-post sibling like instagram_post. However, it never names or contrasts with any sibling, leaving the agent to infer the posts-vs-post distinction from the tool names alone.

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 statement, no prerequisites beyond the auth header, and no guidance on choosing between this and instagram_post, instagram_detailed, or instagram_tagged. Usage is only implied by 'for a user id'.

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 per-page pricing (1 credit/page), the required Authorization: Bearer api_key, pagination behavior, and that play metrics are only included 'when available'. It omits rate limits and error/edge behavior, keeping it short of 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-loads the core purpose, but the trailing metadata is repetitive ('Priced per page... Costs 1 credit(s)... Credits unit: page') and includes a stray double period. Some sentences do not earn their place.

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

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

For a fetch tool with no output schema and no annotations, the description covers the key facts an agent needs: what is returned (captions, play metrics), pagination, cost, and auth. It is nearly complete, missing only rate/error details.

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 only restates the depth default ('defaults to 1 page') already documented in the schema and adds no syntax or format meaning beyond 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?

Names a specific verb (Fetch) and resource (recent reels) with scope (for a user id), which distinguishes it from instagram_posts and instagram_post siblings. It does not explicitly contrast itself with those siblings, so it stops short of a 5.

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

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

The description never states when to use this tool versus alternatives, nor any prerequisites or exclusions. Only implicit context (reels-of-a-user) hints at usage; no routing guidance for the many sibling tools is provided.

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

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

With no annotations, the description carries the full burden and does disclose two useful behavioral facts: cost (1 credit) and required auth (Bearer api_key). However, it omits return format and pagination/resumption behavior despite the cursor and chunk_size parameters, leaving notable gaps 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?

Purpose is front-loaded in the first sentence and the description is short. There is some waste: 'Platform=instagram resource=tagged' largely restates the name, and there is a stray double period, but the credit and auth notes earn their place.

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

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

For a read/fetch tool with no output schema and no annotations, the description covers purpose, cost, and auth, which is adequate. It stops short of describing the return shape or pagination behavior, which an agent would need to page results 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 cursor, user_id, and chunk_size are already documented in the schema. The description adds no parameter meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description gives a specific verb (Fetch) and resource (public posts where a user id was tagged), making it distinguishable from instagram_posts (posts authored by a user). It does not name a sibling explicitly, but the 'tagged' qualifier clearly scopes the operation.

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 supplies a use-case hint ('brand mentions and collaboration discovery') but gives no explicit when-to-use/when-not guidance or named alternatives (e.g., instagram_posts for authored content). Usage is implied rather than directed.

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 reasonably well: it discloses the credit cost ('Costs 1 credit(s)') and the auth requirement ('Requires Authorization: Bearer <api_key>'), plus the fact that only public profile identity is returned. It still omits behavior for private, suspended, or nonexistent accounts and any error/rate-limit semantics, which keeps it short of 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 and payload, then boilerplate (Platform/Resource, cost, auth) that is genuinely useful rather than filler. Minor blemish: a stray double period in 'metadata..' and the templated 'Platform=instagram resource=user' is low-value relative to the rest.

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 correctly enumerates the return fields, and with no annotations it supplies the cost and auth context an agent needs before calling. It is close to complete for a single-parameter lookup; only failure-mode behavior for inaccessible accounts 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?

There is one parameter with 100% schema description coverage, and the schema already explains 'Instagram username without @.' The description only restates 'for an Instagram username' and adds no format, casing, or URL-vs-handle guidance 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?

States a specific verb ('Fetch') and resource ('public profile identity for an Instagram username'), then names the returned fields (username, display name, verification status, profile picture metadata), which is concrete enough for an agent to know what it gets. It does not, however, distinguish itself from close siblings such as instagram_detailed, which presumably also returns profile data — a one-clause differentiation would have made this 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?

Usage is implied by the purpose: call this when you need identity/profile information for a single Instagram username. There is no explicit when-to-use, when-not-to-use, or comparison against the overlapping siblings (instagram_detailed, instagram_followers, tiktok_user, threads_user), so the agent must infer routing.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two genuinely useful traits the schema does not: a cost of 3 credits and a required Bearer api_key Authorization header, plus the fact that only public pages are fetched. It stops short of error behavior, rate limits, or what happens on invalid/private URLs.

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

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

Purpose is front-loaded and the whole thing is short with no padding. A stray double period ('followers..') is a minor cosmetic flaw rather than a structural problem.

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 public fetch with no output schema and no annotations, the description covers the return payload, cost, and auth, which is most of what an agent needs. Only edge-case behavior (invalid URL, private page) is unaddressed.

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% for the single url parameter, including an example, so the schema does the documentation work. The description only restates 'by URL' and adds no format or syntax nuance. 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) plus the resource (public LinkedIn company page) and enumerates the returned data (about, size, industry, followers). The 'company' resource clearly separates it from siblings linkedin_job and linkedin_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 never says when to use this versus linkedin_job or linkedin_post, nor any precondition beyond the URL requirement. The 'Platform=linkedin resource=company' line is metadata, not usage 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 does disclose useful operational facts — a cost of 5 credits and the required Authorization: Bearer header — which go beyond the schema. It omits pagination behavior, result volume limits, and rate/error handling, leaving real gaps for a read 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?

Purpose is front-loaded in the first clause and the boilerplate (platform, resource, cost, auth) is compact. Minor blemishes: a doubled period after 'metadata' and template-style key=value phrasing that reads as generated 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 usefully names the return fields, and it covers the two operational essentials (cost, auth). For a single-parameter read tool that is close to sufficient; only pagination/limit behavior is unaddressed.

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

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

Schema description coverage is 100% with a single 'url' parameter already documented and exemplified in the schema. The description adds no syntax or format detail beyond that, so the schema does the work and baseline 3 applies.

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

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

States a specific verb and resource ('Discover recent public posts from a LinkedIn company page URL') plus the returned fields (text, engagement, author metadata). An agent can distinguish it from linkedin_post (single post) and linkedin_company (profile) by the resource noun, though no sibling is named 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?

The description says what it returns but never states when to choose it over linkedin_post, linkedin_company, or linkedin_job, nor any prerequisites beyond auth. The only implicit guidance is the word 'public', which hints at scope but is not framed as a usage 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 behavioral burden. To its credit it discloses pricing ('Costs 2 credit(s)') and an auth requirement ('Requires Authorization: Bearer <api_key>'), plus that it targets public postings. It stops short of describing error behavior, rate limits, or return shape, leaving meaningful gaps for an unannotationed 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?

Purpose is front-loaded in the first clause and the whole definition is short. Minor waste remains: the 'Platform=linkedin resource=job' fragment is redundant metadata and there is a stray double period after 'summary', but these do not impede comprehension.

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 covers purpose, returned fields, cost, and auth adequately. A brief note on failure modes (invalid/private URL) would make it fully complete, but nothing essential to correct invocation is missing.

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

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

Only one parameter exists and schema coverage is 100%, so the schema already fully documents the url field (including an example). The description adds nothing about URL format beyond what the schema provides, 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 (Fetch) plus resource (public LinkedIn job posting) and enumerates the returned fields (title, company, location, summary). This clearly distinguishes it from sibling tools like linkedin_company and linkedin_post, so an agent can select it without opening either schema.

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

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

Usage is implied by the URL-based fetch pattern, but there is no explicit when-to-use guidance, no exclusions, and no comparison to the LinkedIn siblings (company/post). The agent must infer that this is the tool for individual job URLs.

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 does disclose two important operational facts an agent needs: a 2-credit cost and the required 'Authorization: Bearer <api_key>' header. It omits error/edge-case behavior (private, deleted, or rate-limited requests) which matters for a paid external fetch.

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 core sentence is front-loaded and efficient, but the appended boilerplate 'Platform=linkedin resource=post.' is redundant with the tool name and adds no value, and there is a stray double period ('metadata..'). It is short but not maximally economical.

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 usefully enumerates the returned fields (text, likes, comments, author metadata), so an agent knows what to expect. Auth and cost are covered; the remaining gap is edge-case handling for non-public or invalid URLs.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents 'url' with an example. The description adds only the phrase 'by URL', which restates the schema rather than extending it. 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 (Fetch) and resource (public LinkedIn post by URL) and enumerates the payload (text, likes, comments, author metadata). The resource ('post') is distinct from the LinkedIn siblings linkedin_company and linkedin_job, though no alternative is named 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?

'Fetch a public LinkedIn post by URL' implies the usage context and quietly signals the public-post limitation. There is no explicit when-to-use guidance, no statement about private/deleted posts, and no routing to alternative tools for feed or company data.

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 usefully discloses the cost (3 credits) and the auth requirement (Bearer token), which is genuine behavioral context beyond structured fields, but it omits rate limits, error behavior, and pagination.

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 purpose and compact overall. Minor flaws: a double period after 'followers' and a boilerplate 'Platform=linkedin resource=profile' segment that mildly duplicates the tool name.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential elements: what it fetches, the fields returned (compensating for the missing output schema), cost, and auth. It is adequate though it could note prerequisites or failure modes.

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 100% schema description coverage and a single well-exampled 'url' parameter, the schema already documents the input. The description restates URL-based lookup but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (Fetch) and resource (public LinkedIn person profile by URL), and enumerates the fields returned. It implicitly distinguishes from siblings like linkedin_company by scoping to a 'person' profile, though it never names the alternative 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 implied by 'person profile by URL' and the sibling set, but there is no explicit when-to-use/when-not guidance and no mention of linkedin_company or linkedin_post as alternatives for other LinkedIn resource types.

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. It discloses that the output includes required parameters and credit costs, which is meaningful, but it does not say whether the list is static, how large it is, or how to interpret endpoint names.

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

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

Two short sentences with no waste: the object of the listing is front-loaded and the calling condition follows immediately.

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 discovery tool with no output schema, the description is serviceable but does not explain the shape of the returned list or how endpoint names map to sibling tools. An agent knows when to call it but not exactly what it will receive.

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 to document and the baseline is 4. The description correctly implies a parameterless listing call.

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: listing Socify platforms and resources, plus what the listing includes (required parameters and credit costs). The term 'endpoints' is slightly at odds with 'platforms and resources' used elsewhere in the ecosystem, but the intent is still 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 a clear conditional: call this before lookup if unsure which endpoint to use. That routes the agent sensibly among the large sibling set, though other siblings are not named and no explicit when-not condition is given.

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 does the important work itself: it discloses the auth requirement (Bearer API key) and, critically, that calls consume credits — a cost signal an agent can't infer from the schema. It stops short of return shape, credit cost magnitude, rate limits, or error behavior.

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

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

Three short sentences, zero filler, purpose first followed by the two hard constraints (auth, credits) and the prerequisite call. 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?

For a generic dispatcher with a nested free-form params object, no annotations, and no output schema, the description leaves the return shape and the relationship to the per-platform siblings unexplained. The auth/credit/discovery facts are covered, but an agent still has to guess why it would use lookup instead of instagram_user.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: valid platform/resource values and the free-form params keys must be resolved via list_endpoints, and none of the parameters have enums in the schema. That discovery dependency is genuinely useful parameter 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 verb and resource ('Fetch public social data via Socify') are stated, but 'social data' is so broad that it doesn't distinguish this tool from any of its ~40 platform-specific siblings (instagram_user, tiktok_posts, youtube_search). It never says this is the generic/parameterized dispatcher versus the pre-bound per-platform tools, so an agent can't confidently choose it.

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 one concrete workflow rule: call list_endpoints first to discover platform/resource/params. That is real guidance. But there is no statement of when to prefer lookup over the many specific siblings, nor any exclusion, which is the key routing decision for this tool.

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 are absent, so the description carries the full burden. It does disclose two non-obvious operational facts, the 3-credit cost and the required Bearer api_key auth, which is real value beyond the schema. It stops short of describing return shape, pagination, or rate limiting, leaving meaningful gaps for a tool with no 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?

Short, front-loaded, and every clause carries information (action, resource, cost, auth). Minor deductions for the doubled period typo ('permalink..') and for the templated platform/resource tag, which reads as generated boilerplate.

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 read tool, the core call contract (what to pass, auth, cost) is covered. With no output schema, however, the description could reasonably say what comes back or whether results are paginated, and it says nothing about either.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already fully documents the permalink format including an example. 'via its permalink' merely restates the parameter name and adds no syntax or format detail beyond 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 (Fetch) plus resource (comments) and scope (public, for a post via its permalink). The 'Platform=reddit resource=comments' tag cleanly separates it from the platform-mate tools like instagram_comments and youtube_comments in the sibling list.

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 or when-not-to-use guidance, and no named alternative (e.g. reddit_posts for post data vs this for comment threads). The only routing hint — 'Post permalink from Search or Subreddit Posts' — lives in the schema, not the description, and is not referenced here.

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 burden. It does disclose pricing (2 credits per page), auth requirement (Bearer api_key), and billing unit (page) – meaningful operational context beyond the schema. However, it does not state rate limits, return shape, or whether it is read-only, leaving gaps a no-annotation mutation-risky tool would ideally cover.

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

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

Two short sentences front-load the purpose, then append pricing/auth stubs. It is efficient but the trailing 'Platform=reddit resource=posts' metadata is slightly redundant and fragmentary, though not harmful.

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 public read tool with full schema coverage and no output schema, the description covers purpose, cost, and auth, but omits return-value expectations and pagination behavior semantics beyond the cursor field, leaving the agent with a somewhat incomplete picture of the response.

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 clear per-parameter descriptions (name, sort, cursor, period), so the schema already does the heavy lifting. The description adds no parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Fetch posts from a public subreddit') that clearly distinguishes it from reddit_comments and reddit_search among siblings. It is unambiguous what the tool retrieves, though it does not explicitly differentiate itself from the sibling reddit tools.

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

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

The description implies usage (fetching posts from a subreddit) but gives no explicit when-to-use versus alternative guidance, such as when to prefer reddit_search or how it relates to reddit_comments. Usage is inferable from the purpose statement.

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

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

With no annotations provided, the description carries the full behavioral burden and does disclose meaningful operational context: cost of 2 credits per page, the credits unit, and the required 'Authorization: Bearer <api_key>' header. It omits return shape and pagination mechanics, but the cost and auth disclosure is genuinely valuable.

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

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

Front-loaded with the purpose, but the trailing metadata block ('Priced per page.. Platform=reddit resource=search. Costs 2 credit(s)...') is boilerplate-adjacent and contains a doubled period. Each fact is useful, yet the phrasing is clunky rather than tight.

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

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

There is no output schema and no annotations, so the description must cover more. It handles purpose, cost, and auth, but says nothing about pagination behavior (despite the cursor parameter) or what a result page contains. Adequate but with clear gaps for a search 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 description coverage is 100%, so all four parameters (name, sort, cursor, period) are already documented with examples and defaults in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Search public Reddit posts by keyword.' An agent can distinguish it from reddit_comments and reddit_posts by resource scope. It does not explicitly name which sibling to prefer, 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?

No when-to-use or when-not-to-use guidance. Given siblings like reddit_posts and reddit_comments, the description never explains when a keyword search is the right choice versus fetching a subreddit's posts or a post's comments. Usage is only implied by the verb 'Search'.

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 present, the description carries the full disclosure burden, and it does add real operational context: a fixed cost of 3 credits and a Bearer api_key auth requirement. It stops short of describing failure modes (private/nonexistent accounts) or rate limits, but the cost and auth disclosure is genuinely useful.

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

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

Front-loaded with the purpose and returned fields, followed by short operational facts. Slightly marred by a doubled period after 'media' and by template-style fragments ('Platform=snapchat resource=user'), but nothing is verbose.

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 the description compensates by enumerating the returned profile fields, plus it covers auth and credit cost for a simple one-parameter fetch. Enough for an agent to invoke correctly, though error/edge behavior is left unstated.

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

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

Schema description coverage is 100% and the single 'name' parameter is already documented as a Snapchat username without '@'. The description's 'by username' adds nothing beyond the schema, 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?

Specific verb (Fetch) + resource (public Snapchat profile) + scope (by username) + the fields returned (bio, subscribers, profile media). Naming the platform disambiguates it from the near-identical siblings instagram_user, tiktok_user, and threads_user, so an agent can pick 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?

Usage is only implied by the purpose: fetch a Snapchat profile when you have a username. There is no explicit when-to-use, no statement of when this is the wrong choice, and no routing to an alternative such as a generic lookup tool or the platform-specific user endpoints.

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 useful traits: a small batch per call, a 3-credit cost, and the required Authorization bearer token. It omits pagination behavior and whether/how to fetch more results, which matters given the stated small batch size.

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

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

Front-loaded with the purpose, which is good, but the 'Platform=threads resource=keyword' segment merely restates the tool name and consumes space without adding meaning. There is also a stray double period, though the overall length is acceptable.

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 two-parameter search with no output schema, the description covers cost, auth, and result-batch size, which is the core operational context. It is still missing return-field or pagination detail and any differentiation from threads_search, so it is adequate rather than 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%, so both parameters are already documented in the schema (name = keyword, sorting = 0 top / 1 recent). The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the work.

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

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

States a specific verb and resource ('Search public posts by keyword'), so an agent knows exactly what the tool does. However, it does not distinguish itself from the sibling threads_search, which on its face appears to do the same thing, leaving the agent to guess which to call.

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 when-to-use or when-not-to-use guidance and no mention of the obvious alternative threads_search. The agent must infer the distinction 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?

No annotations are provided, so the description carries the full disclosure burden. It does add genuinely useful operational context, the 3-credit cost and the required Bearer auth, but says nothing about how many replies are returned, ordering, or any rate limits, which leaves gaps for a read tool with 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?

Very short and front-loaded with the capability before the cost/auth metadata. Minor friction from the doubled period after 'shortcode' and the tag-style 'Platform=threads resource=post' fragment, but nothing 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?

For a 2-parameter lookup with full schema coverage and no output schema, the description covers what is needed: the target, the alternate key, the cost, and the auth scheme. Only reply-count/pagination detail is absent, which is a minor gap here.

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

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

Schema description coverage is 100%, with both id and shortcode documented in the schema (including the 'any integer if passing shortcode only' rule), so the baseline is 3. The description only restates 'by post id (or shortcode)' and adds no format or syntax 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 (Fetch) plus the resource (a post and its popular replies) and the key lookup (post id or shortcode), so the agent knows exactly what it gets. It never names the list-shaped sibling threads_posts or threads_search, so the boundary with them must be inferred from the name.

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

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

Usage is implied rather than stated: you call it when you already have a post id/shortcode, versus threads_posts or threads_keyword for discovery. There is no explicit when-to-use/when-not or named alternative, so an agent must infer the routing.

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

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

With no annotations present, the description carries the full burden and does disclose meaningful operational facts: per-post pricing, the default of 3 posts, and the required 'Authorization: Bearer <api_key>' header. It still omits rate limits, pagination behavior, and what happens for private/suspended accounts, which keeps it from 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?

The opening sentence is front-loaded and useful, but 'defaults to 3 posts' is duplicated in the schema, and the appended template metadata ('Platform=threads resource=posts... Credits unit: item.') is largely boilerplate. Reasonably tight but with visible redundancy.

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

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

For a simple two-parameter read tool it covers auth, cost, and default count, but with no output schema present the description could say what a returned post looks like or whether results are paginated. The essentials are there; the return shape is not.

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

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

Schema description coverage is 100% and both parameters are documented in-schema (id source, chunk_size range and default). The description adds no syntax or format detail beyond restating the default of 3, 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 and resource ('Fetch recent public posts for a user id'), and the 'public posts for a user id' phrasing clearly separates it from threads_post (single post), threads_user, and threads_keyword. It does not explicitly name those siblings as alternatives, 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?

Usage is only implied: the required user id and the 'recent public posts' scope suggest when to reach for it, but there is no explicit when/when-not guidance and no routing to threads_keyword or threads_post. Adequate but leaves the agent to infer the choice.

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 non-trivial work: it discloses credit costs (4 vs 8), the internal id resolution behavior, the returned fields, and the required Authorization header. It lacks rate-limit or failure-mode detail, but cost and auth disclosure are exactly what annotations would not have 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?

Front-loaded and mostly efficient, but there is redundancy: the 4-credit cost is stated twice (once in the username/id clause, once in 'Costs 4 credit(s)'), plus a stray double period. The 'Platform=threads resource=user' fragment reads as templated 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 or annotations exist, but the description names the fields returned, both input modes, authentication, and cost. For a simple read-only profile fetch this is close to sufficient; only failure/empty-profile behavior is unaddressed.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes beyond the schema by explaining the cost tradeoff between the two params ('username resolves the id internally (8 credits); id alone is 4 credits'), which informs the agent's choice.

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'), a specific resource ('public Threads profile'), and enumerates the fields returned (bio, followers, verification). 'Platform=threads resource=user' plus the field list clearly separates it from threads_post, threads_posts, and threads_keyword siblings.

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 two input modes (username vs numeric id) and their credit difference, which implies when to use each. However, it never states when to prefer this tool over alternatives like instagram_user or tiktok_user, nor any prerequisite context for using a profile lookup.

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

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

With no annotations, the description carries the full burden and does contribute useful operational facts: page size (~30), cost (1 credit per page), and the required Authorization: Bearer header. It stops short of disclosing ordering, whether replies are included, or rate limits, so it is adequate but not rich.

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 key information (page of comments, ~30 per page) is front-loaded, but the tail is a noisy metadata dump with redundancy ('Priced per page..' followed by 'Costs 1 credit(s).') and a stray double period, wasting space on repeated pricing 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?

There is no output schema, so the description should characterize the return payload; it only says 'a page of comments (~30)' without describing comment fields or pagination continuation. For a simple single-entity list endpoint this is minimally sufficient, but not 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% — both aweme_id and cursor are documented in the schema, including that cursor defaults to 0 — so the description adds nothing beyond what the schema already states. Baseline 3 applies.

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

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

The description opens with a specific verb and resource — 'Fetch a page of comments for a post' — and reinforces the scope with 'Platform=tiktok resource=comments', which cleanly separates it from sibling tools like instagram_comments, reddit_comments, and youtube_comments.

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 what the tool does but gives no when-to-use vs when-not guidance and names no alternatives; there is nothing about using cursor to paginate or about how this differs from tiktok_post/tiktok_posts beyond the resource noun.

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 burden. It discloses pagination (~100 per page, cursor-based), cost (1 credit per page), and auth requirement (Bearer token). It doesn't describe rate limits, error behavior, or whether follower data ordering is stable.

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?

Compact and front-loaded: the operation, then requirements, then pricing, then platform/resource, then auth, then credit unit. The trailing metadata is slightly list-like, but every element is useful and there is 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?

Covers operation, input provenance, pagination, cost, auth, and resource tagging for a simple read/list tool with no output schema. Only missing pieces are return shape and error/rate-limit behavior, which are minor for this complexity.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds value by stating where id and sec_uid originate (User Info) and that pricing is per page, reinforcing the cursor's role in pagination beyond the schema's generic 'defaults to 0'.

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 page of followers for a user') with scope (~100 per page) and platform. It clearly distinguishes from siblings like tiktok_following and tiktok_user by naming what it returns.

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?

Specifies that id and sec_uid must come from User Info and that pagination is per page, giving clear prerequisites. It doesn't mention when to prefer this over alternatives like tiktok_following or tiktok_user, but the resource is unambiguous enough.

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 auth requirements ('Requires Authorization: Bearer <api_key>'), cost ('Costs 1 credit(s)'), pricing unit ('Credits unit: page'), and the pagination page size (~100). It lacks detail on error behavior or rate limits, but covers the key operational traits.

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

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

The first sentence front-loads the purpose well, but the description is a stitched-together set of boilerplate lines with redundancy: 'Priced per page..' (double period) and 'Credits unit: page' restate the same pricing fact twice. Several sentences are fragmented and could be consolidated.

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 or annotations exist, so the description must stand alone — and it adequately covers purpose, prerequisites, auth, cost, and page size. Return-field structure is not described, but for a paginated listing tool the operational essentials are present.

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

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

Schema description coverage is 100%, so all three parameters (id, cursor, sec_uid) are already fully documented with examples. The description reinforces the provenance of id and sec_uid ('from User Info') but adds no syntax or format meaning beyond the schema, fitting the baseline.

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

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

States a specific verb and resource — 'Fetch a page of accounts a user follows (~100)' — which is clearly distinguishable from the sibling tiktok_followers (accounts following the user). Scope (~100 per page) is included. It stops short of an explicit sibling callout, but the following/followers distinction is inherent in the wording.

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 prerequisites: 'Needs id and sec_uid from User Info,' routing the agent to the correct upstream tool for parameter acquisition. It does not state when-not to use it or name tiktok_followers as the alternative, so it falls short of full 5-level when/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?

With no annotations, the description must carry the behavioral burden, and it does disclose two concrete traits: a cost of 1 credit and the required Authorization: Bearer <api_key> header. It still omits error behavior, pagination/rate limits, and whether the target must be public, so it is useful 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?

Front-loaded with the purpose in the first clause, then metadata (platform/resource, cost, auth) in compact form. A stray double period ("author..") is a minor cosmetic flaw 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?

For a single-parameter fetch tool with no output schema, the description names the returned data (caption, stats, author), plus cost and auth requirements. It is nearly complete; only failure modes and output structure detail are absent, which is acceptable given the tool's simplicity.

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 url parameter is fully documented in the schema (100% coverage, with an example), so the schema does the heavy lifting. The description adds only that the URL should point to a TikTok video, which is consistent but marginally additive; 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 ("Fetch") and resource (public TikTok video details from a URL) and enumerates the returned fields (caption, stats, author). This clearly separates it from list-oriented siblings like tiktok_posts, though it never names an alternative 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 implied by the phrase "for a TikTok video URL," so the agent can infer this is the single-post fetch tool. However, there is no explicit when-to-use versus tiktok_posts/tiktok_search guidance and no statement of prerequisites beyond the auth line.

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 reasonably well: it discloses page size (~10 posts per page), pricing model (per page, 1 credit, default 1 page), and the required Authorization header. It omits rate limits, what 'recent/public' excludes, and error behavior, but covers the key operational facts.

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 core sentence is front-loaded and efficient, but the trailing block ('Platform=tiktok resource=posts. Costs 1 credit(s). Requires Authorization... Credits unit: page.') is metadata-style duplication of the per-page pricing statement, plus a double-period typo. Mildly cluttered.

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 fetch tool with no output schema, the description covers auth and cost but says nothing about return shape (list of videos plus a nextCursor) even though start_cursor implies pagination. Adequate but leaves the response contract for the agent to guess.

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 depth, username, and start_cursor are already documented in the schema, including the ~10 posts per page detail. The description's '~10 posts per page' and 'defaults to 1 page' merely restate schema content, so baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Fetch recent public videos for a username.' The 'for a username' scoping distinguishes it from siblings like tiktok_search and tiktok_user without naming them explicitly. Clear enough to select, though it never explicitly contrasts with tiktok_post or tiktok_search.

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

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

Usage is implied by the username-based fetch and the disclosed per-page pricing, but there is no explicit when-to-use/when-not guidance versus siblings such as tiktok_search or tiktok_post. An agent must infer the choice from the resource 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?

No annotations are provided, so the description carries the full burden. It does disclose pricing ('Costs 1 credit(s), priced per page'), the auth requirement (Bearer API key), and the credit unit, which is genuinely useful. It doesn't explain rate limits, what happens on empty results, or the response shape.

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 definition is short and front-loads the purpose, but it reads as machine-appended metadata fragments ('Platform=tiktok resource=search. Credits unit: page.') rather than a coherent sentence structure.

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 should do more to explain return values and result behavior. It covers cost and auth but leaves the response shape and pagination outcome unstated.

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 explains keyword and cursor. The description adds no parameter guidance beyond the schema, but the 'Priced per page' line does hint at the pagination semantics of the cursor. 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: 'Search public users by keyword.' It's clear what the tool does, and the Platform=tiktok tag distinguishes it from sibling search tools like threads_search, reddit_search, and youtube_search. It doesn't explicitly name a sibling alternative, so 4 rather than 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 word 'public' implies a scope, but there's no explicit guidance on when to use this versus alternatives like tiktok_user or tiktok_posts. Usage context 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. It usefully discloses two non-schema behaviors: a cost of 1 credit and a required Authorization: Bearer <api_key> header. It says nothing about rate limits, failure modes, or whether the profile must be public-facing beyond 'public', leaving 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?

Purpose is front-loaded, which is good, but the definition is padded with metadata-style boilerplate ('Platform=tiktok resource=user') that duplicates the tool name, and there is a stray double period after 'avatar.'.

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 output schema and no annotations, the description covers the essentials: what it fetches, the returned fields, the auth requirement, and the credit cost. Missing only error/rate-limit behavior, which is minor here.

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 username parameter already documents format ('without @') with an example. The description only restates 'by username', adding no format or edge-case detail beyond the schema, 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 (Fetch), resource (public TikTok profile), and scope (by username), plus the fields returned (bio, stats, verification, avatar). This clearly separates it from tiktok_posts, tiktok_post, and tiktok_search, though it never names a 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?

No when-to-use guidance, no conditions for choosing this over tiktok_posts or tiktok_followers, and no exclusions. The only guidance is operational (cost and auth), not selection-oriented.

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 cost (1 credit) and the auth requirement (Bearer api_key), but says nothing about rate limits, error behavior, or whether the count is cached/approximate.

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 is front-loaded and the text is short, but the 'Platform=twitch resource=followers' clause largely restates the tool name and the double period is sloppy. The cost/auth sentence earns its place; the metadata clause 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?

For a single-parameter read tool with no output schema, the description covers the essentials: what is returned (a follower count), the auth requirement, and the cost. Nothing critical is missing, though output shape and error cases are unaddressed.

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 already documents the sole parameter ('Channel login without @.'). The description adds no syntax or format detail beyond what the schema provides, 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 (fetch) and resource (public follower count) scoped to a Twitch channel username, which cleanly separates it from siblings like twitch_search. It stops short of explicitly naming a sibling, but the platform/resource tags make the distinction 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?

There is no guidance on when to use this tool versus alternatives; the 'Platform=twitch resource=followers' string is metadata, not routing advice. No exclusions or prerequisites beyond the auth header are given.

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 behavioral burden well: it discloses the auth requirement (Authorization: Bearer), the credit cost (1 credit per page), the billing unit (page), and an approximate result count (~15 per page). It omits error/edge behavior and deeper pagination semantics, 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-loads the actual action, but the trailing boilerplate ('Platform=twitch resource=search. Costs 1 credit(s). Credits unit: page.') is machine-generated noise that partially restates the tool name, and there is a stray double period.

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 auth, cost, and result-set size, which is adequate. However it never describes what a result looks like or how depth interacts with cost when set above 1, leaving some 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 100%, so the schema already documents keyword, type, and depth. The description's only added detail is '~15 per page', which loosely contextualizes depth, so baseline 3 applies.

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

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

States a specific verb and resource ('Search public Twitch videos, channels, or games by keyword') with scope (public) and the entity types covered. An agent can distinguish it from twitch_followers, though it does not explicitly contrast against it or the other platform search siblings.

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 no when-to-use guidance or alternatives. The '~15 per page' and pricing notes describe cost, not the conditions under which this tool is the right pick over reddit_search/threads_search/tiktok_search.

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 add useful operational context: a 2-credit cost and the required Authorization: Bearer <api_key> header. It does not disclose error behavior (e.g., invalid/private/deleted tweet) or what the 'stats' payload contains, so it 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 purpose and kept to a few short clauses; nothing is padded. Minor blemish is the stray double period after 'id..' and machine-generated boilerplate ('Platform=twitter resource=post').

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 fetch with no output schema, the description covers purpose, auth, and cost but omits return shape, error handling, and pagination/rate-limit behavior. It is adequate but leaves gaps an agent may hit at invocation time.

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 'id' parameter already documented as 'Tweet id.' with an example. The description adds no format or semantic 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?

States a specific verb (Fetch), resource (tweet/post), and scope (public details and stats) plus the lookup key (by id). It is distinguishable from twitter_tweets, but it never names the sibling to clarify the boundary between a single-post fetch and a listing/search tool.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives. The 'by id' phrasing only implicitly signals single-item retrieval; an agent must infer that twitter_tweets is the list counterpart.

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

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

With no annotations, the description carries the burden well: it discloses cost ('Costs 4 credit(s)'), auth requirements ('Requires Authorization: Bearer <api_key>'), coverage limitations ('Best coverage on verified accounts'), and the return shape ('compact tweet list (not raw GraphQL)'). It doesn't cover pagination or rate behavior, keeping it below 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?

Purpose and the key caveat are front-loaded, and the length is reasonable. The trailing 'Platform=twitter resource=tweets' boilerplate and a stray double period add minor noise.

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 list tool with no output schema, the description covers the id source, the response shape, cost, and auth. Only pagination/result limits are unaddressed, which is 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?

Schema coverage is 100% and the single 'id' parameter is fully documented in the schema, so baseline 3 applies. The description reinforces the id source ('from User Info') but adds no new format or syntax 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?

States a specific verb ('Fetch') and resource ('recent public tweets for a user id'), which is enough to separate it from twitter_user (profile) and twitter_post (single post). It stops short of explicitly naming those siblings, so it lands at 4 rather than 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?

'Best coverage on verified accounts' and '(from User Info)' imply when to use it and where the id comes from, but there is no explicit when-not or named alternative among siblings. Usage is 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 burden, and it does disclose two useful traits: a 2-credit cost and a Bearer api_key authorization requirement. However, it says nothing about failure modes (private/suspended accounts), rate limits, or response shape.

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 in the first clause, and the cost/auth notes are short. Slight deductions for the stray double period and the redundant 'Platform=twitter resource=user' metadata line that repeats the tool name.

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, no-output-schema tool, the description covers the identity of the resource, the key returned fields, cost, and auth. It is close to sufficient, though it omits what happens when the profile is missing or protected.

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

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

Schema description coverage is 100% and the single parameter is documented with an example format, so the baseline is 3. The description's 'by username' adds almost nothing beyond the schema's 'Username without @.'

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), a specific resource (public X profile), and the access path (by username), plus the fields returned (bio, followers, verification). This distinguishes it from siblings like twitter_tweets (timeline content) and twitter_post (single 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?

There is no guidance on when to use this tool versus alternatives (e.g., twitter_tweets for timeline content), no exclusions, and no prerequisites beyond the auth note. The use case is only implied by 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?

With no annotations, the description carries the full burden and does disclose two operationally important traits: it requires Authorization: Bearer <api_key> and costs 2 credits per page. However it says nothing about return format, ordering, rate limits, or what happens when the cursor is exhausted, leaving sizable gaps for a mutation-free but paid, authenticated 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?

The first sentence is well front-loaded and useful, but the trailing boilerplate is redundant and contains a typo ('page..'), repeating the per-page pricing twice ('Priced per page' and 'Credits unit: page'). Roughly half the text is machine-generated metadata rather than information the agent needs.

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 two-parameter read tool with no output schema, the description covers the essentials: what it returns (a page of comments), how it is paged (cursor from previous nextCursor), auth, and cost. It could say more about the returned comment fields or when pagination should stop, but nothing critical is missing.

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

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

Schema coverage is 100%, so both id and cursor are already documented in the schema, and the description only re-states that id targets a video/Short page. No additional syntax, format, or limits are added beyond the schema baseline.

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

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

States a specific verb (Fetch) and resource (public comments) scoped to a video or Short, and the platform/resource metadata plus the name distinguish it from the instagram_comments/reddit_comments/tiktok_comments siblings. It does not explicitly name an alternative, but an agent can identify the tool without opening either schema.

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

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

The description implies the tool applies when you have a video or Short id, but gives no when-to-use vs when-not guidance and no comparison to siblings such as youtube_video or youtube_shorts. Usage must be inferred from the required id parameter 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 and does disclose two meaningful traits: an auth requirement (Authorization: Bearer <api_key>) and a cost model (1 credit per page). It still omits rate limits, sorting/ordering behavior, and whether results are paginated beyond the stated depth, which keeps 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?

The purpose and page size lead the sentence, which is good, but the tail is boilerplate redundancy: 'Priced per page' is restated by 'Costs 1 credit(s)' and 'Credits unit: page', and 'Platform=youtube resource=search' adds nothing for an agent. A stray double period also signals templated, unedited text.

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 is adequate: auth, cost, and approximate result volume are present. It stops short of describing result fields, ordering, or how to disambiguate from the many sibling search/video tools, 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 100%, so both parameters (keyword, depth) are already documented, and the description only restates the depth default and adds the ~20-per-page output estimate. Baseline 3 is appropriate 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 ('Search public videos by keyword') and adds scope via the ~20-per-page estimate, so an agent knows this is a keyword-driven public video search. It does not, however, distinguish itself from near siblings like youtube_videos, tiktok_search, or threads_search, leaving that routing to inference.

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 only usage guidance is an implicit default page count; there is no statement of when to choose this over youtube_videos, youtube_channel, or other platform search tools, and no preconditions beyond the generic auth note.

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 cost (6 credits), the pricing unit (page), the auth requirement (Bearer api_key), and the ~50-items-per-page rate. It does not state read-only semantics explicitly, but 'Fetch' implies it and the pricing/rate details are the operationally important facts.

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 and short, but contains redundancy: 'defaults to 1 page' repeats the schema, while 'Priced per page' and 'Credits unit: page' say the same thing twice, and a stray double period ('page..') signals careless formatting.

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 or annotations exist, yet the description covers the key unknowns: cost, pricing unit, auth, and page size. An agent has enough to call it correctly, with only return-value shape left unspecified.

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 both browse_id and depth. The description adds the ~50-per-page rate that helps interpret depth, but otherwise restates the 1-page default already 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?

States a specific verb ('Fetch') and resource ('Shorts for a channel'), and the resource name inherently distinguishes it from youtube_videos/youtube_video in the sibling list. It does not explicitly name the alternative video tool, so it stops short of a 5.

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

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

There is no guidance on when to use this versus youtube_videos or youtube_search; the only conditional content is the depth default. An agent must infer that 'Shorts' is a distinct content type 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 present, the description carries the full burden, and it does disclose useful traits: the data is 'public', it requires an Authorization: Bearer header, and it costs 1 credit. It stops short of describing the return shape beyond 'string', error behavior, or any rate/permission limits.

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

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

The core purpose is front-loaded and terse, but the 'Platform=youtube resource=subscribers' segment merely restates the tool name, and a stray double period ('id..') suggests unfinished editing. Minor waste, still readable.

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, no-output-schema read tool, the description covers what it returns, the auth need, and the credit cost, which is largely sufficient. It omits any differentiation from sibling tools and any notion of failure modes or pagination.

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 browse_id with an example and a source hint. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (fetch) and a precise resource (public subscriber count for a channel id), so an agent knows exactly what it returns. However, it does not distinguish itself from siblings like youtube_user, which plausibly surfaces the same subscriber data.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as youtube_user. The only hint of usage context is the channel-id scoping, which is already implied by the required parameter.

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 credit cost, the cheaper browse_id path, and the auth requirement (Authorization: Bearer <api_key>). It says nothing about rate limits, failure behavior when a username does not resolve, or whether the data is cached/public-only beyond the word 'public'.

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 and short, but it repeats cost information ('3 credits / 2 credits' then 'Costs 2 credit(s)'), contains boilerplate 'Platform=youtube resource=user', and ends with a stray double period. The boilerplate and duplication dilute an otherwise tight description.

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 endpoint with no output schema and no annotations, the description covers the operation, both input modes, cost, and auth. Only the shape of the returned metadata and error conditions are left unstated.

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 genuine meaning the schema lacks: the credit differential between username (3) and browse_id (2) and the internal resolution step. That is useful decision information beyond the parameter docs.

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 public channel details by username or browse id') and names the returned payload ('description, links, and metadata'). It is clearly distinct from youtube_videos, youtube_comments and youtube_subscribers, though it never explicitly says which sibling to prefer.

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 real guidance for choosing between the two input modes (username resolves internally at 3 credits vs browse_id at 2), but offers nothing on when to use this tool versus youtube_subscribers, youtube_search or the other youtube siblings. Usage context is 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 burden, and it does disclose two real behavioral facts: the call costs 1 credit and requires an Authorization Bearer header. However, it says nothing about whether the call is read-only, what 'stats' actually contains, or any rate/limit behavior.

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

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

Extremely tight, front-loaded with the purpose before the metadata clauses. Minor blemish: the stray double period after 'id..' suggests mechanical generation rather than clean prose.

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 with no output schema, the description covers purpose, cost, and auth but never says what fields the 'public stats' return or what happens on an invalid/non-existent id, leaving an agent guessing about the response shape.

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 in the schema with an example, so the description adds nothing beyond 'by id'. Baseline 3 applies 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 and resource: 'Fetch public stats for a video or Short by id.' It distinguishes itself reasonably from the list-style siblings (youtube_videos, youtube_shorts) by being single-item, though the 'video or Short' overlap with those siblings is not explicitly resolved.

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 versus youtube_videos, youtube_shorts, or youtube_resolve – all of which deal with YouTube video resources. The only implicit cue is 'by id', leaving the agent to infer the selection condition.

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 useful operational traits: cost (3 credits/page, priced per page), auth requirement (Bearer api_key), and pagination (~25 per page). However, it says nothing about return shape, rate limits, quota errors, or what an empty channel yields.

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 purpose and the per-page pricing immediately, followed by boilerplate (platform/resource, cost, auth). Every clause is informative, though the doubled period ('page..') and stacked metadata lines are slightly unpolished.

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 2-param list tool with no output schema, the description covers cost, auth, and pagination, which is reasonably complete. It falls short on routing (why not youtube_video/youtube_search) and on any error or return-shape expectations.

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% – browse_id is documented as the channel id (UC…) and depth as pages with default 1. The description adds no format or syntax beyond that, so the baseline 3 applies. It does reinforce that depth is page-based via the pricing note.

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 recent uploads for a channel', plus scope detail (~25 per page). It is clearly a list-uploads tool, distinguishable from youtube_video (singular) and youtube_search in intent, though it never names those siblings to sharpen the distinction.

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 or when-not guidance, and no mention of the many YouTube siblings (youtube_video, youtube_search, youtube_shorts). A user must infer from the name alone whether this or youtube_video is the right call. Context is only implied.

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