Scraping Daddy

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

The annotations already disclose readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the response is returned unchanged, which is useful passthrough context, but it omits important behavior such as approval requirements, auth expectations, rate limits, and 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?

It is a single front-loaded sentence with no wasted words. The core behavior and passthrough semantics are stated 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 generic API proxy surrounded by endpoint-discovery and platform-specific siblings, the definition is too sparse. The schema and output schema carry much of the load, but the description does not explain how an agent should discover approved endpoints or choose this tool over the specific platform tools.

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 fully documents path, method, params, and body, including the constraint that path must be a known endpoint under /v1 or /v2. The description adds no parameter-level detail beyond what the schema already provides, 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: call any Scraping Daddy endpoint and return its response unchanged. This distinguishes it as a generic passthrough tool, but it does not explicitly contrast itself with siblings such as list_endpoints, get_endpoint_schema, or the platform-specific 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?

There is no guidance on when to use this generic api_request versus the many specific sibling tools like tiktok_profile or x_tweets, nor when to call list_endpoints or get_endpoint_schema first. Usage is only implied by the phrase 'any endpoint.'

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 declare readOnlyHint=false and openWorldHint=true, but the description's "Get ... profile data" implies a plain read and never reconciles the mismatch or warns that the call reaches an external network. With annotations already flagging open-world access, the description should add at least what data is returned or what auth/quota constraints apply; it adds none of that, though the presence of an output schema means return shape needn't be spelled out.

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

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

One short, front-loaded sentence with no filler or redundancy. It is appropriately sized rather than bloated, though the brevity edges into under-specification rather than economy.

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?

An output schema exists and the single parameter is fully documented, so the essentials for invoking it are present. Still, for an open-world external fetch the description leaves the agent without any statement of what a "page profile" includes, whether private/page-admin data requires authorization, or how failures surface.

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

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

Schema description coverage is 100% and the single parameter is well documented ("Page id, username, or facebook.com URL"), so the schema carries the meaning. The description only implicitly confirms that the page is the lookup key and adds no new semantics; 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 names a specific verb and resource ("Get a Facebook page's profile data") and the platform is unambiguous, so an agent can distinguish it from the instagram_profile / tiktok_profile / x_profile siblings by platform alone. It doesn't say what fields constitute "profile data" or how it differs from the generic api_request escape hatch.

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 api_request or get_endpoint_schema, and no mention of prerequisites such as needing a page identifier or an authenticated connection. The agent must infer usage entirely from the name and the single 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that the returned schema covers both request AND response, which is useful beyond the annotations and beyond the short output schema summary. It says nothing about lookup failure behavior or that the 'method' parameter affects which schema is returned.

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

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

One sentence, front-loaded with the verb and the payoff ('full request and response schema'). No filler and no redundancy with the title.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile; a single sentence is close to sufficient for a simple two-parameter read. The only missing piece is any hint about the expected workflow with api_request or how an invalid path is surfaced.

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%: the path format example '/v1/tiktok/profile' and the GET/POST enum-free method constraint are documented inline. The description contributes nothing additional about parameters, 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 ('Return the full request and response schema for one AM-CORE endpoint'), which is precise enough to tell apart from list_endpoints (enumerates endpoints) and api_request (executes calls). It is clear what the tool produces, though the 'AM-CORE' naming is only meaningful if the agent already knows the product.

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: you fetch a schema, presumably before calling api_request. Neither sibling is named, and there is no statement of when to prefer list_endpoints to discover a path first, nor what happens for an unknown path. Adequate but leaves the routing decision to inference.

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

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

The description frames this as a pure retrieval ('Get business details'), while annotations declare readOnlyHint=false, so an agent cannot tell whether calling it has side effects. No mention of authentication via the aggregator, rate limits, or what happens when identifiers disagree beyond the bare constraint. With annotations present the bar is lower, but this tension is unexplained.

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

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

Two tight, front-loaded sentences with no filler, and the identifier constraint is placed where an agent will read it first. It is efficient but so terse that the gaps are a matter of under-specification, not verbosity.

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?

An output schema exists so return shape need not be explained, but with 4 parameters at 0% schema coverage and an unresolved read-only question, an agent lacks enough to call this confidently. The unmentioned country parameter and the unmapped data_id/ludocid fields are real holes.

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 carry parameter meaning and it only partially does: it names three identifier concepts without mapping them to data_id, ludocid, or place_id, and the country parameter (default 'us') is never mentioned at all.

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 ('Get business details') plus the three accepted identifier kinds (feature ID, place ID, decimal CID), which separates it from google_maps_search (query-based) in the sibling list. It doesn't explicitly name search as the alternative, but the lookup-by-identifier scope is clear.

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

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

'using at least one ... ID' implies the precondition and 'Multiple identifiers must agree' gives a consistency rule, but it never says when to prefer this over google_maps_search or where to obtain those IDs. Usage is implied rather than prescribed.

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

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

Annotations already declare openWorldHint=true and destructiveHint=false, and the description adds useful paging and domain-restriction context. It does not contradict the annotations, but it leaves important behavioral details unstated, such as what 'select' does and whether there are auth or rate-limit concerns.

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 short and front-loaded, but it is cryptic: 'AM-CORE' is undefined, 'offsets' is not mapped to the page parameter, and the meaning of 'data' is never clarified. It is concise without being sufficiently clear.

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?

This is a nine-parameter, open-world search tool with an output schema but no schema descriptions. The description omits most parameter semantics and does not route the agent between search and place lookup, so it is not complete enough for reliable invocation.

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

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

Schema description coverage is 0% across nine parameters, so the description must compensate. It only gives hints for ll, place_id, data, and domain, while query, type, page, country, and language are left completely 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 gives a verb and resource: 'Search places or select one by place_id/data.' However, 'select one' is vague, and it does not explain how this differs from the sibling google_maps_place, which appears to serve a similar place lookup role.

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 offers operational constraints about offsets, maximum paging, and supported domains, but gives no explicit guidance on when to use this tool versus google_maps_place. An agent has to infer the search-vs-place distinction from the type enum and sibling 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?

The description says 'Get', which implies a read-only retrieval operation, but the annotations declare readOnlyHint=false. That is a direct conflict in the safety profile. The description also adds no context about authentication, rate limits, private 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 description is a single front-loaded sentence with no wasted words. It immediately communicates the verb, resource, and required identifier.

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

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

The tool is simple and has an output schema, so the description does not need to explain return values. However, for an open-world retrieval tool it should clarify behavior enough to resolve the readOnlyHint conflict and provide basic routing guidance among sibling tools.

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 shortcode parameter is already well documented in the schema with examples. The description only restates that the tool uses a shortcode, so it adds no meaningful parameter semantics 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?

The description states a specific verb and resource: get a single Instagram post or reel by shortcode. This is clear and distinguishes the tool from profile-oriented siblings in practice, though it does not explicitly name alternatives such as instagram_profile.

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 'by its shortcode', which tells the agent when this tool applies. However, there is no explicit guidance about when to use this versus instagram_profile, api_request, or other media-specific tools.

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

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

The description says 'Get an Instagram profile,' which implies a read-only retrieval, while the annotations explicitly set readOnlyHint=false. This is a direct contradiction. The description also omits any auth, rate-limit, or side-effect context.

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

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

A single front-loaded sentence with no wasted words. It states the resource and the key returned data 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?

The description covers the returned profile data, and an output schema exists, so return values need not be explained. However, with zero required parameters and both identifiers nullable, it should clarify that the caller must supply a username or user_id. That gap matters for correct invocation.

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

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

Schema description coverage is 100%, and both optional parameters (user_id and username) are already documented in the schema. The description adds no parameter-level meaning, such as whether one identifier is required or preferred, 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: 'Get an Instagram profile.' It also names the fields returned (bio, follower counts, account metadata), which clearly differentiates it from media-focused siblings like instagram_media.

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 retrieval intent is implied by 'Get an Instagram profile,' but there is no explicit guidance on when to use this versus instagram_media or other profile tools. No prerequisites or exclusions are 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that filtering is optional and unrestricted by default, but says nothing about result volume, default limit behavior, or whether the full set is returned in one page.

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, front-loaded with the action and resource, with zero redundant text. Nothing needs trimming.

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?

An output schema exists and annotations cover the safety profile, so the remaining burden is light. Still, for a discovery tool among many endpoint-ish siblings, the description leaves unclear what an endpoint record contains and how it relates to get_endpoint_schema or list_platforms.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the 1-500 limit range and match fields for query. The description only restates platform and query at a high level and omits limit entirely, so it adds no meaning beyond the schema (baseline 3).

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

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

Specific verb+resource ("Find AM-CORE endpoints") with scope modifiers named. It doesn't reference the closest siblings (get_endpoint_schema, list_platforms), so an agent must infer the boundary, and "AM-CORE" is unexplained jargon.

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

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

The phrase "optionally filtered by platform and/or a search term" implies when the filters are useful, but there is no explicit when-to-use/when-not guidance and no named alternative such as get_endpoint_schema for drilling into a single endpoint.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds genuinely new context the annotations cannot express: 'Discovery only — this does not consume API credits', which is a material cost consideration for an agent deciding whether to call it. It omits any note on result size or pagination, keeping it below 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?

Three short sentences, front-loaded with what it returns, followed by when to use it and the cost caveat. No filler and no restating of 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?

An output schema exists, so the description needn't explain return values, and the zero-param schema needs no elaboration. What is missing is only a pointer to the natural follow-up tool (list_endpoints / get_endpoint_schema), which would make the discovery workflow fully closed-loop.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. It correctly presents itself as an unfiltered full listing, which is the only semantically relevant statement for a no-arg tool.

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 ('List every platform Scraping Daddy can scrape') plus the shape of the result ('with a short description'). This is clearly distinguishable from siblings like list_endpoints, get_endpoint_schema, and api_request, which operate on endpoints or make calls rather than enumerate platforms.

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

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

Explicitly names the triggering condition: 'Start here when the user asks SD for live data and the endpoint is not known yet.' That gives a clear entry-point rule, though it stops short of naming list_endpoints/api_request as the required next step, so the agent must infer the follow-on 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 already declare openWorldHint=true and destructiveHint=false, so the description's bar is lower, but it adds nothing beyond them: no mention that results are paginated via the after cursor, no rate-limit or auth context. Notably readOnlyHint=false on a search tool is unexpected, and the description neither confirms nor explains any side effect.

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

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

A single front-loaded sentence with zero waste. It is under-specified rather than bloated, so the terseness is a clarity problem, not a conciseness one.

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?

An output schema exists, so return values need no explanation, and the schema covers all parameters. What is missing is the operational framing: what corpus is searched, that results are paged, and how this relates to the generic api_request sibling.

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 query, limit, and after are fully documented in the schema itself. The description adds no meaning beyond that, which is acceptable at this coverage level but earns no credit.

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

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

The description names a specific verb and resource ("Search Reddit posts"), so the basic operation is clear. However, it does nothing to separate this tool from siblings like api_request or the other platform-specific tools (x_tweets, instagram_media), and it never states what scope of Reddit is searched (subreddit, user, all of Reddit).

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 api_request or list_endpoints, and no exclusions. An agent must infer that this is the Reddit-specific path for post search purely from the name.

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

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

No annotations are repeated and the description correctly conveys a pure fetch, adding the specific payload fields. It does not mention auth requirements, rate limits, or whether a missing/private creator yields an error versus empty data. Note the annotations set readOnlyHint=false for what the description presents as a read — an inconsistency worth flagging, though the fault likely lies in the annotation rather than the text.

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

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

A single front-loaded sentence with the resource and returned fields, zero filler, zero restatement of the title.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. What remains unaddressed is the practical calling constraint — that the agent must supply handle or user_id — which is the main thing an agent could get wrong 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 schema already explains that user_id is 'an alternative to handle' and that '@' is optional, so the description adds nothing on parameters and the baseline 3 applies. The one operational gap is that neither schema nor description states that at least one identifier is required (required parameters: 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?

The description names a specific verb and resource and enumerates the payload (bio, follower/following counts, stats), so an agent knows exactly what it returns. It does not explicitly differentiate itself from cross-platform siblings like instagram_profile or x_profile, but the TikTok scoping in name+description makes the boundary obvious in practice.

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 mention of when to prefer tiktok_video or the generic api_request, and no prerequisites. Usage is only implied by the platform named in the description; an agent must infer it from the tool 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?

Annotations already declare openWorldHint=true and destructiveHint=false, so safety is partly covered. But readOnlyHint=false is unusual for a data-fetch tool and the description never explains why (credit consumption? scraping/rate limits?), nor does it mention failure behavior beyond what the schema's region note implies.

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

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

One front-loaded sentence with zero filler; the resource and the input are stated immediately. Nothing to trim.

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?

An output schema exists and the input schema is fully documented, so return-value detail is not needed. However, for an open-world fetch tool with readOnlyHint=false, the description should at least signal cost/rate-limit/failure characteristics — that context 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% and the schema descriptions are richer than the tool description (region retry advice, trim envelope behavior, WebVTT transcript format). The description adds nothing beyond 'by URL', 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?

Specific verb + resource: retrieves post data for a TikTok video or photo-post given a URL. The scope (single post by URL) implicitly distinguishes it from tiktok_profile, but the description never names that sibling or states the boundary 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 / when-not-to-use guidance and no alternatives named, despite a crowded sibling set (tiktok_profile, api_request, get_endpoint_schema). The only implied condition is 'you have a post URL', which the agent must infer.

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

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

Annotations already declare openWorldHint=true and destructiveHint=false, so the description's main added value is the "public" qualifier, which signals that non-public profiles are out of scope. It does not mention the readOnlyHint=false flag or what side effects could occur, nor whether auth or rate limits apply. No contradiction: "Get" describes intent, not a guarantee of annotation semantics.

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

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

A single front-loaded sentence with zero waste. The accepted input formats are packed into the same sentence rather than a trailing list.

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?

An output schema exists, so return shape needn't be described, and for a one-parameter lookup the definition covers the essentials. Remaining gaps are edge-case behavior (private/suspended handles) and precise input formatting.

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 single `username` property has no description, so the description must carry the burden — and it does partially, by saying the value can be a handle or an x.com profile URL, which resolves the surprising mismatch between the parameter name and accepted URL input. It still omits whether an "@" prefix is accepted and what URL forms are valid.

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 ("Get a public X profile") plus the accepted input forms, which distinguishes it from the tweet-oriented siblings x_tweet/x_tweets. It never names a sibling explicitly, so differentiation is inferential rather than stated.

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

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

Usage is implied by the resource: fetch a profile rather than tweets or media. There is no explicit when-to-use vs. alternatives statement, and no guidance on what to do for private, suspended, or nonexistent accounts.

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

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

Annotations already declare openWorldHint=true and destructiveHint=false, so the description doesn't need to restate that this hits an external service. It does add genuine context with 'raw public' — the payload is the unmodified API object and only public posts are returned — but it says nothing about auth/quota cost or failure modes for missing or protected IDs, and notably does not explain the tension with readOnlyHint=false on an operation described as 'Get'.

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

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

A single front-loaded sentence with no filler. Every element — verb, cardinality, resource, 'raw', 'public', and the accepted identifier forms — carries 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?

An output schema exists, so return-shape explanation is rightly omitted, and the one parameter is covered in prose. What remains unaddressed is the behavioral envelope around an open-world call: rate limits, credential requirements, and what happens when the ID is unknown or the post is not public.

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

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

Schema coverage is 0%, so the description carries the burden for the single 'id' parameter, and it does: it tells the agent the value may be either a tweet ID or a status URL, which the bare `{"type":"string"}` schema does not convey. It could still be sharper about accepted URL forms or numeric-ID format, but the essential semantics are supplied.

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

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

The description gives a specific verb and resource ('Get one raw public X Tweet object') and quantifies the scope as a single object, which implicitly separates it from the plural sibling x_tweets and from x_profile. It stops short of naming the alternative explicitly, so an agent must infer the distinction rather than being told.

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?

'By ID or status URL' signals the intended calling context, so usage is implied. There is no statement of when to prefer this over x_tweets or x_profile, no prerequisites, and no exclusions (e.g. protected or deleted posts), leaving routing to inference.

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

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

Beyond the annotations, the description only says the objects are "raw" and "public," which hints at unfiltered API payloads. It discloses nothing about pagination (a cursor param exists), rate limits, or auth requirements for an openWorldHint tool. It also sits in tension with readOnlyHint=false: the verb "Get" reads as a pure retrieval, so an agent cannot tell whether calling it has side effects.

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 efficient sentence with no waste, and the key content (verb + resource + accepted input) is front-loaded. It is concise to a fault: the space saved is spent on nothing that would help an agent choose or call it.

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 output schema covers return shape, so return values need no prose. But with 0% schema coverage and no sibling differentiation, the description leaves an agent unable to decide between x_tweets, x_tweet, and x_profile, and unable to paginate via cursor — gaps the definition should fill.

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 carry the burden. "Handle or profile URL" usefully clarifies what the required url field accepts, but the cursor parameter — the only other input and the one governing pagination — is completely unmentioned in both schema and description.

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

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

"Get raw public X User and Tweet objects" names a retrieval verb and the resource types, which is better than a tautology. But it does not distinguish itself from the sibling tools x_profile and x_tweet, and it is unclear whether x_tweets lists a user's posts or returns a user-plus-tweets bundle, since the name says tweets and the description says "User and Tweet objects."

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 at all: nothing says when to pick this over x_profile, x_tweet, or the generic api_request sibling. The only contextual hint is "handle or profile URL," which implies input shapes rather than selection criteria.

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?

The annotations declare readOnlyHint=false, but the description frames the tool as a pure 'Get' retrieval and does not disclose what non-read-only behavior entails. This is a direct inconsistency between the description's implied read-only nature and the annotation.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately sized for a simple two-parameter retrieval tool.

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?

An output schema exists, so return details need not be explained, and the annotations carry some safety context. However, the description remains thin on usage context and contains no guidance about the non-read-only annotation.

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 the url and language parameters are already documented with clear descriptions. The description mentions only the URL and adds no meaning beyond what the schema provides, which is adequate given high schema coverage.

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

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

The description states a specific verb (Get) and resource (YouTube video or Short details) plus the input selector (by URL). It is clear, though it does not explicitly differentiate this tool from sibling platform-media tools such as tiktok_video or x_tweet beyond the platform 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?

It gives no when-to-use or when-not-to-use guidance. There is no mention of alternatives, prerequisites, or exclusions, so the agent must infer that this tool applies only when a YouTube URL is present.

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