PenguinRadar

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds two genuinely extra behavioral facts: data provenance ('no online collection') and a staleness caveat ('counts may have a different observation time than lists') that an agent needs to avoid misreading counts against list results.

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

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

Three short sentences, front-loaded with the core purpose and then the two constraints. No filler, no restatement 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 return-value explanation is unnecessary, and annotations carry the safety profile. The description supplies the freshness caveat and data-source note, leaving only the sibling-routing guidance absent for a low-complexity single-parameter read.

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 username parameter is fully documented in the schema (including @ handling and length bounds). The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

States a specific verb+resource combination: reads 'stored profile information and follower/following counts'. The word 'stored' plus 'No online collection' implicitly separates it from the online-facing siblings, though it never names them directly, so the differentiation is left to inference.

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

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

'No online collection' implies this is the cached/offline path, which is meaningful given siblings like query_public_account and list_followers, but the description never states when to choose this tool over those alternatives. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: detectedAt is detection time rather than the exact Instagram action time, and the cursor must carry the list/dates/timezone to keep the page consistent.

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 dense sentences with zero filler, front-loaded with the resource and default window before the timestamp caveat and pagination mechanics.

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 description covers the default range, timestamp semantics and pagination contract. Only the limit parameter and list enum semantics go unexplained.

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 29%, so the description must compensate and partially does: it explains from/to defaulting, cursor continuation, and the list/timezone coupling. It never mentions limit or the followers/following semantics, leaving a real gap for a 7-parameter 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+resource: 'Read detected changes in your accessible tracking history'. The word 'changes' separates it from the sibling list_followers/list_following/list_tracking tools, though the description never explicitly contrasts itself 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?

Gives concrete context: the default window is the last seven calendar days UTC, and it explains the continuation condition ('for the next page send username and cursor'). No explicit when-not or named alternative sibling, 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?

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real behavioral context: it reads a snapshot/cache rather than triggering collection ('Never collects automatically') and warns results may be partial with an asOf timestamp. It stops short of explaining auth requirements or rate limits.

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

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

Two compact sentences with the purpose front-loaded, but the phrasing is opaque ('permitted public query cache') and the imperative 'State its asOf and partial coverage' is an odd instruction rather than a clean statement of behavior.

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 cover the safety profile. What remains missing is usage routing against siblings and any clarity on the snapshot-versus-cache distinction, leaving the definition adequate but with 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 67%, with username and cursor documented in the schema but limit undocumented. The description adds no syntax or format detail for any parameter; 'Read a page' only loosely signals pagination. Baseline 3 applies when the schema carries most of the burden.

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 (Read) and resource (a page of the follower snapshot), so an agent knows this returns followers rather than the following list, accounts, or changes. However, the phrase 'permitted public query cache' muddies what is actually returned and there is no explicit differentiation from siblings like list_following or query_public_account.

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 statement of when to use this versus the sibling tools (list_following, query_public_account, list_tracking). The 'Never collects automatically' note hints at a read-only/cache posture but is not framed as a usage condition or exclusion.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely non-obvious behavior: it never collects automatically, and its output may carry partial coverage tied to an asOf timestamp. That is useful context an agent cannot get from the annotations or 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?

Three terse sentences, front-loaded with the core action and resource. The middle sentence reads as an instruction to the caller ('State its asOf...') which is slightly cryptic, but nothing is wasted.

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

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

With an output schema covering return values and annotations covering safety, the description only needs to add operational context. It does add the no-auto-collection and partial-coverage facts, but it leaves the sibling-routing and any authentication/access prerequisites unstated, which matters for a tool named alongside four related account-data 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 coverage is 67% – cursor and username are documented in-schema, while limit is not, though its type, default, and min/max bounds are self-evident in the schema. The phrase 'Read a page' hints at pagination but the description adds no format or constraint detail beyond what the schema already shows.

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

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

States a specific verb+resource: reads a page of the most recent accessible following snapshot or public query cache. It implicitly separates itself from list_followers and query_public_account by specifying 'following' versus followers and by calling out the cached nature, but it never names a sibling explicitly.

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

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

The cached-snapshot framing implies this is for reading existing data rather than triggering collection, but there is no explicit when-to-use, when-not-to-use, or comparison against list_followers, list_tracking, or query_public_account. An agent must infer the choice from the resource name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: this reads cached stored data and incurs no collection charges. Pagination mechanics are left implicit, keeping it from a 5.

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

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

Two sentences, zero filler, and the core action is front-loaded before the cost/behavioral note. Every clause 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?

An output schema exists, so return values need not be spelled out, and the cursor's pagination role is documented in the schema itself. For a read-only list tool with full annotation coverage, the description supplies what the structured fields do not.

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

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

Schema description coverage is only 33%: 'cursor' is documented in the schema, but 'limit' and 'includeArchived' have no descriptions anywhere. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap as required at this level.

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 your tracked accounts') and even previews the payload ('profile counts and snapshot times'). It is distinguishable from list_followers/list_following by the word 'tracked', but it never names or contrasts a sibling explicitly, so it stops short of a 5.

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

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

Usage is implied rather than stated: the possessive 'your tracked accounts' and the 'without collection charges' phrase hint that this is the cheap stored-data path. There is no explicit when-to-use/when-not guidance or named alternative (e.g., get_account or get_account_changes), so an agent must infer the routing.

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

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

Adds substantial context beyond annotations: concrete credit burn (maxCredits ≥2 for a first list page, 1 for a next page), the authorization requirement per target/type/budget, and idempotency-key lifecycle guidance (generate before first attempt, reuse with identical arguments when restoring). This is consistent with readOnlyHint=false and idempotentHint=true and explains why the operation is not free.

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

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

Front-loaded with the core action and scope, then progressively adds cost, authorization and retry rules. Every sentence carries operational weight, though the dense run-on phrasing around credit thresholds takes a second read.

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 credit-consuming, idempotent, paginated read tool with an output schema already present, the description covers cost, auth, pagination discipline and retry safety. Minor gaps remain on failure/restore semantics and cursor origin, but nothing essential to a correct first call 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 only 20%, so the description has to compensate, and it does for maxCredits (per-page cost semantics) and idempotencyKey (lifecycle and reuse rule), plus cursor via 'next page'. It leaves 'type' enum values and cursor format unelaborated, but the critical cost/retry parameters are covered.

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

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

States a specific verb+resource (online query of a public profile or followers/following) and pins the scope to a single source page of ~25 people. The 'ONE page' framing implicitly distinguishes this from bulk siblings like list_followers/list_following without needing to name 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?

Gives clear usage conditions: explicit target/type/maxCredits authorization, credit cost thresholds per page, and explicit negatives ('never automatically fetch all pages or increase budget'). It stops short of naming alternative siblings (e.g. get_account) for cached or non-credit reads.

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