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

Annotations already declare readOnly, idempotent, and openWorld, so safety is covered. The description adds real context beyond them: the backing endpoint is the public syndication API, long posts are auto-enriched when truncated, and conversation context is out of reach. It doesn't mention rate limits or failure modes (deleted/protected posts), which would round this 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?

Front-loaded with the verb and action, then behavior, then limits — a sensible order with no filler. The enumerated return fields (author, timestamp, metrics, media, card, quoted post) partially duplicate the output schema, which costs a little space.

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?

Covers input forms, default enrichment behavior, and the thread/reply limitation, which is the main trap for this tool. Since an output schema exists, the return-value paragraph is surplus but harmless; adding guidance on when to prefer get_tweets would make it 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?

Schema description coverage is 100%, so all five parameters are already documented, including enrich, include_raw, resolve_links, and include_quoted. The description's mentions of enrichment and resolved t.co links describe output rather than adding constraints or defaults beyond the schema, so it sits at the baseline.

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 ("Fetch one X/Twitter post by ID or URL") and clarifies scope with "returns one post, not a thread," which separates it from get_tweets and search_tweets by cardinality. It stops short of naming any sibling explicitly, so differentiation is inferred 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?

The closing note — "The public syndication endpoint returns one post, not a thread. Replies and the rest of the conversation are not available" — is a genuine exclusion that tells an agent when this tool will fail. It never names the alternative tools (get_tweets, search_tweets) to use instead, leaving the routing step 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and repeatability are covered. The description adds genuinely new behavioral context the annotations do not: partial-failure semantics where individual bad IDs return per-item errors without failing the whole batch. It does not mention rate limits or ordering, but the added disclosure is substantive.

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, zero filler, with the core purpose front-loaded and the failure-mode note following as supporting detail. 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?

Output schema exists and the input schema is fully documented, so the description only needs to add the non-obvious behavior — which it does via batch partial-failure semantics. Minor gap: no hint about ordering of results, deduplication, or when the batch size limit should push the agent to split calls, but nothing critical 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 description coverage is 100%, including the 1-25 item bound, URL-or-ID acceptance, and each enrichment flag, so the schema carries the parameter burden. The description adds no syntax or format guidance beyond that, which is the expected baseline when schema coverage is complete.

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 ('Fetch multiple posts') and makes the batch scope explicit with 'in one call', which implicitly contrasts with the singular get_tweet sibling. It does not name get_tweet or search_tweets, so the differentiation is inferable 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 only implied: 'multiple posts in one call' suggests batching rather than a single-post fetch, but the description never says when to prefer this over get_tweet, search_tweets, or get_user_tweets. No prerequisites or exclusions are given.

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 readOnly/idempotent/openWorld, so the bar is lower; the description adds genuine negative-space information by stating the data comes from the public profile page and that follower/following counts are unavailable. It does not mention behavior for private, suspended, or nonexistent accounts, which is the main remaining 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?

Three short sentences, front-loaded with purpose, zero filler. The enumeration of returned fields (display name, bio, avatar, banner) is somewhat redundant given an output schema exists, costing it a point.

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 single-parameter read with an output schema, the description covers purpose, scope, and data limitations adequately. It stops short of covering failure modes (nonexistent or protected accounts), which would matter for a public-data lookup.

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 username parameter already documents the 'without @' convention, so the description adds nothing beyond the schema. 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 ('Read public profile metadata for an X account') and immediately narrows scope to the public profile page. An agent can distinguish this from the tweet-oriented siblings (get_tweets, get_user_tweets) without inspecting schemas.

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 scope statement (public profile only), but there is no explicit statement of when to prefer this over get_user_tweets or search_tweets, and no prerequisites or error conditions are named.

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 readOnly, idempotent, openWorld, so safety is covered. The description adds the useful fact that results are filtered to exactly one author, but leaves open whether retweets/replies are included and says nothing about pagination caps (page 1-9, limit 1-30) or rate-limit 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, front-loaded with the purpose and followed by the implementation relationship. Nothing is wasted 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 a full parameter schema and an output schema present, the description has little structural burden, but it is silent on retweet/reply inclusion semantics ('exactly that author' is ambiguous) and pagination depth, which are the remaining facts 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 coverage is 100%, so every parameter including freshness, sort, enrich and include_quoted is already documented inline. The description only maps the required username into the from: operator, which is a small addition over the schema — 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 (fetch recent posts from one X account) and explicitly positions itself relative to search_tweets. It does not distinguish itself from get_tweets, the other obvious sibling for retrieving posts, so an agent must still infer that difference.

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 the use case — you know the author handle and want only their posts — and names the alternative (search_tweets with from:<username>), making the two interchangeable by construction. No explicit when-not guidance or note about when get_tweets would be preferable.

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 read-only, idempotent, open-world profile, and the description goes well beyond them: it discloses the hydration pipeline and what fields it yields, the indexing lag on fresh posts, the search backend chain and the BRAVE_API_KEY auth requirement, and the speed cost of link resolution and enrichment. That is exactly the extra context annotations cannot carry.

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?

Core behavior and the recency caveat are front-loaded in the first two paragraphs. The third paragraph about matching OpenCode's keyless Exa/Parallel endpoints is backend trivia that does not help an agent decide or invoke, and could be trimmed.

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 9 parameters, an output schema, and full annotation coverage, the description supplies the needed mental model: index-based search, hydration output shape, latency knobs, and freshness limits. Minor gaps remain around pagination semantics (page vs limit vs sort) and how X operators combine with freshness, which the schema alone handles.

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 baseline is 3; the description earns an increment by explaining that results are hydrated into full text/author/date/metrics/media, which gives real meaning to the hydrate and enrich flags and their performance trade-off. Page/limit/sort interactions and the 1-9 page cap remain schema-only.

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 ('Search X/Twitter posts') plus the mechanism ('through public web indexes'), and explicitly contrasts it with X's live search, which separates it from get_tweet/get_user_tweets-style tools. It never names a sibling as the alternative, so differentiation is by implication rather than explicit routing.

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 context is implied rather than prescribed: the note that very recent posts may not be indexed hints at when this tool will under-perform, but there is no explicit 'use get_user_tweets for a timeline' or 'use get_tweet when you already have an ID'. The backend/fallback narration describes internals, not selection 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the description only needs to add context — and it does, with 'Does not require any credentials', which is meaningful operational information not present in the annotations. It does not restate cost details for live checks (those live in the schema), so it is not fully rich, but it adds real value beyond structured data.

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: purpose first, then the credential constraint, then the parameter trigger. Every sentence earns its place and nothing is padded. Minor deduction for the awkward line breaks and the unexplained 'Xearch' 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?

With only one optional parameter at full schema coverage and an output schema present, the description need not explain return values. It covers purpose, credentials, and the flag's use case, leaving only minor gaps such as whether live checks can fail/timeout or what the tool does not validate.

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 live runs reachability checks and costs one search request. The description adds a decision-oriented trigger ('when debugging a failing tool call') that the schema does not provide, which is genuine value on top of the 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?

States a specific verb and resource: reports configuration, caches, and optional endpoint checks. This is clearly a diagnostic tool, distinct in kind from the data-retrieval siblings (get_tweet, search_tweets, get_user), though the description never explicitly names them. The term 'Xearch' is slightly odd/unexplained but the resource being inspected is still 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?

"Use live=true when debugging a failing tool call" gives a concrete decision trigger for the optional flag, which implies the tool's role as a first-line diagnostic. It lacks any explicit when-not/alternatives statement (e.g., 'use get_user instead to verify a user exists'), so it falls 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.