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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one useful behavioral fact: the counts come from the 'configured' account, implying no account argument and no selection step. It says nothing about freshness, rate limits, or failure when no account is configured.

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 word carries information, and the returned fields 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?

With an output schema present, the return structure needn't be described, and a zero-parameter read tool does not need much more. Only the missing sibling routing keeps this from being 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 schema has zero parameters, so the baseline is 4. Nothing in the description is needed to compensate for parameter documentation, and it correctly implies no inputs are required.

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 resource (the configured Instagram account) and enumerates exactly what it returns: follower, following and post counts. This is clearly distinct from data-heavy siblings like instagram_recent_media, 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?

There is no guidance on when to use this versus instagram_recent_media or instagram_hashtag_top_media, and no stated prerequisites. The reader can infer it is a stats snapshot, but nothing routes them here or away from a sibling.

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 openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful constraint the annotations do not carry: a quota of 30 unique hashtag lookups per 7 days, which affects how an agent should budget calls.

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-loaded with the core purpose and zero filler. It is efficient, though the extreme brevity leaves semantics unaddressed rather than being purely a strength.

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 the rate limit is disclosed. However, for a tool with 0% schema coverage on its parameters, the description omits the hashtag input format, which an agent needs 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?

Schema description coverage is 0% for two parameters. The description never explains whether 'hashtag' should include a leading '#', nor what 'limit' controls (default 10, max 50), so it fails to compensate for the schema 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 names a specific verb+resource ('Top posts for a hashtag'), which is clearly distinct from account-oriented siblings like instagram_recent_media and instagram_account_overview. It stops short of explicitly naming an alternative, but the scope is 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?

There is no guidance on when to use this tool versus instagram_recent_media or other siblings; the only context offered is a quota constraint. The agent must infer that this is the hashtag-scoped lookup path.

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 openWorldHint=true, so the safety profile is covered. The description adds useful output context by naming engagement rate, outliers, and per-format averages, but it does not disclose auth requirements, rate limits, pagination, or how the limit parameter affects 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?

The description is two short sentences and front-loads the core output description. The second sentence adds a focused interpretive note about the per-format split without unnecessary detail.

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-only tool with one optional parameter and an output schema, the description is largely complete: it explains what data is returned and highlights the most actionable metric. It leaves a minor gap by not relating the tool to sibling Instagram tools or explaining the limit parameter, but the schema and annotations cover the critical invocation 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?

The sole parameter 'limit' has 0% schema description coverage, and the description does not mention it at all. The schema provides type, default, minimum, and maximum, which makes the gap less severe, but the description does not compensate for the missing semantic explanation of how many posts are returned or when to adjust the limit.

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 resource and data scope: recent Instagram posts with engagement rate, outliers, and average engagement per format. It is clear what the tool returns, but it does not explicitly differentiate itself from sibling tools like instagram_account_overview or instagram_hashtag_top_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 statement that the per-format split is usually the most actionable number implies the tool is useful for Reels-vs-feed comparison. However, it gives no explicit when-to-use guidance and does not name alternatives such as instagram_account_overview or instagram_hashtag_top_media.

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 openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the annotations: no note about public-data-only access, rate limits, or what happens with an invalid channel, and since an output schema exists the return shape need not be restated.

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 sentence with zero filler and the key metric scope front-loaded. It is efficient, though the terseness borders on under-specification for a tool with no usage guidance.

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 an output schema covering return values and annotations covering safety, the main missing piece is usage guidance and any auth/quota caveats. For a simple single-parameter read tool this is minimally adequate 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% and the single 'channel' parameter is documented in the schema with both forms ('UC...' or '@handle'). The description adds no parameter detail, 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?

The phrase 'Subscriber, view and upload totals for a YouTube channel' names the resource and the exact metrics returned, so an agent knows this is a stats-summary tool rather than a listing tool. It lacks an explicit verb and does not name which sibling (e.g. youtube_recent_uploads) it differs from, but the metric scope is distinctive enough to separate it from the other youtube_* 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 when-to-use guidance, no prerequisites (e.g. requiring a valid channel ID/handle), and no mention of alternatives among the youtube_* or instagram_* siblings. The agent must infer usage entirely from the metric list.

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 and openWorldHint, covering safety and external data access. The description adds that results include engagement rate and median comparison, useful output context, but omits freshness, rate limits, or auth needs.

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

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

Two sentences, front-loaded with what the tool returns and immediately followed by the intended use case. No filler or repetition.

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 output schema and annotations, the description need not explain return values or safety. However, it lacks guidance on choosing this over sibling tools like youtube_channel_overview or youtube_search_videos, and does not address max_results.

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 50%: channel is well described, but max_results has no description in schema or tool description. The description contributes no parameter guidance and does not compensate for the undocumented max_results parameter.

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 it returns latest uploads with views, engagement rate, and median-beating videos, a specific resource and metric set. It does not explicitly name sibling tools like youtube_channel_overview, but the name and metric focus make its scope 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?

Provides an explicit use case: answering 'what is working on this channel right now.' It gives clear context but no exclusions or named alternatives such as youtube_channel_overview or youtube_search_videos.

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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds genuinely valuable context the annotations lack: the ~101 quota-unit cost and the recommendation to keep queries narrow, which tells the agent to budget calls carefully. It doesn't cover pagination or the statistics returned, but the quota disclosure is meaningful.

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-loaded with the tool's function and then the cost caveat. No filler or restated 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?

An output schema exists, so return values needn't be explained, and the cost hint is valuable. But for a 5-parameter search tool with only 40% schema coverage, the description omits any parameter guidance and any sibling differentiation, leaving clear gaps.

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

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

Schema description coverage is only 40%, so the description should compensate but adds no parameter meaning at all. region_code and published_after are documented in the schema, but order and max_results are undocumented in both places, and nothing in the description clarifies enum choices or result limits.

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 (Search) and resource (YouTube videos) plus the return shape (with statistics). It is clear what the tool does, but it does not distinguish itself from siblings like youtube_recent_uploads or youtube_video_details, leaving the agent to infer that search is query-driven rather than feed-driven.

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 cost note ('prefer narrow queries') gives useful operational guidance, implying this is an expensive, last-resort-style call. However, it never states when to use this over the sibling tools (e.g., use recent_uploads for a known channel), so routing guidance is only implied.

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

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

readOnlyHint and openWorldHint already tell the agent this is a safe external read. The description adds the useful distinction that only top-level comments (not replies) are returned, but says nothing about pagination, ordering defaults, or quota/rate 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?

Two short sentences with the scope stated first and the use case second; nothing is wasted, though it is arguably a bit thin given the undocumented parameters.

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. For a simple three-parameter read tool this is close to adequate, but with 0% parameter coverage and no usage exclusions, an agent still has gaps about ordering and result limits.

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 carries the full burden, yet it mentions none of the three parameters (video_id, order, max_results). The only implicit signal is "top-level," which loosely relates to the relevance/time ordering, leaving the enum and the 1-100 max_results bounds undocumented in prose.

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 the specific resource and scope: top-level comments on a video, which clearly separates it from youtube_video_details and youtube_channel_overview. It lacks an explicit verb (list/fetch), but the noun phrase is unambiguous enough for selection.

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?

"Useful for audience sentiment and content ideas" gives a motivation for calling it, but there is no when-not guidance and no mention of the sibling tools that fetch video metadata or search results. Usage is implied rather than specified.

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 and openWorldHint, so the safety profile is covered. The description adds useful context about the data fields returned (statistics, duration, tags) and the batch limit of 50, but does not cover other behavioral traits like rate limits or authentication.

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 that efficiently conveys the key information (what is returned and the batch limit) with no wasted words.

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

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

Given the presence of an output schema and annotations, the description covers what the tool does and its batch limit. However, it lacks usage guidance for selecting this tool over siblings, leaving a gap for an agent to infer when to invoke it.

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 for parameter semantics. It only repeats the parameter name ('video IDs') and a constraint already in the schema (max 50), without explaining the expected format (e.g., YouTube video ID strings) or any other details.

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 what data is returned (statistics, duration, tags) and the resource (video IDs), distinguishing it from sibling tools like channel overview or comment retrieval. No explicit verb, but the purpose is clear from context.

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

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

No guidance on when to use this tool versus alternatives such as youtube_recent_uploads or youtube_search_videos. The description implies usage when you have video IDs, but no explicit conditions or exclusions are provided.

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