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

With no annotations, the description carries the full behavioral burden and does well: it labels the operation a WRITE ACTION, states the confirmation gate, and ties it to the confirm parameter. It omits irreversibility, behavior when the status does not exist or is not owned, and rate limits, which keeps it short of a 5.

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

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

Two sentences, no filler, with the action and the safety gate front-loaded before the parameter requirement. 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?

For a destructive two-parameter tool with no annotations and no output schema, the definition covers the essentials an agent needs to act safely: what is deleted, the ownership constraint, and the confirmation gate. Failure modes and reversibility are the only notable omissions.

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 must compensate. It explains the semantics of confirm ('Requires confirm=true') but says nothing about status_id format or where it comes from, leaving half the parameters undocumented.

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 (Delete) plus resource (status) with a clear ownership scope ('one of the user's own statuses'), which separates it from get_status, post_status and favorite in the sibling list. An agent can identify the operation without opening the schema.

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

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

Gives an explicit precondition for invocation: call only after the user has explicitly confirmed this exact action and content in chat. It does not name alternative tools or describe what to do when confirmation is absent, but the gating condition is unambiguous.

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

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

With no annotations, the description carries the full burden and does disclose the key trait: this is a WRITE ACTION requiring explicit user confirmation and confirm=true, which is exactly the safety context an agent needs. It omits auth requirements, rate limits, and what happens if confirm is omitted/false (default false is only visible in the 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?

Two tight sentences with the core capability first and the safety gate second. No filler, and the critical constraint is capitalized and front-loaded rather than buried.

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 3-parameter write tool with no annotations and no output schema, the description covers the essential behavioral contract (write + confirmation). It would be fully complete with a note on return behavior or failure when confirm is absent, but nothing needed to invoke it correctly 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 0%, so the description must compensate, and it does: it explains the two meaningful values of 'action' ('create' vs 'destroy') and the required 'confirm=true' semantics, which the bare schema does not. 'status_id' is left unexplained but is self-evident from the purpose.

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 pair ('favorite/unfavorite a status') and clarifies that a single tool handles both directions via the action parameter. This distinguishes it from the sibling 'favorites' (a listing tool) and 'post_status'/'delete_status' without opening any schema.

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

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

Gives a clear gating condition: only call after the user has explicitly confirmed this exact action and content in chat, plus the confirm=true requirement. It does not name alternative siblings (e.g., 'favorites' for reading), but the when-to-use context is explicit and actionable.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies a non-mutating call, but pagination behavior (page/count interaction), result limits, ordering, and auth requirements are all unstated for a tool with three parameters.

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 short sentence, front-loaded with the resource and action, with the scoping rule appended. No wasted words, though the brevity is partly under-specification rather than pure 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, so return values need not be described, but with 0% schema coverage the description should compensate for the undocumented page/count parameters and lack of any read-only or auth statement. As written, an agent must guess at pagination semantics.

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%, and the description only clarifies one of three parameters (user_id defaults to the authenticated user). The meaning of 'page' and 'count' — units, defaults, interaction — is left entirely undocumented 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?

States a specific verb+resource ('Read ... favorited statuses'), which is clear on its own. It implicitly distinguishes from the sibling 'favorite' (the write action) but never says so explicitly, leaving a possible ambiguity between reading favorites and favoriting a status.

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 parenthetical 'empty = the authenticated user' gives a useful rule for when to omit user_id, but there is no guidance on when to use this versus home_timeline, user_timeline, or mentions. Usage is only implied by the resource name.

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

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

With no annotations provided, the description carries the full behavioral burden and does disclose the most important trait: this is a write action gated behind explicit confirmation and a confirm=true flag. It stops short of describing side effects on timelines, rate limits, or failure 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 sentences, zero waste, with the operation mapping and the safety guardrail both front-loaded. 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 mutation tool with no annotations and no output schema, the description supplies the critical confirmation protocol. Remaining gaps are minor: whether unfollow also requires confirmation, and what a failed or rejected call returns.

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 the two non-obvious parameters: action ('create'=follow, 'destroy'=unfollow) and confirm (must be true for the write). user_id is self-evident from the name, leaving only minor gaps.

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 the two specific operations (follow/unfollow) and maps them to the action values, fully disambiguating the opaque name 'friendship'. An agent can distinguish this from siblings like favorite or post_status without opening the schema.

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

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

It states a clear precondition for use: only call after the user has explicitly confirmed the exact action and content in chat. It doesn't name alternative tools or when-not-to-use cases, but no sibling overlaps with follow/unfollow semantics.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read-only operation, but nothing is said about ordering, reply depth, pagination, or authentication requirements for the reply chain.

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 compact sentence with no filler, and the scoping detail '(reply chain)' is front-loaded. It is arguably under-specified rather than verbose, but it wastes no 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?

An output schema exists, so return-value shape need not be explained, and the tool has only one parameter. However, with no annotations the description should say more about the reply-chain semantics (depth, ordering, pagination) to be fully callable.

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 the single required parameter status_id. The description only indirectly implies that the parameter identifies 'a status' and adds no format or source detail to compensate for the empty schema 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?

The description states a specific verb (Get) and resource (the conversation context / reply chain of a status), and the parenthetical '(reply chain)' disambiguates it from the sibling get_status, which retrieves the status itself. It is clear without opening the schema, though it never names the sibling it differs from.

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 and no mention of alternatives such as get_status or the various timeline tools. The agent must infer that this is for expanding a thread rather than fetching a single status.

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 reveals nothing about return shape, visibility/permission constraints (e.g., whether a private status returns an error), or error behavior for an unknown id. For a zero-annotation tool this is a notable gap.

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 concise to the point of under-specification, but nothing is redundant or buried.

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 one required parameter, no output schema, and no annotations, the description should have compensated for all three. Instead it supplies only a bare purpose statement, leaving an agent without enough context to know what a successful or failed call yields.

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?

One parameter at 0% schema description coverage. 'by id' loosely signals that status_id is an identifier, but nothing is said about its format (numeric vs. string id), where to source it, or whether it is required — the schema marks it required but the description does not reinforce this.

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 with a scoping qualifier: 'Get one status by id.' The phrase 'one status' implicitly contrasts with the timeline siblings that return many statuses, but it does nothing to distinguish itself from get_user, get_context, or post_status.

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 versus home_timeline, mentions, or get_context, and no prerequisites stated. The agent must infer that it needs a status_id it obtained elsewhere.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the empty-string default behavior, but says nothing about authentication requirements, whether the profile is public/private, or what happens on an unknown id, leaving the read-only safety profile only implied by the verb '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 tight sentence with the key behavioral detail (empty = self) front-loaded in parentheses. 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 simple one-parameter read tool with no output schema or annotations, the description covers the essential selection key and the default case. Adding auth or error-behavior context would make it fully complete, but the gap is minor at this complexity.

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

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

Schema coverage is 0% and the lone parameter has only a bare default of "", so the schema alone is uninformative. The description compensates by defining the id semantics and the special empty-value case, fully covering the single 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 a specific verb+resource ('Get a user's profile') and clarifies the retrieval key (by id). The parenthetical 'empty = the authenticated user' further sharpens scope, though it does not explicitly distinguish this lookup from timeline/status siblings.

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

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

Implies usage by explaining the empty-id case, which tells the agent how to fetch the caller's own profile. However, it gives no when-to-use/when-not guidance relative to siblings like user_timeline or verify_credentials.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a read operation and adds the 'count 1-60' constraint beyond the schema, but it omits authentication requirements, pagination behavior, and 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?

The description is very tight and front-loaded, using two short sentences with no wasted words. The fragment 'count 1-60' is slightly abrupt but informative.

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 read tool with an output schema and no annotations, the description is missing pagination semantics for max_id/since_id/page and any usage guidance. It covers the core purpose and count limit but is not complete enough to call the tool confidently without opening the schema.

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 four undocumented parameters. It adds a useful count range, but says nothing about page, max_id, or since_id, leaving most parameter semantics 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 states a specific verb and resource: 'Read the authenticated user's home timeline,' and parenthetically clarifies content as 'statuses from people they follow.' This distinguishes it from public timelines and mentions implicitly, but it does not explicitly name or differentiate from any sibling tool.

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

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

There is no guidance on when to use this tool versus alternatives like user_timeline, mentions, or public_timeline. The implied usage is clear from the purpose statement, but no exclusion or alternative routing is provided.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that results are scoped to mentions of the authenticated user and states the valid count range (1-60), which is genuine behavioral context, but it says nothing about pagination behavior, auth requirements, or result ordering.

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 followed by the one constraint worth surfacing. No filler, though it is arguably under-specified rather than optimally concise.

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 explained. For a simple read tool this is nearly adequate, but the total absence of parameter documentation and any usage/routing guidance leaves real gaps for an agent picking among many sibling feeds.

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 4 parameters (page, count, max_id, since_id). The description only documents the count range and leaves page, max_id, and since_id entirely unexplained, so the documentation gap is largely uncompensated.

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 statuses') and scopes it to those mentioning the authenticated user, which distinguishes it from the timeline siblings (home_timeline, user_timeline, public_timeline). It never names a sibling explicitly, but the 'mention the authenticated user' qualifier is enough to route correctly.

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 and no mention of alternatives. Given the crowded set of timeline/search siblings, an agent has to infer that this is the mentions-only feed rather than home_timeline or search_public_timeline.

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

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

With no annotations, the description carries the full burden and does disclose the key behavioral traits: this is a WRITE ACTION, it requires explicit user confirmation, and it needs confirm=true. It omits irreversibility, rate limits, and what the call returns, so not a 5.

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

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

Front-loaded with the action, then the optional threading params, then the safety constraint. Every clause carries information and nothing is padded.

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?

A write tool with no annotations, no output schema, and 0% parameter coverage needs more than this. The safety/confirmation guidance is solid, but the threading and repost parameters remain opaque and no return behavior is indicated.

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 4 parameters, so the description must compensate. It names in_reply_to_status_id and repost_status_id and flags confirm, but supplies no meaning, format, or valid-value guidance, and never explains the required 'status' parameter beyond the verb.

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 ('Post a new status'), which clearly distinguishes it from read siblings like get_status and destructive siblings like delete_status. It stops short of naming any sibling explicitly, but the purpose 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?

Gives an explicit when-to-call condition: only after the user has explicitly confirmed the exact action and content in chat, plus the confirm=true requirement. It does not name when-not to use it or route to alternative write tools (favorite, friendship), so it falls short of the top band.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies a safe read operation, but it says nothing about authentication requirements (Fanfou timelines typically need a session), rate limits, or ordering/refresh semantics, leaving real gaps for a network-backed tool.

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

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

Two short, front-loaded fragments with no filler; the purpose leads and the constraint follows. The second fragment ('count 1-60') is telegraphic, 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?

An output schema exists, so return values need no explanation, and the one parameter is at least bounded. Still missing are auth requirements and how this feed differs from the sibling timelines, which an agent needs to select 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 coverage is 0%, so the description must compensate for the single 'count' parameter. It usefully supplies the valid range (1-60) that the schema omits, but does not mention the default of 20 or what happens on out-of-range input, so the compensation is partial.

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 the latest public statuses on Fanfou,' which tells an agent exactly what data comes back. However, it offers no differentiation from close siblings like home_timeline, user_timeline, or search_public_timeline, so the agent must infer that 'public' means unauthenticated/global feed.

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 contrast against the five sibling timeline tools, and no prerequisites or auth context. The only supplemental text ('count 1-60') is a parameter constraint, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only discloses query operator syntax. It says nothing about auth requirements, rate limits, pagination behavior, or that this is a read-only lookup, which matters for a tool with a max_id cursor.

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 tight sentence with the resource up front and the syntax detail in parentheses. Nothing is wasted, though there is little content overall.

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, but with no annotations and 0% parameter coverage the definition should still cover pagination (max_id), result limits, and access constraints. Those omissions leave an agent unable to page or scope results reliably.

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% and there are three parameters. The description usefully explains the 'a b' AND / 'a|b' OR syntax for q, but count and max_id are left entirely undocumented in both schema and description, so pagination semantics are lost.

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 clear verb and resource ('Search public statuses by keyword') and the 'public' qualifier implicitly separates it from search_user_timeline and public_timeline. It stops short of explicitly naming which sibling to prefer, so it's clear but not fully differentiated.

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

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

There is no explicit when-to-use guidance, no mention of alternatives (e.g. search_user_timeline for a single account), and no stated prerequisites. Usage is only inferable from the word 'public' in the resource.

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 of behavioral disclosure and delivers very little. It does not state authentication requirements, rate limits, pagination behavior (relevant given a max_id param), or result ordering. Only the user_id default behavior is disclosed.

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 tight sentence with the scoping condition front-loaded and no filler. It is efficient but leans on the reader to infer the rest, which is under-specification rather than a structural flaw.

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, which lightens the burden. Still, four undocumented parameters, no annotations, and no mention of auth or pagination leave meaningful gaps for a search tool with a required query parameter.

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 largely does not. It explains only user_id's default semantics; q, count, and max_id are left with bare titles, and the pagination meaning of max_id (return results before this ID) is never conveyed.

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 (search) and a bounded resource (one user's statuses), and the parenthetical scope makes it clear this is a per-user timeline search rather than a global one. It does not explicitly name competing siblings like user_timeline or search_public_timeline, so differentiation is only implied by scope wording.

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

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

The parenthetical 'user_id empty = the authenticated user' gives a concrete default behavior an agent can act on. However, it never states when to prefer this over user_timeline (unfiltered list) or search_public_timeline (global search), so selection guidance is only inferable.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the read-only nature ('Read') and the count range constraint ('count 1-60'), but omits pagination behavior and auth requirements. Useful but incomplete for a no-annotation tool.

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

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

Three short, front-loaded clauses with no filler; the core purpose leads and constraints follow. Efficient, though its extreme terseness is what leaves the pagination parameters unexplained.

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 five parameters at 0% schema coverage and no annotations, the description is too sparse: the ID-based pagination fields (max_id, since_id, page) are essential to calling this correctly and are never described. An output schema exists, so return values need not be covered, but the input side remains under-specified.

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 must compensate for all five parameters. It clarifies user_id (empty = authenticated user) and count (1-60), but leaves page, max_id, and since_id entirely undocumented, and these cursor parameters are non-obvious without explanation.

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 ('Read a user's statuses'), which clearly maps to a timeline-fetch tool. It does not explicitly differentiate from close siblings like home_timeline or search_user_timeline, but the user_id default hint gives enough to separate it from the authenticated-user variants.

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?

'user_id empty = the authenticated user' implies when to use it for self vs. another user, which is genuine contextual guidance. However, there is no explicit when-to-use/when-not guidance relative to siblings such as home_timeline or mentions.

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 full burden, and it does disclose the read-only, no-side-effect nature plus what is returned. However it omits auth-failure behavior (e.g. what happens with an invalid token) and any note that this doubles as a credential check, which is the key trait of a verify endpoint.

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 short sentence, front-loaded with the return value and its scope qualifier. No filler, nothing repeated from structured fields.

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 read-only call with no output schema, the description gives what an agent needs: the returned entity and its authenticated scope. It is slightly thin on return shape and error behavior, but those are minor for a tool this simple.

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 the baseline of 4 applies; there is nothing for the description to disambiguate beyond what the empty schema already conveys.

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 authenticated Fanfou account') with the scope qualifier 'authenticated', which distinguishes it from sibling get_user. It doesn't explicitly name that sibling, so it falls short of the top mark.

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

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

Usage is only implied: the word 'authenticated' hints this is the identity/auth-check call rather than an arbitrary profile lookup. There is no explicit when-to-use or when-not-to-use statement and no reference to get_user as the alternative.

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