Fetchwire - Social Data

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the call 'spends credits like any other call' and uses 'Fetch' to imply a read operation. However, it does not address potential errors, response format, rate limits, or whether any route could have side effects, leaving behavioral coverage incomplete for a generic route caller.

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

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

The description is three sentences, each earning its place: purpose, prerequisite workflow, parameter explanation with example, and cost note. It is front-loaded with the core function and contains 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?

Given the tool's generic nature and lack of output schema or annotations, the description covers the key operational aspects: what to call, how to discover the path, how to pass parameters, and that credits are consumed. It could mention the response shape or error handling, but for a generic route caller with this complexity, it is reasonably 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?

The input schema provides zero description coverage, so the description must compensate. It does so by explaining that `params` are query parameters and giving a concrete example with both `path` and `params`. This adds real meaning beyond the bare schema, though it does not fully elaborate on path formats or edge cases.

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 any Fetchwire route by path.' It clearly distinguishes itself from sibling operation tools by targeting 'the routes the operation tools do not cover,' and names list_routes as the discovery mechanism. This is specific enough for an agent to understand exactly what call_route is for.

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

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

The description gives explicit context for when to use this tool: for routes not covered by operation tools, and instructs the agent to find the path with list_routes first. However, it does not name the specific operation tools as alternatives, instead referring to them as a category ('operation tools'), which is clear but slightly less direct than naming the siblings.

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

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

With no annotations, the description carries the full burden. It discloses the flat response structure with parent_id, explains cursor pagination for threading, and specifies input formats per platform. It does not mention side effects, but as a read operation this is implicit. It provides solid behavioral insight beyond the bare schema.

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

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

The description is dense but every sentence adds essential value. It opens with the core behavior and response structure, then cursor mechanics, then platform-specific formats. No fluff or repetition; it is appropriately sized for the complexity.

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?

Despite lacking an output schema, the description covers all necessary aspects: response format (flat with parent_id), pagination (cursor), and parameter semantics for every platform. It is comprehensive for an agent to call the tool correctly without additional documentation.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does this extensively: it defines valid formats for the 'id' parameter on every supported platform (e.g., shortcode, /p/ URL, t3_ id, secUid, etc.), explains 'cursor' usage for replies, and implicitly defines 'platform' by listing platforms. This is far beyond what the schema offers.

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 title and opening sentence state the tool's purpose precisely: 'Get comments on a post' and 'Comments on a post, flat, with parent_id set on replies...' This clearly distinguishes it from siblings like get_post or get_user_posts. The description also explains the comment structure, making the purpose unambiguous.

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

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

The description clearly indicates the tool is for retrieving comments on a post, giving strong context. It does not explicitly compare with alternatives or state when not to use it, but the context is clear enough for an agent to select it when comments are needed. Slight deduction for lack of explicit exclusions.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that the result is 'one post with its stats and author' and that it accepts 'any public URL,' which is useful. It does not mention read-only behavior, error cases, authentication needs, rate limits, or what happens when a user/profile identifier is supplied, leaving meaningful gaps.

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

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

The structure is front-loaded with the core purpose and then proceeds through a dense, platform-by-platform list of accepted forms. The repeated 'username or profile URL; for posts…' pattern adds length and ambiguity, but each sentence carries concrete parameter value rather than filler.

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

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

Given no annotations, no output schema, and 0% parameter schema coverage, the description does a strong job of covering the two parameters and the expected output ('stats and author'). It is still missing output structure, error semantics, and clarification of why username/profile forms appear in a post-fetching tool, so it is not fully complete.

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

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

The input schema has 0% description coverage and only bare 'platform' and 'id' string fields. The description compensates thoroughly by enumerating accepted identifiers per platform, including shortcodes, activity ids, t3_ ids, handles, and URL patterns, giving an agent the concrete format guidance needed to supply valid parameters.

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 'One post with its stats and author,' which clearly states the verb, resource, and scope, distinguishing it from siblings like get_user_posts and get_comments. However, the per-platform list includes 'username or profile URL' forms, which confuses whether this tool also accepts user identifiers, so it is not fully unambiguous.

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

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

The description gives extensive accepted id/URL formats for each platform, such as 'a shortcode or /p/ or /reel/ URL' for Instagram and 'a tweet id or status URL' for X. It does not explicitly say when to prefer get_post over alternatives like get_user, get_user_posts, or search, nor does it state exclusions, so usage guidance is implied rather than explicit.

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 disclosure burden. It usefully adds that the call is free, is scoped to the calling key, and returns both a balance and per-endpoint monthly usage. It omits details like rate limits or response format, but this is a simple read-only balance query, so the disclosure is adequate.

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

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

The description is two compact sentences with no filler. The return content is stated first, and the cost note is cleanly separated. Every sentence earns its place.

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

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

For a zero-parameter, low-complexity read-only tool, the description is nearly complete: it states what data is returned and that it is free. The absence of an output schema is partially mitigated by the high-level return description, though the exact response structure remains 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?

This tool has zero parameters, so the baseline is 4. The description's mention of the 'calling key' clarifies the implicit authentication scope, and there are no parameter semantics left unexplained.

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

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

The description clearly identifies the resource (the calling key's credit balance) and the scope (this month's usage by endpoint). The title supplies the verb 'Check,' making the operation obvious. It is distinct from siblings like get_user or list_routes, though it does not explicitly contrast with them.

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 does not state when to use this tool versus alternatives. 'Free to call' is a cost note, not a usage rule, and there is no guidance on when not to use it or which sibling might be more appropriate.

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 of behavioral disclosure. It does reveal return content (follower counts, bio, verification, `extra`) and accepted input kinds, but it does not mention auth requirements, rate limits, error behavior, or which platforms are excluded.

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

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

The description is long but justified by seven platforms; the general rule is front-loaded, then each platform is covered compactly. The semicolon-heavy style is dense but 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?

Given the high complexity (7 platforms, 0% schema coverage, no output schema), the description provides substantial guidance on input construction and mentions key return fields. It stops short of a full output shape or handling of ambiguous cases like the post-URL behavior for a user-profile tool.

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

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

Schema coverage is 0%, and the description fully compensates by enumerating valid `id` formats for each platform, including handles, URLs, shortcodes, post IDs, and even short links. This is exactly the domain semantics the schema leaves out.

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 resource ('A user's profile') and the key data returned (follower counts, bio, verification, platform extras), which distinguishes it from siblings like get_post or get_comments. The extensive per-platform notes slightly blur the line by accepting post URLs, but the core purpose remains 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?

It gives concrete identifier formats for each platform and implies when to use the tool with those inputs, but it never explicitly says when not to use it or names alternatives like get_post for actual post retrieval. Usage context is implied rather than explicit.

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 and does disclose key traits: newest-first ordering, included view/like/comment counts, and cursor-based pagination. It omits auth/error/rate-limit details, but for a simple read endpoint the named behaviors are the most decision-relevant ones.

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 concise and front-loaded, but the remaining platform-by-platform list becomes a dense block of text. It is informative and mostly necessary, though the phrasing 'for posts' adds ambiguity and the format could be more scannable with line breaks or structured 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?

Given no annotations and no output schema, the description covers the key usage details: result ordering, returned metrics, pagination, and platform-specific id formats. It does not mention authentication or supported platform enum values explicitly, but the platform list is inferable and the core calling contract is 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 coverage is 0%, yet the description compensates thoroughly: it enumerates every supported platform, gives accepted user-identifier and post-identifier forms for each, and defines the cursor as next_cursor from a previous response. This is far more than the bare property names provide.

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

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

The description clearly identifies the resource as a user's posts and specifies ordering and returned counts, so an agent can distinguish it from get_user or get_post by resource type. The only slight weakness is that the later 'for posts' ID-format clauses could be read as implying single-post retrieval, adding ambiguity.

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

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

It gives clear context that this endpoint is used to fetch a user's posts, and it instructs on pagination with next_cursor. It does not explicitly name alternatives or exclusions (e.g., use get_post for a single post), so it stops short of a 5.

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 alone must convey behavior. It communicates that the result is an informational catalog of platforms with per-platform operation support, and the word 'list' implies a read-only call. It does not explicitly confirm non-mutating behavior, output format, or ordering, but for a zero-parameter listing these omissions are minor.

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

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

A single sentence with no filler; it states the resource and the key output detail in one line. The information is front-loaded and every word earns its place.

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

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

For a parameterless list tool with no output schema, the description explains the return content well enough to invoke the tool. It could arguably enumerate the six operations, but that is likely domain knowledge and not required for a correct call.

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 are zero parameters and schema coverage is 100%, so the description has no parameter details to add. Per the baseline for zero-parameter tools, the definition is adequate.

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

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

The description identifies the resource (platforms served by Fetchwire) and the specific information returned (which of six operations each supports). It is clearly distinct from sibling tools like list_routes or search_users, though it lacks an explicit verb and relies on the title 'List platforms' for the action.

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 a use case: to discover platforms and their supported operations before picking a platform. However, it does not explicitly state when to prefer this tool over alternatives such as list_routes, nor does it mention any preconditions or follow-up actions.

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 that the call is free ('Free to call') and that the output includes credit costs, giving useful behavioral context. It also states it returns 'every route', indicating the scope. It does not mention potential response size or pagination, but for a listing tool this is a reasonable level of transparency. The description adds value beyond the raw schema.

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

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

The description is three sentences with no filler. The core purpose is front-loaded, then usage guidance and filters follow. Every sentence contributes: what it is, when to use it, and how to filter. It is concise yet thorough, earning its length.

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

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

The tool has two optional parameters, no output schema, and no annotations. The description covers the key aspects an agent needs: what the tool does, when to use it (for uncovered routes), the two filters, and the next step (call_route). It does not describe the response format, but since there is no output schema, that might be a gap; however, the purpose and usage are clear enough for an agent to invoke it successfully. Slightly more detail on return shape would push it to a 5.

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

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

Schema coverage is 0% for the two optional parameters, so the description must compensate. It explains that 'platform' filters by platform and 'contains' matches on the path, adding meaning that the schema lacks. It doesn't enumerate allowed platforms or give examples, but it gives enough semantic clarity for an agent to use the filters correctly.

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

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

The description clearly states the tool's purpose: lists every route Fetchwire serves with credit costs. It uses a specific verb 'list' and resource 'routes', and differentiates from siblings by explicitly noting it covers routes that operation tools do not (TikTok shop/live/trending, Reddit subreddits/feeds, etc.) and names the follow-up tool call_route. This makes it unmistakable which tool is which.

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 explicitly says to use it to find routes not covered by operation tools, and instructs to fetch one with call_route. It also mentions filtering by platform or contains. However, it does not explicitly contrast with list_platforms or state when not to use it, though the 'operation tools do not cover' phrase implies the division of labor. Good guidance overall, but could be more explicit about 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 provided, the description carries the full disclosure burden, and it does add useful behavioral context: platform-specific sort semantics and the exclusion of LinkedIn/Threads from keyword search. However, it leaves other operational behaviors undisclosed, such as cursor/pagination behavior, what an invalid platform produces, and any rate limits or auth requirements.

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

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

Three sentences with zero filler: core purpose front-loaded first, sort caveat second, platform exclusion and pointer third. Every sentence earns its place and the most decision-relevant information appears first.

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

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

For a 4-parameter, multi-platform search tool with no output schema and no annotations, the description covers the essential calling contract well but omits cursor semantics and any indication of the return shape or pagination behavior. It is adequate for basic invocation but leaves clear gaps an agent would hit on real usage.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for three of four parameters: q (keyword), platform (enumerated in prose), and sort (varies by platform, omit for default — genuine added nuance). The cursor parameter is entirely unexplained, which is the main gap.

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

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

The description states a specific verb and resource ('Search posts or videos by keyword') and scopes it to five named platforms, making the tool's purpose immediately clear. It differentiates from siblings like search_users implicitly (posts/videos vs. users), though it never explicitly contrasts with search_users or get_user_posts.

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

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

The description gives explicit when-not guidance ('LinkedIn and Threads have no keyword search') and routes the agent to a concrete alternative ('use list_routes to see what they do offer'). It also advises on sort behavior, but it does not address when to prefer this tool over other search-like siblings such as search_users.

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 implies a read operation ('Find') and discloses a platform limitation (LinkedIn), but it does not mention rate limits, auth requirements, pagination behavior, or what happens with no results. Some behavioral context is given, but significant gaps remain.

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

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

Two sentences, both purposeful and front-loaded. The first sentence states the action and scope; the second explains the use case and an exclusion. No wasted words.

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

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

For a tool with 3 parameters, no output schema, and no annotations, the description is incomplete. It explains the purpose but omits parameter semantics, return format, pagination, and error behavior. The agent would need to inspect the schema (which also lacks descriptions) or guess to call it correctly.

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

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

The schema has 0% coverage and the description does not mention any of the parameters (q, platform, cursor). It lists platforms in prose but does not connect them to the platform parameter, nor does it explain what q or cursor mean. The agent gets no help from the description in understanding parameter usage.

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

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

The description uses a specific verb ('Find') and resource ('accounts') and enumerates the exact platforms (youtube, tiktok, instagram, x, reddit, threads). It also clarifies the use case: turning a person/brand name into a handle for other tools, and notes the LinkedIn exclusion, which differentiates it from generic 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?

The description gives clear context for when to use it ('turning a person or brand name into the handle the other tools take') and an explicit exclusion ('LinkedIn has no profile search'). It does not name alternatives or state when not to use it, but the context is strong enough to guide selection.

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