Lodestone

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that: newest-first ordering, aggregation across all connected networks, and the shape of each returned chat. No pagination or result-count behavior is described, 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?

One sentence, front-loaded with the verb and resource, with the parenthetical supplying exactly the cross-network context an agent needs. Nothing is padded or redundant.

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 no output schema, the description usefully names the returned fields and ordering, which is what an agent needs to consume the result. It is slightly thin on pagination and on how the optional query/account filters interact with 'recent', but it is otherwise complete for a 3-parameter read tool.

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 limit, query and account are all fully documented in the schema itself. The description only gestures at the network concept via the parenthetical; it adds no format, default or example detail beyond the schema. Baseline 3 is correct where the schema does the heavy lifting.

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 ('List your recent Beeper conversations') and adds scope details: cross-network aggregation, newest-first ordering, and the three returned fields (ID, title, network). It doesn't explicitly differentiate from the sibling beeper_read_chats, which is the main reason it isn't 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?

The word 'recent' and the cross-network framing imply this is the browse/discovery entry point, and the query/account params hint at filtered variants, but the description never states when to use this instead of beeper_read_chats or beeper_search. Usage is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: the ordering guarantee (newest last) and the content shape (who said what). It omits any mention of permissions, rate limits, or truncation behavior, keeping it out of the top tier.

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; the purpose, return shape, and motivating context all arrive in one pass.

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 read-only tool with no output schema, annotations covering the safety profile, and full schema coverage, the description supplies enough to call it correctly and interpret the result order. It could be marginally richer about what happens when the conversation is empty or the limit is hit, but nothing essential 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%, so both parameters (chatID origin, limit default/cap) are already fully documented in the schema. The description adds no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 recent messages in one Beeper conversation) plus the return shape (who said what, newest last). This clearly distinguishes it from sibling beeper_list_chats, beeper_search, and beeper_send_message without needing to open 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?

"so you have the context before replying" gives a clear triggering condition and implicitly routes to beeper_send_message as the follow-up action. It does not explicitly exclude alternatives or name the sibling, so it falls short of the 5 tier.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the 'across all your messages' scope but says nothing about result format, ordering, or the hard cap beyond what the annotations/schema provide, so it is adequate rather than rich.

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, front-loaded with the verb and resource, with no wasted words. The examples earn their place by illustrating query types.

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 read-only search tool with full schema coverage and annotations covering the safety profile, the description gives an agent enough to invoke it correctly. It could mention result ordering or that results are per-message, 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%, so every parameter is already documented. The description loosely signals the chatID and sender dimensions ('limited to certain chats or to messages from other people'), which reinforces but does not meaningfully extend the schema, making the baseline of 3 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?

Specific verb (search) plus resource (all your Beeper messages) and concrete query examples ('an address someone sent, a confirmation number') make the purpose immediately clear. It doesn't explicitly contrast with siblings like beeper_read_chats, 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?

The phrase 'optionally limited to certain chats or to messages from other people' hints at scoping usage, but there is no explicit when-to-use versus alternatives (e.g. beeper_read_chats for reading full threads) and no when-not 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 declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is partly structured. The description adds real value with '[sends a real message to a real person]', emphasizing the irreversible human-facing consequence, plus the explicit confirm:true safety gate and the read-first requirement. It does not describe failure modes or rate limits, but the impact framing is strong.

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 compact sentences, front-loaded with the bracketed write/safety tag before the action. Every clause earns its place; nothing is redundant padding.

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 no output schema and full parameter coverage, the description supplies the key context an agent needs: it's a real write, it needs a prior read and user confirmation, and confirm:true is mandatory. Return-value behavior is unspecified, but for a write gate that is a minor omission.

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 the schema already documents chatID, text, confirm, and replyToMessageID fully. The description only echoes the confirm:true requirement already spelled out in the confirm parameter description, adding no new syntax or format detail. 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?

States a specific verb+resource: 'Send a text message to one of your Beeper conversations.' The '[WRITE]' tag immediately frames it as a mutation, and it is trivially distinguishable from the sibling read tools (beeper_list_chats, beeper_read_chats, beeper_search) and from the cross-channel telegram_send_message.

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 workflow prerequisites: 'You must have read the thread first and confirmed the exact text with the user. Requires confirm:true.' This tells the agent both when the tool is appropriate and what must precede it. It does not explicitly contrast with alternatives (e.g., email_send / telegram_send_message), but the channel is fixed by the tool itself, so this is a minor gap.

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 destructiveHint=true and openWorldHint=true, so the description earns credit for adding genuinely new behavioral context: credentials are validated against the real provider before saving, failures return the specific reason, and credentials must never be echoed back. These details go well beyond the structured fields.

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 sentences, front-loaded with the primary action and instructions, with no filler. The parenthetical slightly interrupts flow but every clause carries actionable content.

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, open-world write tool with no output schema, it covers validation, failure handling, field sourcing, and credential privacy. It omits what happens on success or whether an existing connection is overwritten, but remaining gaps are minor.

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

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

Schema coverage is 100%, so both params are already documented (baseline 3). The description adds real meaning by specifying that field names must come from integration_guide, clarifying the nested 'fields' object's expected keys beyond the schema text.

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 ('Connect one of the user's accounts') and clarifies the mechanism (values pasted in chat). It distinguishes itself from the external-website path and routes to the sibling integration_guide for field names, so an agent can identify it without inspecting 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?

Explicitly states the supported usage ('values they pasted in this chat'), the exclusion ('do not send the user to a website instead'), and the prerequisite/discovery source ('Field names come from integration_guide'). This is the when/when-not/alternative guidance an agent needs.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by specifying what is destroyed (the saved credentials for a single account) and confining scope to "one of the user's accounts." It does not say whether the deletion is reversible or whether re-authentication is required.

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 destructive action front-loaded and the usage condition immediately after. Nothing could be cut without losing meaning.

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 one-parameter destructive tool with strong annotations and no output schema, the description covers action, target, and trigger condition adequately. Minor gap: it does not state that disconnecting requires reconnection via connect_integration, nor whether credential removal affects linked automations.

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 single parameter already carries an example ("email, telegram"). The description's "one of the user's accounts" loosely frames the parameter but adds no format or constraint detail beyond the schema, 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 and resource: "Remove the saved credentials for one of the user's accounts from Lodestone." An agent knows exactly what is being deleted and from where. It stops short of naming the inverse sibling (connect_integration), but the phrasing "disconnect or replace an account" ties it to that pair clearly enough.

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 only when the user asks to disconnect or replace an account" gives an explicit trigger condition and a restrictive "only" that discourages incidental use. It does not name the alternative tool (connect_integration) for the opposite operation, so routing is implied rather than spelled out.

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/openWorld/non-destructive safety, lowering the bar. The description adds genuinely novel context beyond them: that message_id is an IMAP uid scoped to the folder it was found in, not the Message-ID header. It still says nothing about ordering guarantees or pagination 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 filler, purpose front-loaded before the id-semantics clarification. Each 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?

There is no output schema, so the description partly compensates by explaining the returned message_id semantics. That is the key detail an agent needs to chain into email_read, though ordering and return shape remain unstated.

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 defaults and the max-50 cap, so the description adds no parameter detail the schema lacks. 'Default INBOX' merely restates the schema. Baseline 3 applies when the schema carries parameter semantics.

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 the most recent emails in a folder') and names the default scope (INBOX). However, it never distinguishes itself from the sibling email_search, which an agent must choose between when retrieving mail.

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 guidance on when to use this versus email_search or email_read. The only usage hint is the implied default folder. An agent has to infer the intended retrieval strategy on its own.

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, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds real context on top: the id is an IMAP uid 'scoped to the folder it was found in — not the email's Message-ID header,' which is a meaningful behavioral caveat. It omits auth requirements 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?

Two tightly written sentences with no redundancy: the purpose is stated first and the parameter caveat second. 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 read-only, two-parameter tool with no output schema, the description covers the return value ('full text of one email'), how to obtain the uid, and the folder scoping. Minor gaps like auth requirements remain, but nothing needed to call 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 100%, setting a baseline of 3, but the description goes further by explaining that message_id is an IMAP uid from the listed tools and is folder-scoped, not the Message-ID header. That is semantic value beyond the schema text.

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 the full text of one email ... by its uid.' The 'one email by uid' framing implicitly distinguishes it from the sibling search/list tools, but it never explicitly names them as the alternative.

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 description points to email_search and email_list_recent as the sources of the uid, which implies when this tool is used. However, it gives no explicit when-to-use vs when-not guidance or conditions that would route an agent here over 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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: message_id is an IMAP uid, not the Message-ID header, and it is folder-scoped — a real misuse trap an agent would otherwise fall into.

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 does, followed by the identifier caveat. No filler. The second sentence concerns message_id, which is not a parameter of this tool, so it sits slightly outside the tool's immediate scope, but it is contractually useful.

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 no output schema, the description does not describe the returned shape, but it implicitly signals that results carry a message_id usable downstream, and annotations cover the read-only/open-world profile. Adequate for an agent to call correctly, with the return format the only real gap.

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 the baseline would be 3. The description earns an extra point by clarifying what the 'query' parameter actually searches (From, Subject and body), which the schema only calls 'Text to search for'. It adds no detail for limit or folder, but those are fully specified in the schema.

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

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

States a specific verb (search) and resource (connected email account messages) and specifies the searched fields (From, Subject, body). It is distinguishable from email_read and email_list_recent by describing query-based matching, though it never explicitly contrasts itself with those 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?

By noting that message_id comes 'from email_search or email_list_recent', it implies a workflow and hints these two are related entry points, but it never states when to prefer this tool over listing recent mail or reading a specific message. Usage is inferable rather than explicit.

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=false, openWorldHint=true, and destructiveHint=true, so the agent knows this is an outward-facing write. The description adds the useful constraint that only plain-text is supported and that mail comes from the connected account, but says nothing about irreversibility, delivery confirmation, 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?

One short sentence, front-loaded with the verb and resource and free of filler. It is efficient, though its brevity leaves no room for the usage context a mutation tool would benefit from.

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 3-param write tool with rich annotations and full schema coverage, so the safety and input story is largely covered. However, no output schema exists and the description says nothing about what happens after the send or how failures are surfaced, leaving it merely adequate.

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 to/subject/body are already documented in the schema. The description's 'plain-text' note loosely reinforces the body constraint but adds no syntax, format, or multi-recipient detail beyond what the schema provides.

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 (send) and resource (email) with a scope qualifier (plain-text, from your connected account). The action verb clearly separates it from sibling email tools like email_list_recent, email_read, and email_search, but it never names those siblings 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 description offers no when-to-use guidance, no prerequisites, and no alternatives. It does not say when to prefer this over beeper_send_message or telegram_send_message, nor mention any constraint such as needing a connected account before calling.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine non-structured context beyond that: results are limited to properties the connected service account can read, which tells the agent why some properties may be missing. It does not mention pagination or result volume.

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

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

A single sentence, front-loaded with the verb and resource, with the access-scope caveat folded in rather than padded out. 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 simple zero-parameter list tool with no output schema, the description covers purpose, scope and the returned identifier. It stops short of describing the full response shape (e.g. display names, account nesting), which is the only remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly signals the no-argument nature by not implying any filters.

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 (List) plus resource (GA4 properties) with a clarifying gloss of what a property is (sites/apps) and what identifying data comes back (property ids). It is distinguishable from the report-running siblings ga4_run_report and ga4_realtime_report, though the description never names them 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?

Usage is only implied: an agent can infer this is a discovery step to obtain property ids before calling ga4_run_report, but the description never states when to use it, when not to, or that it is a prerequisite for the report tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context – that data is realtime and bounded to a 30-minute window – which is the defining trait of this endpoint versus a standard report, though it omits things like data latency, sampling, 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?

Single well-formed sentence with the resource and its scope front-loaded; no filler, no restatement of the 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?

For a no-required-param, output-schema-less reporting tool, the description conveys what the call returns (active users broken down by a chosen dimension) and the recency window. It is reasonably complete, with only minor gaps around return format and the relationship to sibling GA4 tools.

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

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

Schema description coverage is 100% and each parameter (limit, filter, metrics, minutes, dimensions, property_id) is documented with defaults and examples, so the schema carries the load. The description's mention of country/page/traffic-source/device breakdowns loosely echoes the dimensions parameter but adds no syntax or format detail beyond the schema.

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

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

States a specific verb+resource (realtime active users in GA4) plus the exact scope: a 30-minute window broken down by country, page, traffic source or device. An agent can immediately distinguish this from the historical ga4_run_report sibling.

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 realtime framing implicitly tells the agent this is for 'right now' monitoring versus historical reporting, but it never names ga4_run_report or ga4_list_properties as alternatives, nor states when-not to use it. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that the report targets the user's own site — nothing about GA4 quota/rate limits, sampling, or latency for large queries, which would be genuinely useful for a live external API.

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

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

A single sentence with a front-loaded verb, a colon-delimited operand list, and one worked example. No filler, and the highest-value information (what it does, what it accepts) comes first.

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 fully-documented optional parameters and annotations carrying the safety profile, the description needs to establish scope and it does. The absence of return-shape detail is acceptable since no output schema exists, though nothing explains what a result row looks like.

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 the baseline is 3. The description's example filter ('sessionSource==instagram') and date phrasing ('over the last 28 days') are illustrative rather than additive syntax the schema lacks; the filter operator grammar lives in the schema, not the 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 ('Run a Google Analytics 4 report') scoped to 'your own site', and enumerates the operands (dimensions, metrics, date range, filters). An agent can distinguish it from ga4_realtime_report and ga4_list_properties 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?

The embedded example ('sessions and conversions from Instagram by landing page over the last 28 days') gives concrete when-to-use context, and the schema note routes property discovery to ga4_list_properties. However, it never says when to prefer ga4_realtime_report or states any 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 declare readOnlyHint=false, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful output detail 'Returns the image inline' (valuable since there is no output schema), but says nothing about cost, latency, rate limits or prompt restrictions.

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 naming the model, its characteristics and its return behavior. No filler or repetition of the title.

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

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

With no output schema, the 'returns the image inline' note fills the main return-value gap, and the model characterization is a genuine differentiator. Missing only guidance on when to choose this over the sibling image models.

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 both the prompt and the enum-constrained aspect_ratio are already documented in the schema. The description adds no parameter-level detail (no prompt length guidance, no default aspect ratio), so the 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 (generate) and resource (image) plus the exact model variant (FLUX1.1 [pro]), which distinguishes it from sibling generators generate_image_nano_banana and generate_image_seedream. An agent can select it 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 lists suitable use cases (art, product shots, concept art) and speed/quality traits, which implies when this model fits, but it never names the sibling image generators or states when to prefer nano_banana or seedream instead. Usage is implied rather than guided.

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 only declare readOnly=false, openWorld=true, destructive=false. The description adds the operationally critical traits annotations cannot express: it is SLOW (~30-40s), it returns the image inline, and it prescribes a pre-call UX step to avoid the wait looking like a hang.

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 capability and differentiators, then the return behavior, then the latency warning and the action to take. Every clause carries information; no filler.

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?

There is no output schema, but the description compensates by stating the image is returned inline and how long it takes. Combined with 100% schema coverage on both parameters, an agent has everything needed to call and wait 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 100% with 2 parameters, and the enum of aspect ratios is fully documented in the schema. The description adds no format, syntax, or constraint detail beyond the schema, 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 ('Generate an image') and pins down the exact backend (Google's Nano Banana / Gemini 3 Pro Image), which distinguishes it from the sibling generators generate_image_flux and generate_image_seedream. It also names the domains where it wins (photorealism, legible text, complex compositional prompts), so an agent can choose without opening 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?

Gives explicit selection criteria ('best for photorealism, legible text in the image, and following complex/compositional prompts') that route the agent among the image-generation siblings. It also adds a concrete invocation-time instruction: tell the user it is generating ~30 seconds BEFORE calling, so the wait is expected.

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 safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description usefully adds that the image is returned inline, which matters since there is no output schema, but it omits cost, latency, or how inline data is encoded.

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 that front-loads the action and model, then adds the differentiator and the return behavior with no filler.

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 no-output-schema generation tool the description covers what the agent most needs — the model, its strengths, and that the image comes back inline. Only minor gaps remain, such as resolution specifics or latency expectations.

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?

With schema description coverage at 100%, both parameters (prompt and aspect_ratio's enum) are already fully documented in the schema. The description adds no syntax, format, or constraint detail beyond that, so baseline 3 applies.

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

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

States a specific verb (Generate) and resource (an image), and names the underlying model (ByteDance Seedream 4.5), which cleanly distinguishes it from the sibling tools generate_image_flux and generate_image_nano_banana.

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

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

The phrase 'high-resolution, strong at people, scenes and cinematic looks' gives an implicit selection criterion for choosing this model over its two image-generation siblings. It stops short of an explicit when-to-use statement or exclusions, 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.

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds critical traits annotations cannot convey: ~90s latency, client timeout risk, a returned link, and the billing consequence of retrying after an apparent failure.

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 what it does and what it returns, then latency, then the alternative, then failure guidance. Dense and purposeful, though the all-caps emphasis and multi-clause failure instruction push it slightly past what a single read needs.

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 no output schema, the description correctly states the return value (a link to the finished video), and it covers the operational hazards (latency, timeouts, double-billing on retry) an agent needs to call and handle this safely. Nothing material is missing.

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

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

Schema coverage is 100% with only 2 parameters, so the schema fully documents 'prompt' and the aspect_ratio enum. The description adds no syntax or format detail beyond the schema, so the 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+resource ('Generate a short video') and names the exact model (Kling 2.5 Turbo Pro) plus the motion character it produces. This clearly differentiates it from the sibling generate_video_veo without needing to open either 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?

Explicitly routes the agent: use this for cinematic motion, but if the user needs speed, generate_video_veo is about 60s. It also prescribes pre-call behavior (warn the user about ~90s) and failure handling (do not silently retry), leaving nothing 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 only declare the generic shape (not read-only, open-world, non-destructive). The description adds the traits that actually matter: ~60s or longer latency, expected wait, and the billing consequence of retrying after an apparent timeout. That is exactly the beyond-annotation context an agent 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?

Front-loads what the tool produces and its return value, then adds the latency warning and the anti-retry rule. Every sentence carries operational weight; nothing is filler.

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 slow, billable, non-idempotent generation tool with no output schema, the description covers latency expectations, user-facing messaging, failure semantics, retry cost, and the return format. Nothing an agent needs to call 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 description coverage is 100% and both parameters (prompt, aspect_ratio enum) are already documented in the schema. The description adds no parameter-level detail, so the 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 (Generate) and resource (a short video with Google Veo 3 Fast), notes that audio is included, and names the concrete return value (a link to the finished video). This distinguishes it from the sibling generate_video_kling and the generate_image_* 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?

Gives explicit procedural guidance: tell the user before calling that generation takes ~a minute, and do not silently retry on apparent failure. It stops short of stating when to prefer this over the sibling video/image generators, so it is clear context but not full alternative 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds real behavioral context beyond them: the 30-day per-call ceiling and the Business/Creator account requirement, both of which affect whether a call will succeed.

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; the metric list is compact and the limiting constraint ('Max 30 days per call') is placed at the end where it is easy to scan. No filler.

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 no output schema, the description usefully enumerates the returned metrics (reach, views, profile visits, engagement, likes, comments, saves, shares, website taps, follower count, net new followers), covering what the agent would otherwise not know. Defaults and precedence for the date parameters are in the schema, so nothing material 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%, so all four parameters are already documented, including the defaults and the since/until precedence. The description only reinforces the 1-30 day constraint, adding marginal value 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+resource ('Get analytics for your own Instagram Business/Creator account') plus an explicit scope constraint (account-level, own account) and enumerates the exact metrics returned. An agent can distinguish this from instagram_media_insights (per-post) without opening either 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?

The 'your own Business/Creator account' scoping and the 'Max 30 days per call' cap imply when the tool is valid, but there is no explicit when-to-use guidance or named alternative for per-media stats (instagram_media_insights). Usage is inferable but not spelled out.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: it enumerates the returned metrics (reach, views, likes, comments, saves, shares, permalink) and discloses that Stories are included, which is non-obvious. It stops short of mentioning insight-fetch cost/latency or ordering guarantees.

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 that packs verb, resource, scope, and payload into minimal space with zero filler. Nothing is repeated or 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 100% schema coverage and no output schema, the description usefully compensates by naming the returned metrics. It is largely complete for a simple list tool, though it could have disambiguated itself from the adjacent instagram_*_insights tools.

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

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

Schema description coverage is 100%, so all three parameters (limit, with_insights, instagram_account_id) are already fully documented in the schema, including defaults and the faster-path tradeoff. The description adds no parameter-level detail beyond what the schema provides, so the 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 (list) and resource (your own Instagram posts, Reels, Stories) plus the payload (per-post insights with named metrics). The 'your own latest' scope implicitly separates it from search_instagram, but it never names a sibling to make the distinction explicit.

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 or when-not guidance. With siblings like instagram_media_insights, instagram_account_insights and search_instagram in the catalog, an agent gets no help deciding which to call or in what order.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful ownership constraint ("your own") but does not describe the returned insights or any rate-limit/permission 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?

A single front-loaded sentence with zero filler, stating verb, resource, scope, and the id source all at once.

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 tool with one parameter and no output schema, the description plus annotations cover what an agent needs: safety, target scope, and where the id comes from. It stops short of describing the insight fields returned, which a caller might still want.

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 there is a single required media_id already documented in the schema. The description adds only the provenance hint (from instagram_list_media), 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 description names a specific verb (Get), resource (insights), and scope (one of your own Instagram posts, Reels or Stories), which clearly separates it from the sibling instagram_account_insights (account-level) and pairs with instagram_list_media. An agent can pick this tool 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 tells the agent the required input is a media id obtained from instagram_list_media, which is practical routing context. However, it does not explicitly state when to prefer this over instagram_account_insights or what to do when the media isn't your own, so no full when-not 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses what the tool returns (click-by-click steps, links, screenshots, values to collect) and the intended interactive pattern, which is real behavioral context.

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

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

Three sentences, front-loaded with the core purpose and organized as purpose → usage → parameter note. Each sentence earns its place, though the final provider clause is slightly repetitive of the schema description.

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 no output schema, the description compensates by describing the return content and the interactive follow-up. Combined with 100% schema coverage and clear annotations, an agent has enough to call it correctly; only the link to connect_integration as the subsequent step is left implicit.

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 the baseline is 3, but the description adds conditional semantics not in the schema: provider is only relevant for email and should be passed 'once you know it,' with the accepted values restated to tie the parameter to a real choice point.

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

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

The description names a specific verb and resource: 'Get the step-by-step walkthrough for connecting one account to Lodestone.' It goes further to specify exactly what the walkthrough contains (where to click, exact links, screenshots, values to ask the user for), so an agent can distinguish this from siblings like integration_status (status lookup) and connect_integration (performs the connection).

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 prescribes the workflow clearly: read the guide, then walk the user through it one step at a time and collect values in-chat, and it references integration_status as the source of the integration id. It does not explicitly name connect_integration as the follow-up action or state a when-not condition, so it stops short of full alternative 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description adds real value beyond that with "Returns no credentials" (a security-relevant guarantee) and the explicit enumeration of what is being checked. It stops short of describing the shape of the status result, so it is 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?

Two sentences, front-loaded with the tool's role and followed by the invocation trigger. Every clause earns its place; no filler, no repetition of the annotation title.

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

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

For a no-parameter, read-only status query with a full annotation set, the description tells the agent what it reports and when to reach for it. A brief hint at the response form (per-provider connected/not-connected list) would make it fully self-contained, but no output schema exists and the omission is minor.

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 by the baseline rule this is a 4. There is no argument surface for the description to clarify or omit.

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 ("Show") plus resource (which accounts are connected vs. not), and it enumerates the exact providers in scope (email, Meta Ads, Telegram, Typefully, Instagram Insights, Google Analytics, chat apps). An agent can distinguish it at a glance from connect_integration, disconnect_integration, and integration_guide.

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?

"Call this first when the user wants to connect something, or when a tool says an account is not connected" gives an explicit trigger condition and a second fallback trigger, effectively routing the agent between this and the sibling connect/disconnect tools. Nothing is left 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=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond that by naming the response contents (currency, status, lifetime spend, spend cap, balance), which matters because there is no output 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?

A single front-loaded sentence that names the action and immediately enumerates the returned fields. No preamble or filler.

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 one-parameter read tool whose annotations cover the safety profile, listing the returned fields compensates for the missing output schema. Only the absence of routing guidance against sibling account tools leaves a small gap.

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 optional parameter with 100% schema coverage, where the schema already documents the act_XXXX format and the default-to-connected-account behavior. The description adds nothing about the parameter, so the 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 ('Get details for your Meta ad account') and enumerates the fields returned, so the agent knows what it retrieves. It does not explicitly differentiate itself from close siblings like meta_ads_list_accounts or meta_ads_whoami, which keeps it from 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?

The description gives no when-to-use guidance, no conditions, and no alternatives. With siblings such as meta_ads_list_accounts and meta_ads_whoami in the same family, the agent must infer that this is the single-account detail call.

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 only declare the generic write/open-world profile (readOnlyHint=false, destructiveHint=false). The description adds meaningful behavior: it impacts the live account, the created ad defaults to PAUSED, and it enforces a confirm:true safety gate. That said, 'PAUSED default' and 'confirm' partly overlap with schema descriptions, so it is strong but not fully additive.

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 opens with the [WRITE — changes your live account] warning, then delivers scope, precondition, default state, and the confirm requirement with zero 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?

With no output schema, the safety annotations present, and full schema coverage, the description supplies everything an agent needs: purpose, write impact, precondition, default status, and the confirm gate. Nothing required to call 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 description coverage is 100%, so all five parameters (including post_id format and ad_set_id provenance) are already documented in the schema. The description corroborates 'existing ad set' and 'confirm:true' but adds no syntax or semantic detail beyond the schema — the 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 (promote/boost), resource (existing Facebook Page post as an ad), and the key scoping distinction '(no upload)' plus 'under an existing ad set'. This clearly separates it from the sibling meta_ads_create_image_ad without needing to open either 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?

Implies the preconditions that an ad set must already exist and that the post already exists (no upload path), steering the agent away from the create/upload siblings. However, it never names an alternative tool or an explicit when-not-to-use condition, so it falls short of full routing 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), but the description adds critical context beyond them: the 'WRITE — changes your live account' warning, the fact that the ad set is created PAUSED rather than live, and the confirm:true gate. An agent knows the blast radius and the required safety flag.

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 compact clauses, with the highest-severity information (WRITE, live account) front-loaded in brackets and the confirm gate last. No sentence 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?

For a 13-parameter write tool with full schema coverage and annotations present, the description covers the essential behavioral facts an agent needs. The only gap is that, with no output schema, it does not indicate what is returned (e.g., the new ad set id) after creation.

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 every one of the 13 parameters is already documented in the schema (including enum for status and defaults for budget/age/targeting). The description only restates the areas covered and adds no format or syntax detail beyond the schema, 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 and resource ('Create a Meta ad set under a campaign') plus the scope of what it configures (budget, optimization goal, country/age/gender targeting). This clearly distinguishes it from siblings like meta_ads_create_campaign and meta_ads_create_image_ad.

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 description conveys prerequisites ('Requires confirm:true') and the resulting state ('Created PAUSED'), which implies when it is safe to call. However, it never says when to choose this over meta_ads_create_campaign or meta_ads_boost_post, so alternative-selection guidance is absent.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, but the description adds material context the annotations do not: it touches the live account, the object starts PAUSED and won't spend until activated, and confirm:true is a hard safety gate. That is genuine value beyond the structured hints, though it says nothing about rate limits or failure modes.

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, each earning its place, with the live-account warning and the default-state behavior front-loaded before the call requirement.

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?

No output schema exists, and the description covers the safety profile, default state and required gate, which is enough for an agent to call it correctly. It could note what the tool returns (e.g. the new campaign id) to be 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 name, status, objective, daily_budget and confirm are already documented in the schema. The description only restates the confirm gate and the PAUSED default, adding no new semantics such as budget units or objective selection guidance.

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 ('Create a new Meta campaign'), clearly distinguishing it from siblings such as meta_ads_update_campaign or meta_ads_create_ad_set. The bracketed write-scope marker further disambiguates it from the read/list 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?

Gives operational guidance (created PAUSED, requires confirm:true), which tells the agent how to call it safely, but never says when to choose this over alternatives like meta_ads_create_ad_set or meta_ads_boost_post, nor any prerequisites beyond the confirm gate.

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?

Goes well beyond the annotations: flags this as a live-account WRITE, discloses that the ad is created PAUSED by default, and surfaces the confirm:true safety gate. These are exactly the behavioral facts an agent needs before invoking a mutation 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 clauses, leading with the risk level in brackets, then the effect, then the gating requirements. No filler; each sentence carries a distinct constraint.

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 an 11-param mutation tool with no output schema, the description covers the safety gate, default state, and prerequisites. It does not mention what is returned (e.g. the new ad id) or how to inspect/verify the created ad, but the essential call-time information is present.

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 every parameter including confirm, status, page_id and cta is already documented in the schema. The description's notes on no-upload image fetching and the PAUSED default largely restate schema text, 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?

Specific verb+resource (create an image ad) with the key mechanism stated (from a public image URL, Meta fetches it) and the required parent container (under an existing ad set). Clearly distinguishable from siblings like meta_ads_create_ad_set or meta_ads_boost_post.

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?

States prerequisites explicitly: needs an existing ad set, needs a Facebook Page, requires confirm:true. This tells the agent what must exist before calling. However it doesn't name alternatives (e.g. when to prefer boost_post over creating a fresh ad) or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds which fields come back (name, status, parent ad set/campaign), which is mildly useful context but no auth, rate-limit, 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?

A single front-loaded sentence with no filler; the returned-field list is the only detail beyond the core purpose. Nothing is wasted, though it is very terse.

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 single-parameter read operation with annotations covering safety and no output schema, the description need not explain return formatting. Naming the fields returned compensates for the absent output schema, leaving only minor gaps around id sourcing.

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% with a single required parameter, so the baseline is 3. The description adds no syntax, format, or source guidance for ad_id beyond what the schema already says.

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

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

States a specific verb and resource ('Get one Meta ad by id') and scopes it to a single record, with a parenthetical naming the returned fields. It implicitly distinguishes itself from the list/get_ad_set/get_campaign siblings by resource, though it never names 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?

The phrase 'by id' implies the tool is for direct lookup when an ad id is already known, but there is no explicit when-to-use, when-not, or pointer to meta_ads_list_ads for discovery. Usage is left 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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value by disclosing the returned fields (status, optimization goal, budget, targeting), which matters because no output schema exists.

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

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

A single front-loaded sentence with the action verb first and the useful return-field detail in a compact parenthetical. Nothing is wasted and nothing extraneous is included.

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 get-by-id read tool with annotations covering safety and no output schema, the description supplies enough: it names the resource, the selector, and the principal fields returned. It omits error behavior for an invalid id, which is a minor gap.

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% with a single documented ad_set_id parameter, so the schema already carries the burden. The description's 'by id' adds no format, type, or sourcing detail beyond what the schema states, making the baseline 3 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?

States a specific verb and resource ('Get one Meta ad set by id'), and the word 'one' implicitly separates it from meta_ads_list_ad_sets. It does not explicitly name siblings like meta_ads_get_ad or meta_ads_get_campaign, so 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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives (list_ad_sets, get_ad, update_ad_set). The 'by id' phrasing faintly implies a known identifier is required, but that is the only usage signal.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by naming the returned fields (status, objective, budget, schedule), but says nothing about auth requirements, rate limits, or behavior when the id is unknown.

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 action and lookup key front-loaded and the payload summarized in a parenthetical. No filler or redundancy.

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 single-parameter read whose annotations cover the safety profile, the description is nearly sufficient; listing the returned fields compensates for the absence of an output schema. Only the missing error/not-found behavior keeps it 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?

Only one parameter and schema description coverage is 100%, so the schema fully documents campaign_id. The description adds no format, prefix, or validity information beyond the phrase 'by id', making the baseline 3 correct.

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 (Get) and resource (one Meta campaign) with the lookup key (by id) and enumerates the salient fields returned. It is clearly distinguishable from meta_ads_list_campaigns (plural/list) and from meta_ads_get_ad / meta_ads_get_ad_set by naming the campaign entity.

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: fetch a single campaign when you have its id. There is no guidance on when to prefer meta_ads_list_campaigns or meta_ads_insights instead, and no prerequisites mentioned. Minimum viable routing information only.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without description help. The description adds no behavioral context such as required ad-account permissions, rate limits, or data-freshness/attribution caveats that a reporting tool would benefit from disclosing.

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 that names the verb, the metric list, and the applicable scope with no filler. 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?

There is no output schema, and the description partially compensates by enumerating the returned metrics (spend, impressions, clicks, CTR, CPC, CPM, reach). It is close to complete for a simple reporting tool, though it omits return shape and the default-level behavior when object_id is omitted.

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

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

Schema description coverage is 100%, so all three parameters (level, object_id, date_preset) are already documented with enums and defaults in the schema. The description adds no syntax or format detail beyond what the schema provides, so the 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 (Get) plus resource (performance/spend metrics) and enumerates the exact metrics returned. It also scopes the operation to the whole account or a single entity, which cleanly separates it from sibling tools like meta_ads_get_ad or meta_ads_list_campaigns that fetch entity metadata rather than metrics.

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

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

The phrase 'for your whole ad account or one campaign/ad set/ad' implies when the tool applies, but there is no explicit when-to-use guidance or named alternative (e.g., versus meta_ads_get_campaign for structural data). Usage is inferred from the scope rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the access-scoping behavior (token-bound results) and the shape of returned records, which is useful but not beyond the expected for a read-only list.

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

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

One sentence, front-loaded with the verb and resource, with the scope constraint and return fields packed in without waste.

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, zero-required-parameter list tool with full schema coverage, the description is sufficient, and enumerating the returned fields (name, id, currency, status) usefully compensates for the absent output 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?

There is a single optional 'limit' parameter at 100% schema description coverage, so the schema fully documents it ('Max accounts (default 25)'). The description adds nothing about the parameter, which is acceptable given the schema carries it — 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?

Clear verb (List) plus specific resource (Meta ad accounts) and an explicit scope constraint ('your connected token can access'), with the returned fields enumerated. It reads distinctly from meta_ads_account_info or whoami without opening a schema, though 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 description gives no when-to-use or when-not-to guidance and does not point to alternatives like meta_ads_account_info (single-account detail) or meta_ads_whoami. The 'which accounts the token can access' wording hints at a discovery role, but selection between siblings is left entirely 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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context such as pagination behavior, result caps, or ordering, and its scoping clause merely restates the ad_set_id parameter.

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; the primary scope is stated before the narrower filter. It is efficient, though extremely terse and leaves no room for qualifying 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 listing tool with full schema coverage and safety annotations, the description covers what an agent needs to invoke it correctly. There is no output schema, but the agent is not told anything about result shape or paging, a minor remaining gap.

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% for both parameters (limit default 25, ad_set_id filter), so the schema already carries the semantics. The description echoes the ad_set_id filter but adds no syntax, format, or default details beyond it, making 3 the correct 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?

The description gives a specific verb (list) and resource (ads) plus the two scopes available (whole ad account or a single ad set), which separates it from get_ad and from the list_ad_sets/list_campaigns siblings by resource. It does not explicitly name a sibling it is not, so it falls short of the 5 tier.

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: 'or just those in one ad set' hints at when to pass ad_set_id, and 'list' vs 'get' implies bulk retrieval versus single-item lookup. There is no explicit when-to-use, when-not-to-use, or named alternative.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety and network profile is covered. The description adds only the campaign-scoping behavior; it says nothing about pagination beyond the limit default 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?

One compact sentence that front-loads the verb and resource before the optional scope. No filler or redundancy.

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 two-param read-only list tool with full schema coverage and safety annotations, nothing critical is missing, and no output schema is needed. Return shape/pagination details are the only absent nuance.

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 both parameters (limit default 25, campaign_id filter) are already fully documented in the schema. The description's campaign clause merely restates campaign_id, adding no syntax, units, or constraints beyond it.

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 ('List') and resource ('ad sets') plus its scope (account-wide or single campaign). This clearly separates it from the singular meta_ads_get_ad_set, though 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 'or just those in one campaign' clause implies when to pass campaign_id, giving minimal conditional guidance. No when-not-to-use, prerequisites, or explicit routing to meta_ads_get_ad_set / meta_ads_list_campaigns.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only the returned field set; it says nothing about pagination, ordering, or account-scoping 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?

A single front-loaded sentence with no filler; the resource and the useful return 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?

For a simple read-only list tool with rich annotations and no output schema, this is nearly adequate but leaves gaps: it does not clarify that status is also a filter, nor how accounts/results are scoped or paginated.

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 the schema fully documents limit and status, giving a baseline of 3. The description adds no syntax or default details beyond what the schema already states.

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 (List) and resource (campaigns) plus the fields returned (status, objective, budget). It is clearly distinct from create/update/get siblings, but does not explicitly differentiate itself from meta_ads_get_campaign or meta_ads_list_ads in 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?

No guidance on when to use this versus meta_ads_get_campaign for a single campaign, nor versus meta_ads_list_ads or meta_ads_list_ad_sets. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (each post's id) and its purpose for meta_ads_boost_post, though it omits pagination or ordering 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?

A single front-loaded sentence that names the action, the resource, the goal, and the return value with no filler.

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 two-param, read-only list tool with no output schema, the description supplies the key missing piece: what the call returns and why. Minor gaps remain around ordering and pagination limits, but nothing critical to correct invocation is absent.

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%, with both 'limit' (default 25) and 'page_id' (optional, defaults to connected Page) documented in the schema itself. The description adds no parameter-level detail, so the baseline of 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?

States a specific verb and resource ('List recent posts on your connected Facebook Page') and names the downstream sibling it feeds ('returns each post's id for meta_ads_boost_post'), so an agent can distinguish it from meta_ads_list_ads or meta_ads_list_campaigns without opening a 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?

Makes the usage context explicit ('so you can pick one to promote') and points to the tool this precedes. It does not state when NOT to use it, but the routing intent is unambiguous for the boost workflow.

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 write/destructive/openWorld, but the description adds real behavioral value beyond them: it warns it 'changes your live account', explains the consequence ('Pausing stops spend'), and discloses the confirm:true safety gate. It stops short of stating reversibility or the response behavior, 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-loads the [WRITE] warning, then packs action, scope, consequence and the confirm requirement into two tight sentences with no filler.

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 mutation with no output schema, the definition covers what changes, what it costs (spend), and the safety gate, with annotations carrying the readOnly/destructive profile. Minor gaps remain on reversibility and return behavior, but nothing essential to calling 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 description coverage is 100%, so the enum meaning for status, the object_id target, and the confirm gate are all already documented in the schema. The description's mention of 'by id' and 'confirm:true' only restates structured fields, landing 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 action (pause/resume = set status) on a specific resource (Meta campaign, ad set or ad) identified by id. It is distinguishable from the create/get/list siblings, though it does not explicitly differentiate itself from meta_ads_update_campaign or meta_ads_update_ad_set, which could plausibly also touch 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?

Gives useful context ('Pausing stops spend', 'Requires confirm:true') that implies when this tool is the right choice, but offers no explicit when-to-use-vs-alternative guidance against the sibling update tools or any stated exclusions.

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=false and destructiveHint=true, but the description adds meaningful context beyond them: it warns this changes the live account and that a confirm:true safety gate must be satisfied. It stops short of describing reversibility or rate/permission constraints.

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 most decision-relevant fact (it is a write to a live account) before the mutation surface and the confirm requirement. No filler.

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 five-parameter mutation tool with no output schema, the description covers the write semantics and the confirm gate, which is what an agent most needs before invoking it. It is slightly thin on what the update returns and on how it relates to the status-specific sibling.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including the confirm gate and the minor-units budget. The description merely echoes name/status/daily budget, adding no syntax or format detail beyond the schema, 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 and resource ('Update a Meta ad set') plus the updatable fields (name, status, daily budget), so the agent knows exactly what is mutated. It does not distinguish itself from the sibling meta_ads_set_status, which plausibly overlaps on the status field, so sibling differentiation is incomplete.

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 description gives a hard precondition ('Requires confirm:true') and flags that this is a live-account write, which is real usage guidance. It never says when to choose this over meta_ads_set_status or meta_ads_update_campaign, so the alternative-selection 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?

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds genuinely useful context beyond them: that this touches a LIVE account and requires confirm:true as a safety gate. It stops short of describing reversibility or rate/permission constraints.

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, and the critical warning (WRITE — changes your live account) is front-loaded before the scope. 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 mutation with no output schema but full schema coverage and annotations, the definition gives the agent the essential safety context (live account, confirm gate). Only the relationship to the overlapping set_status sibling is left unresolved.

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 every parameter including confirm and the minor-units convention on daily_budget is already documented in the schema. The description only nods at the same fields, adding no syntax or unit detail 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 (Update) and resource (Meta campaign) plus the exact mutable fields (name, status, daily budget), so it is clearly distinguishable from create_campaign and get_campaign. It does not, however, differentiate itself from the sibling meta_ads_set_status, which plausibly overlaps on the status field.

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 description makes the write context and the confirm:true gate explicit, which implies when to use it, but it never names alternatives or exclusions (e.g. when to prefer set_status vs this tool). Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that this doubles as a health check and returns token identity, which is useful but thin; it says nothing about failure modes (e.g. expired token 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?

A single, front-loaded sentence with no waste. The connectivity-check purpose leads and the identity result follows.

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 no output schema, the description does convey what comes back (token identity) for a zero-param diagnostic tool. It is adequate, though it could mention that it returns the connected account/user for use in later calls.

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 no parameter semantics to clarify and the description correctly implies a parameterless call.

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 ('Check') and resource ('your connected Meta account') and adds the identity aspect ('whose token it is'). It is distinguishable from data-heavy siblings like meta_ads_account_info or meta_ads_list_accounts, though it does not explicitly contrast 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?

'Check that your connected Meta account works' implies the usage context: a connectivity/auth sanity check before other Meta Ads calls. No explicit when-not conditions or named alternatives are given, so the guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered without prose. The description adds genuinely new behavioral context by stating the return content ('matching stays with monthly price and rating'), which matters because no output schema exists. It omits pagination/result-count behavior, keeping 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, zero filler, with the search scope front-loaded and the return value appended. 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 read-only search tool with full schema coverage, the description covers purpose, inputs and a partial view of outputs. It stops short of noting result limits, sorting, or pagination, which are the remaining unknowns given no output 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 100%, so every parameter is already documented in the schema, including the 30-night default. The description restates three of the five filters (location, monthly price ceiling, bedroom count) without adding format or syntax meaning. 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 ('Search') plus resource ('live Airbnb listings') and enumerates the filtering axes (location, monthly price ceiling, bedroom count) along with what is returned. This clearly separates it from siblings like search_hotels and search_flights.

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 description implies when the tool is appropriate (finding Airbnb stays), but gives no explicit when-to-use guidance and never names an alternative such as search_hotels for non-Airbnb lodging. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine value by enumerating the returned fields (title, price, star rating, review count, badges, link), which compensates for the absent output schema. It omits pagination, result-count limits, and rate-limit behavior, keeping 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 tight sentences with the action front-loaded and the return payload second. No filler, no repetition of the title, and every clause contributes information.

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

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

For a two-parameter read tool with no output schema, the description supplies the missing return-shape information and the core scoping (Amazon marketplaces via domain). It is close to complete, though pagination/result-limit behavior would make it fully sufficient.

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%: both 'query' and 'domain' are documented with examples and a default, so the schema already carries full parameter semantics. The description adds nothing beyond the schema, making the baseline 3 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?

States a specific verb (Search) and resource (Amazon products) plus scope (by keyword), which cleanly separates it from the many other search_* siblings (search_airbnb, search_flights, search_reddit). The description is self-contained and an agent can route to it without reading 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?

The description implies usage (product lookup by keyword) but gives no explicit when-to-use, when-not-to-use, or alternative routing guidance. It never mentions how it relates to the other search_* tools or say, meta_ads product-related tools, leaving selection 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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that results are limited to public pages/posts, which is modest extra context; it says nothing about rate limits, result counts, or pagination.

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 zero filler; the core purpose is front-loaded and the return summary follows immediately. 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 simple one-parameter read tool with no output schema, the description usefully names the returned fields (page/author, text, link), which is what an agent needs to decide whether the results fit its task. It falls short only on selection guidance versus sibling search tools.

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

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

Schema description coverage is 100% for the single required 'query' parameter, so the schema already documents it as 'Page name or keyword'. The description's 'by name or keyword' phrasing merely echoes the schema without adding format, syntax, or disambiguation guidance.

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 (Facebook public pages/posts) with a scope qualifier ('public') and input mode ('by name or keyword'). This distinguishes it from the ads-oriented sibling search_facebook_ads, though it does not name any 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?

Usage is only implied: an agent infers it should call this when it needs to find Facebook pages or posts by keyword. There is no statement of when to prefer it over alternatives such as meta_ads_list_page_posts or search_facebook_ads, and no prerequisites or exclusions.

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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it clarifies the data is public ad data rather than the caller's own account, and enumerates the returned fields. It does not mention rate limits or pagination, but this is solid added value over the annotations.

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 tightly written sentences: purpose and audience first, return fields second, sibling disambiguation last. No filler, and the most decision-relevant constraint (public vs own account) is not 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?

No output schema exists, yet the description enumerates the return fields (advertiser, ad copy, CTA, link, platforms, run dates, permalink), and annotations cover the safety profile. Nothing an agent needs to call this 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 description coverage is 100%, with defaults and examples already documented for query, status, country, and limit. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline of 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?

States a specific verb (Search) and resource (PUBLIC Meta Ad Library for any advertiser), and explicitly scopes it against the meta_ads_* siblings that operate on the caller's own ad account. An agent can distinguish this from meta_ads_list_ads without opening either 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 use case ('great for competitor and creative research') and names the alternative tool family plus the condition that selects it ('use meta_ads_* tools for that'). When and when-not are both covered.

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, openWorldHint, destructiveHint=false), so the bar is lower. The description adds real value by disclosing the return contract: results are live prices sorted cheapest-first with airline, duration and stops. It omits freshness/caching caveats and result limits, but exceeds what the annotations provide.

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 dense sentences with zero filler, front-loading what is searched before what is returned. Nothing could be cut without losing information.

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

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

With no output schema, the description usefully summarizes the shape of results (sorted, with airline/duration/stops). Combined with 100% schema coverage, an agent has enough to invoke it correctly, though pagination or result-count behavior is unaddressed.

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 every parameter (from, to, depart_date, return_date, adults) is already documented with format and defaults. The description restates the airport/date pairing and confirms return_date drives round-trip, adding little 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 (search) plus resource (flight prices and itineraries), scope (between two airports on a date), and trip type. It is unmistakable against the other search_* siblings like search_hotels and search_airbnb, which cover different domains.

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 one-way vs round-trip distinction implies how to use the date parameters, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer that this is the flight-domain search tool from context rather than from 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context that results are live/real-time and what each hotel record contains, but says nothing about rate limits, result caps, or pagination behavior for what is presumably an external live-query 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 tight sentences, front-loaded with the action and source, followed by the return contents. No filler or repetition 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?

With no output schema, the description appropriately summarizes return contents (nightly price, star rating, review score) and covers the required inputs; it falls short only on operational behavior such as result limits or pagination, which would matter for a live external search tool.

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 the schema already documents all four parameters including defaults and date formats. The description only gestures at 'location and date range' and adds no syntax, defaults, or constraint detail beyond the schema, matching the baseline of 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 ('Search') plus resource ('live hotel availability and prices') and the source ('Booking.com') with the scoping conditions (location + date range). It is clearly distinguishable from siblings like search_airbnb or search_flights by resource, though it never explicitly names or contrasts 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?

Usage is implied by the description's framing (search hotels for a location and date range) but there is no explicit when-to-use/when-not-to-use guidance or reference to the other travel siblings (search_airbnb, search_flights) that an agent might confuse it with.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds value by naming the returned fields (full name, bio, follower and post counts), but does not disclose rate limits, auth requirements, or behavior for missing/private profiles.

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

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

One sentence, front-loaded with the action and resource, with the returned fields trailing. No filler or redundancy.

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 single-parameter read tool with no output schema, the description is nearly complete, even naming the returned fields. The only gaps are usage routing and behavior on edge cases, which are minor here.

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

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

Schema coverage is 100% with a single required parameter already documented with an example ('nasa'). The description only restates 'by username' and adds no syntax, format, or edge-case detail beyond the schema, so the 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 (look up), a specific resource (Instagram profile), and the lookup key (username). The resource is unique among siblings (search_facebook, search_twitter, etc.), so an agent can distinguish it by domain, though it does not explicitly contrast with any sibling.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. The usage is only implied by the name and description; an agent gets no explicit routing signal beyond 'this is the Instagram one'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond those annotations by enumerating the returned fields (names, star ratings, review counts, category, address, phone, website), which is meaningful for a tool with no output schema. It omits result limits, pagination, 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 sentences, no filler. The purpose and scope are front-loaded, followed immediately by the return payload, and 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?

With annotations covering safety and no output schema, the description usefully fills the return-value gap by listing the fields returned. It is nearly complete for a two-parameter search tool, though a note on result count limits or ordering would remove the last uncertainty.

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

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

Schema description coverage is 100% and both parameters are documented in the schema with examples. The description restates 'keyword and optional location' but adds no syntax, formatting, or constraint detail beyond what the schema already provides, 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 and resource ('Search Google Maps for places') and enumerates the domain of results (restaurants, shops, services, businesses). This clearly separates it from siblings like search_airbnb, search_flights, and search_amazon, which are all vertical-specific searches.

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 description conveys the basic shape of use (keyword plus optional location) but gives no explicit when-to-use vs when-not-to-use guidance and does not name any alternative tool. Usage is implied by the generic 'search' framing rather than stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by naming the returned fields (titles, subreddit, upvotes, comment counts, links), which compensates for the missing output schema, but says nothing about rate limits, pagination, or result caps.

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 purpose front-loaded and the output summary second. No filler or redundant 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?

For a simple one-parameter, read-only search tool, the description covers purpose and the return shape even without an output schema. It is nearly complete, missing only result-volume or pagination expectations.

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?

Only one parameter exists and schema description coverage is 100% including an example query, so the schema fully documents it. The description adds no syntax or format detail beyond what the schema already provides; 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 description states a specific verb and resource (search Reddit for posts), and the return fields are enumerated. It is distinguishable from the many search_* siblings by the explicit 'Reddit' scope, though it doesn't explicitly contrast with any named alternative.

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 siblings like search_twitter or twitter_user, nor any mention of prerequisites or limitations. Usage is only implied by the name and verb.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return fields (author, play count, caption, link), which is useful but is return-value info rather than behavioral context. No mention of pagination, rate limits, or result caps, so it is adequate but not rich.

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 no filler: the first states what it does, the second states what it returns. Front-loaded and efficient.

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, the description covers the action, the input forms, and the returned fields. Missing pagination/limits is a minor gap for a search tool, but nothing essential to calling it is absent.

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% with a single documented parameter, so the schema already carries the meaning. The description's 'keyword or handle' mirrors the schema's 'Keyword or @handle' without adding format or syntax detail beyond it. 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: 'Search TikTok for videos by keyword or handle.' The resource (TikTok videos) distinguishes it from the other search_* siblings by platform. It does not, however, explicitly differentiate itself from the large family of sibling search tools, so it falls 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?

There is no guidance on when to use this tool versus the many sibling search tools (search_instagram, search_twitter, etc.), nor any prerequisites or exclusions. The platform name is the only implicit selection signal.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing supported search operators and the returned fields (author, likes, retweets, link), though it omits rate limits or pagination 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?

Three short sentences, zero filler: purpose first, then capability/operator detail, then return shape. Every sentence earns its place and the most important information is front-loaded.

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 no output schema, the description compensates by naming the returned fields, and it covers query syntax and the operator repertoire. For a 3-parameter read-only search tool with full annotation coverage, nothing an agent needs 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 100%, so the baseline is 3, but the description goes beyond the schema by spelling out operator syntax (from:user, filter:videos, min_faves:N, until:YYYY-MM-DD) that the schema only hints at with a single example. It does not additionally explain the type or limit parameters, which the schema already documents.

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 (X/Twitter tweets matching a query), and the operator examples plus return fields make the scope unambiguous. It is clearly distinguishable from siblings like twitter_user, twitter_replies, twitter_user_tweets, and search_reddit/search_tiktok.

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 verb 'search' but there is no explicit guidance on when to use this over twitter_user_tweets or twitter_replies, nor any exclusions or prerequisites. Adequate context, no routing help.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context (the getMe endpoint, token-validity purpose) but says nothing about the return format or what happens when the token is invalid, which would raise this score.

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 primary purpose (token verification) front-loaded and the return value (username) appended. No filler or redundancy.

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, no-output-schema tool, the description covers both the action and the expected return (username plus token validity). It is complete enough to call correctly, though it omits failure/error behavior for an invalid token.

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, which is the baseline-4 case per the rubric. There is nothing for the description to clarify beyond what the empty 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 and resource: verifies the connected bot token and returns the bot's username, citing the underlying @BotFather getMe call. This is clearly distinct from sibling tools like telegram_get_chat and telegram_send_message, though it doesn't explicitly 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?

"Check that your connected Telegram bot token works" implies the usage context (credential/connectivity verification), which is a reasonable hint. However, there is no explicit when-to-use statement, no when-not-to-use, and no named alternative.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact lookup keys (numeric id or @username) and the field set returned, which matters since no output schema exists. It omits what happens on an unknown/inaccessible chat, 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?

A single sentence that front-loads the verb and resource and then the return payload; every clause earns its place with no redundancy or filler.

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 read-only single-parameter lookup with annotations covering safety, the description is nearly self-sufficient: it names the lookup keys and the returned fields, compensating for the absent output schema. The only real gap is error/not-found behavior and rate-limit context.

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?

Only one parameter, and schema coverage is 100% – the schema already documents 'Numeric chat id or @username'. The description restates the same dual-key idea without adding format nuance (e.g. sign of numeric ids, whether @ is required), so the 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+resource (get info for a chat) and enumerates the returned fields (type, title/name, username, description), which separates it from telegram_read_recent_updates and telegram_get_bot_info. It does not explicitly name a sibling, so it lands just 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?

The phrase 'a chat your bot can see' implies the access precondition a caller must satisfy, but there is no explicit when-to-use versus telegram_read_recent_updates or telegram_get_bot_info, and no statement of when this tool is the wrong choice.

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

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

Beyond the readOnly/openWorld annotations, the description discloses critical behavioral constraints: there is no chat-history endpoint, only messages received after the tool starts checking are visible, and privacy-mode/admin requirements govern group visibility. This is exactly the kind of context annotations cannot convey.

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 core purpose is front-loaded, and the caveat is flagged with 'IMPORTANT' to draw attention. It is slightly dense but every sentence carries necessary behavioral information.

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

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

For a one-parameter read tool with no output schema, the description covers the crucial operational limitations an agent must know. It could briefly note the return shape, but the essential correctness information is present.

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 'limit' parameter already documents its default (10) and max (100). The description adds no additional parameter semantics, so baseline 3 applies.

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

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

The description states a specific verb and resource (read newest messages the bot received) and implicitly scopes it away from siblings like telegram_send_message and telegram_get_chat. An agent can tell this is an inbound-read tool without inspecting 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 clearly explains the operational context in which the tool works (bot only sees DMs, or group messages where privacy mode is off or it's an admin, and only new messages). It does not name alternative tools explicitly, but the when-it-applies guidance is strong.

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=false, openWorldHint=true and destructiveHint=true, so the safety profile is covered. The description adds the useful context that delivery goes through the user's own bot and is limited to reachable chats, but says nothing about rate limits, per-chat throttling, or what happens on send failure — extra context that would matter for a messaging mutation.

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 that carries the action, the channel, and the destination constraint with no filler. Nothing could be removed without losing information.

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

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

For a simple two-parameter, fully documented tool with no output schema, the description covers the essentials and supplies the bot-reachability constraint the schema does not. It falls short of complete only on delivery behavior and limits, which rarely block a correct invocation.

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

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

Schema description coverage is 100%: 'text' documents the 1-4096 character bound and 'chat_id' documents the numeric-or-@username form plus where to obtain it. The description adds nothing beyond the schema for either parameter, so the 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 ('Send a text message ... to a chat') and scopes it to the agent's own Telegram bot, clarifying the delivery channel. It does not distinguish itself from the parallel sibling beeper_send_message, so an agent with both tools has no routing cue, but the action itself 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?

The parenthetical states an important prerequisite: the destination must be a user who has DM'd the bot or a group/channel the bot is in. That is real usage context (an agent cannot message arbitrary users). However, it never names an alternative channel tool (beeper_send_message, typefully_post) or states when not to use this.

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, openWorldHint=true, and destructiveHint=false, so safety and open-world nature are covered. The description adds no further behavioral context such as pagination, rate limits, ordering, or what the replies contain. No annotation contradiction.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately sized for a simple read tool, though it lacks structural elements like usage notes or parameter hints.

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

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

The tool is simple and annotations plus a fully described schema cover the essentials. However, with no output schema, the description could mention what the replies look like or how they are returned. It is minimally adequate but not rich.

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%: the tweet_id parameter is documented as 'Tweet ID or URL' and limit as 'Max replies (default 10)'. The description adds no additional meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: 'Get the replies to a specific tweet.' This clearly identifies the tool's function. However, it does not differentiate from relevant siblings like twitter_user_tweets or search_twitter, which could also return tweet content.

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. It does not mention conditions, prerequisites, or that other tools exist for searching or retrieving tweets by user. Usage must be inferred entirely from the tool name.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds no behavioral detail such as auth requirements, rate limits, or handling of suspended/nonexistent accounts, so it goes no further than the annotations.

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

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

One front-loaded sentence with the resource and its returned fields; every clause earns its place and there is no padding.

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 single-parameter lookup with no output schema, the description usefully previews the returned profile fields so the agent knows what comes back. Only the behavioral/edge-case context is thin.

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?

There is a single parameter with 100% schema description coverage, including a concrete handle example. The description adds no format or syntax detail beyond what the schema already provides, 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 and resource ('Get an X/Twitter user's profile') and enumerates the fields returned. It is clearly distinct from siblings like twitter_user_tweets and twitter_replies, though it never names them explicitly.

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

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

No guidance on when to use this versus search_twitter or twitter_user_tweets, and no prerequisites or context. The agent must infer usage from the 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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the title's near-identical phrasing: no pagination behavior, no treatment of retweets/replies inclusion, no rate-limit context.

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

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

A single front-loaded sentence with zero padding. It is efficient, though so terse that little is 'earned' because little is said.

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?

Read-only, two params, no output schema, so the description need not explain returns. Still, for a social-feed tool it omits what 'most recent' spans and whether the limit counts retweets, leaving the agent with a minimally viable definition.

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

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

Schema coverage is 100%, so both parameters are documented in the schema ('Max tweets (default 10)', 'Twitter handle'). The description contributes no additional detail about how limit interacts with recency or what username formats are accepted, so the 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 ('Get a user's most recent tweets'), which is clear against the sibling set. It stops short of differentiating from close neighbors like twitter_user or twitter_replies, so an agent must infer the boundary rather than being told.

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

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

No when-to-use guidance, no exclusions, and no mention of the obvious alternatives (twitter_user for profile data, twitter_replies for reply threads, search_twitter for topic search). The agent is left to infer selection from the 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 destructiveHint=true and openWorldHint=true, so the external, irreversible nature is partly covered. The description adds real context beyond that: immediate publishing by default, thread encoding via four newlines, and that image fetching/upload is handled internally. It stops short of warning about irreversibility or noting rate limits/auth prerequisites.

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 tight sentences, front-loaded with the primary action and its default behavior, with the image-upload convenience last. No filler sentences or redundant 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?

For a write tool with no output schema and six fully documented parameters, the description covers the key behavioral facts (immediate vs scheduled, cross-post scope, image handling). It does not describe the response payload (e.g. resulting post ID/URL), which is the only notable gap.

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 every parameter is already documented in the schema itself (including the newline thread convention and fal.media image support). The description largely restates that same information rather than adding new syntax or format guidance, 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?

Opens with a specific verb+resource ('Publish a post') and immediately scopes the target surfaces (X plus optionally LinkedIn, Threads, Bluesky, Mastodon). It also differentiates from the only sibling in the same namespace (typefully_whoami) by being the posting/write operation. An agent can select this 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?

Clearly states the default behavior ('publishes immediately by default') and the alternative mode ('can also schedule'), plus the conditional cross-post mapping (connected networks are hit, unconnected ones are ignored). There is no explicit sibling routing, but the typefully namespace contains only whoami as an alternative, so the omission is minor.

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