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

With no annotations, the description carries the burden and it does disclose meaningful behavior: it reports configuration state, tests the server connection, and promises not to reveal secrets. It does not mention error behavior or auth requirements, but those are minor for a simple read-only diagnostic 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?

Exactly two sentences, front-loaded with the tool's function and followed by a practical usage note. 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 zero-parameter tool with an output schema, the description supplies the essential context: what it checks, when to use it, and a security guarantee. It could add an explicit 'when not to use', but that is not essential for this simple diagnostic.

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 has zero parameters and 100% schema coverage, so there is nothing for the description to add. The baseline of 4 applies; the absence of parameter discussion is not a gap.

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

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

The description opens with a specific verb and resource: it shows the configuration state and tests the connection to the uazapi server. This clearly distinguishes check_config from the chat/media/instance sibling tools, which all focus on data operations rather than configuration diagnostics.

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 gives an explicit trigger: 'Use quando as outras tools falharem' (use when the other tools fail), which tells an agent when to reach for this tool. It does not list specific alternative tools by name, but the fallback diagnostic context is clear enough.

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

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

With no annotations, the description must disclose side effects and edge behavior on its own; it only states that details are returned and implies a read operation. It doesn't mention what happens for invalid chat IDs, whether any state changes occur, or auth/instance requirements.

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 sentence, front-loaded with the resource and return fields, no filler. It could be a bit richer given the sparse schema, but as written it is 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?

Despite an output schema likely covering return fields, the description fails to document required input semantics, instance handling, or selection against siblings. For a two-parameter tool with 0% schema coverage, this is materially incomplete.

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

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

Schema coverage is 0% and the description does not explain the chat or instance parameters beyond implying chat is a contact/group. It doesn't specify the accepted format (identifier vs name) or the role of instance, leaving the agent to guess.

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?

Description clearly states it retrieves details (identifier, name, group flag, last message) for a contact or group, matching the get_chat_info name and separating it from message-list/send tools. However, it doesn't explicitly contrast with siblings such as list_chats, list_groups, or get_messages, so it misses the top 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?

No guidance on when to choose this tool over get_messages, list_chats, or list_groups, nor any prerequisites such as having an instance or chat identifier. An agent must infer the intended use from the name and sibling context.

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?

The description discloses a meaningful side effect (downloads to disk) and an extra behavior (audio transcription returns with the audio), which is valuable because no annotations are provided. However, it does not mention permissions, failure behavior, or whether the operation is safe or mutating beyond downloading files, leaving some behavioral gaps.

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

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

The description is compact, front-loaded with the core action, and organized into purpose, parameter hint, and usage guidance. Every sentence earns its place and there is no redundant 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?

The tool has 7 parameters, no annotations, and no schema descriptions, so this is a high-information need. The description covers the tool's purpose and one parameter, but leaves date filters, limits, instance selection, and transcription behavior mostly unexplained, which is a significant 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?

With 0% schema description coverage, the description must compensate, but it only explains the 'tipos' parameter values. It does not clarify 'chat', 'since', 'until', 'limite', 'instance', or 'transcrever_audios' beyond a hint about transcription, leaving most parameters poorly specified.

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: it downloads media from a conversation to disk and returns local paths. It also lists the supported media types and explicitly distinguishes itself from get_messages, so an agent can tell them apart.

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 provides clear when-to-use guidance: use this tool when you need the actual files, and prefer get_messages for reading the entire conversation. This explicit routing to an alternative makes the usage boundary unambiguous.

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

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

No annotations are present, so the description carries the disclosure burden. It usefully discloses that audio comes back transcribed via ElevenLabs Scribe v2 and that media files are written to disk with the path returned in the transcript for the Read tool. It does not mention pagination, ordering, or instance/auth behavior, but the main side effects are surfaced.

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

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

The description is compact, front-loaded with the purpose, and organized as a short parameter reference. Every line adds useful information, and there is 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?

The definition covers the operation, key parameter formats, and side effects, but with 9 parameters and no annotations it is not fully complete: limite, instance, and apenas_nossas remain undocumented. Since an output schema exists, return values do not need to be described, so the gap is manageable but still 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?

With schema description coverage at 0%, the description is the only source of parameter meaning. It documents chat, since/until with exact formats, transcrever_audios, baixar_midias, and tipo_mensagem with examples. However, limite, instance, and apenas_nossas are left unexplained, which is a significant gap.

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

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

The description opens with a specific verb and resource: reading messages from a conversation within a time window, with audio transcriptions. It clearly conveys the retrieval purpose and likely scope, but it does not explicitly distinguish this from sibling tools such as search_messages.

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 first sentence implies the use case: retrieving conversation messages by time range, with optional transcription and media download. However, it does not provide explicit when-to-use versus alternatives guidance, nor any exclusions such as 'for searching, use search_messages instead.'

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It does disclose useful behavior: sorting by most recent, filtering by name fragment, and type-to-group/DM mapping. It does not state whether this is a read-only operation, what happens with pagination/limit, or what the response shape contains, though an 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?

The description is compact, front-loads the primary action, and then provides one terse instruction per parameter. No filler or redundant restatement of the tool name is present.

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 listing tool with an output schema, the description covers the core call shape well. It is incomplete in that 'limite' is not described and no guidance is given about when list_groups would be the better sibling choice; still, an agent can invoke the tool successfully with the information provided.

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

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

Schema description coverage is 0%, so the description must compensate. It adds genuine meaning for three parameters: 'busca' filters by contact/group name, 'tipo' enumerates 'all'/'group'/'dm', and 'instance' supports name-or-number with empty-as-default. Only 'limite' is left unexplained beyond its title/default.

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 opens with 'Lista conversas ordenadas pela mais recente', a specific verb, resource, and sort order. It does not explicitly contrast itself with sibling list_groups, but 'conversas' plus the type filter makes the scope reasonably clear.

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

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

The description gives concrete field-level usage: 'busca' is a contact/group name fragment, 'tipo' accepts 'all'/'group'/'dm', and 'instance' falls back to default. However, it never says when to prefer this tool over a sibling such as list_groups, and it does not state any 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?

With no annotations, the description bears the transparency burden. 'Lista' signals a read-only listing, and the description adds scope and output detail (group identifier), but it does not mention authentication requirements, rate limits, pagination, or ordering behavior. Still, it is not misleading and communicates the core behavior.

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

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

The description is a single front-loaded sentence with no filler, and every clause adds meaning ('groups', 'the number participates in', 'with the identifier'). It is concise, though slightly under-specified in other dimensions.

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 tool with three parameters, no annotations, and no parameter descriptions, a one-sentence description is not enough for fully informed invocation. The existence of an output schema covers the return shape, but context about how parameters interact and how this tool relates to sibling chat/group tools 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 0% and the description says nothing about 'busca', 'limite', or 'instance'. A caller cannot learn how to filter, cap results, or select an instance from either the description or the schema's property titles. The description therefore does not compensate for the missing parameter documentation.

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 uses a specific verb ('Lista'), names the resource ('grupos'), and scopes it to 'o número participa', with the added detail that each group identifier is returned. This is clear, but it does not explicitly distinguish list_groups from the sibling list_chats, so it falls one step 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 'de que o número participa' implies the tool is meant for retrieving groups associated with the WhatsApp number, so the use case is reasonably clear. However, it never names alternatives or explains when to prefer list_groups over list_chats or get_chat_info, 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?

No annotations are provided, so the description carries the burden. It clearly frames the operation as listing available instances, implying a read-only, non-destructive action. However, it does not explicitly state that it makes no changes or mention any auth or server requirements. For a simple listing tool this is adequate but minimal.

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: the first states the core action, the second gives a practical usage tip. Every sentence earns its place, with 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?

The tool is simple, has one optional boolean parameter, and an output schema is present, so return values are documented elsewhere. The description covers what is listed and why to call it, though it omits explicit parameter behavior. Overall it is sufficient for 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?

The schema has one parameter, `apenas_conectadas`, with 0% description coverage, and the description does not mention this parameter or explain what true/false does. The parameter title is self-explanatory, but the description fails to compensate for the missing schema description, adding no parameter-level meaning.

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 action ('Lista') and a concrete resource ('as instâncias (números de WhatsApp) disponiveis no servidor uazapi'), and it explains the tool's purpose: discovering the value to pass in `instance` for other tools. This clearly differentiates it from sibling tools like list_chats and list_groups.

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 explicitly says when to use the tool: 'Use para descobrir qual valor passar em `instance` nas outras tools.' This is clear usage guidance. It does not document when not to use it or name alternatives, but the intended context is obvious from the sibling tool set.

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

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

No annotations are present, so the description carries the full burden. It discloses that the action is a mutation (marking messages), but it does not explain whether the operation is idempotent, whether it affects only unread messages, how the 'quantidade' parameter bounds the action, or any consequences such as sync behavior or permission requirements.

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

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

The description is a single efficient sentence that starts with the action verb and contains no filler. It is concise and front-loaded, though its brevity limits how much context it provides.

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

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

For a mutation tool with three parameters and no annotations, the description is too sparse. It leaves ambiguity about which messages are marked, what 'quantidade' means, what 'instance' refers to, and what kind of confirmation or resulting state can be expected. The presence of an output schema does not compensate for missing parameter and behavior semantics.

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

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

Schema description coverage is 0%, and the description does not explicitly explain any of the three parameters. It loosely hints at 'chat' and 'quantidade' through 'conversa' and 'últimas mensagens', but the meaning of 'instance' and the precise effect of 'quantidade' are left undefined.

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 uses a specific verb, 'Marca' (marks), and a clear resource: the latest received messages of a conversation. This distinguishes it from sibling tools like send_text or get_messages, and makes the action immediately identifiable.

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 says what the tool does but provides no guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions. There is no explicit routing or contextual hint beyond the tautological 'when you need to mark as read'.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully reveals that an empty emoji removes the reaction, which is a non-obvious behavior. It does not cover permissions or additional side effects, but the most important behavioral edge case is documented.

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

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

The description is extremely concise: two short sentences with no filler. The core action and the non-obvious empty-emoji behavior are both front-loaded, so every sentence earns its place.

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

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

The tool is simple and has an output schema, so not documenting return values is acceptable. However, with no annotations, the description should at least hint at the purpose of the optional instance parameter and the behavior when emoji is omitted entirely. The current text is minimally adequate but leaves some call-time 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 0%, so the description must compensate for parameter meaning. It only clarifies the emoji behavior and leaves chat, message_id, and especially instance semantically under-specified. The required parameters are only explained by their titles.

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

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

The description states a clear verb+resource: 'Reage a uma mensagem' (react to a message). It does not explicitly differentiate from siblings, but no sibling appears to duplicate the reaction functionality directly.

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 intended use is implied by the description, but there is no explicit guidance on when not to use this tool or how it compares to alternatives like send_text or send_media. It gives a clear context but no exclusions or 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?

With no annotations, the description carries the full burden of disclosing behavior. It usefully warns that 'a uazapi não busca texto no servidor,' meaning the search is limited to locally available recent messages. However, it does not disclose pagination, result ordering, or whether the operation has any side effects, which leaves meaningful behavioral gaps for a search 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?

The description is short and front-loaded with the core purpose. The parenthetical about server-side search is useful and does not waste words. The chat-mode guidance is compact and adds operational clarity. It could be slightly better structured with explicit parameter notes, but it remains appropriately sized.

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 has five parameters, no annotations, and zero schema description coverage, so the description needs to do substantial work. It covers termo and chat adequately but omits the meaning of since, instance, and limite_chats. The output schema exists, so return format is covered elsewhere, but the parameter gaps leave the description incomplete for confident 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 0%, so the description must compensate. It explains the semantics of chat ('chat vazio = varre os chats mais recentes; com chat, busca só nele') and implicitly clarifies termo as the search term. But it leaves since, instance, and limite_chats unexplained, and their role is not inferable from names alone for an AI agent.

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: 'Procura um termo nas mensagens recentes' (searches for a term in recent messages). It also clarifies behavior with and without a chat argument, which distinguishes it from generic message retrieval tools like get_messages. However, it does not explicitly name sibling alternatives or contrast search_messages against 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 description gives practical usage guidance for the chat parameter: empty chat scans recent chats, filled chat searches only in that chat. This implies when to use each mode, but it does not explain when to choose search_messages over siblings like get_messages or list_chats, nor does it state any exclusions or limitations beyond the server-side search caveat.

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

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

With no annotations provided, the description carries the full burden and does disclose a material behavioral trait: two-step confirmation. However, it does not explain the mechanics of that confirmation, side effects of sending, or what the confirmar parameter actually controls.

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 text is compact, front-loads the core action, and adds a useful list of media types without redundant filler. It earns its place, though the tipo list is telegraphic and could be formatted slightly more cleanly.

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

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

Given six parameters, no annotations, and an output schema, the description covers only the operation and media kinds. It omits the required chat target, confirmation semantics, and most parameter behaviors, so an agent cannot reliably construct a correct call.

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

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

Schema description coverage is 0%, so the description must compensate, but it only covers two parameters: arquivo (local or URL) and tipo (enumerated values). The required chat parameter, legenda, instance, and confirmar are left unexplained.

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

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

The description states a specific action ('Envia um arquivo local ou URL') and identifies the resource scope as media, which is distinct from sibling send_text. It also enumerates the accepted media categories, making the tool's purpose unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives like send_text, get_media, or transcribe_file. The reference to send_text is only about the confirmation behavior, not a usage condition or exclusion.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It transparently explains the two-step confirmation, that the first call does not send anything, that a preview is returned, and that sending only occurs after confirmation. This is exactly the kind of side-effect-related behavior an agent needs to know.

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

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

The description is only three sentences, with the purpose stated first and the procedural instructions kept tight and readable. Every sentence earns its place; there is no filler or repetition.

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

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

For a mutation tool with no annotations, the description covers the essential safety and sequencing behavior well. It still leaves the optional instance and responder_id parameters unexplained, which matters in multi-instance or reply-context scenarios, but the core invocation path is fully specified.

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

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

Schema description coverage is 0%, so the description must compensate for parameter explanations. It clearly explains confirmar's False/True contract, but it does not explain chat, texto, instance, or responder_id beyond their bare titles. Since most parameters are undocumented in both schema and description, the compensation is incomplete.

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 opens with 'Envia uma mensagem de texto', a specific verb and resource that clearly identifies the tool's function. This also differentiates it from the sibling send_media, which handles media rather than text.

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 explicit step-by-step usage: call with confirmar=False, nothing is sent, show the preview, then call again with confirmar=True only after user approval. This is unambiguous operational guidance and leaves little 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?

With no annotations, the description carries the behavioral burden on its own. It discloses that the operation is asynchronous, requires the phone to be online, and that results are not returned directly but appear later in get_messages. This is useful context, though it does not mention possible errors or side effects.

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 add value: the action, the usage condition, and the asynchronous behavior. The most important information is front-loaded and nothing is 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?

The description covers the core operational context: when to use, prerequisite, async nature, and where results appear. It is slightly incomplete only because parameter semantics are left undefined, but an output schema exists and the tool's purpose is clear.

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

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

Schema description coverage is 0% and the description does not explain any of the three parameters (chat, instance, quantidade). An agent must guess what 'quantidade' refers to or what 'instance' identifies, because neither the schema nor the description clarifies 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?

The description identifies a specific action ('Pede ao celular o histórico antigo de uma conversa') and marks it as asynchronous, distinguishing it from the sibling get_messages. This lets an agent recognize exactly what the tool does and how it differs from normal message retrieval.

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 gives an explicit condition: use only when get_messages cannot reach the requested period because the platform keeps a short window. It also states a prerequisite (phone online) and postcondition (messages appear in get_messages after seconds/minutes), so the agent knows when and how to invoke 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?

With no annotations, the description carries the behavioral burden. It clarifies that the file must be local and that the operation uses a specific model, but it does not mention potential upload/privacy implications, accepted formats, or failure behavior. The output schema likely covers return values.

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 primary action is front-loaded, and the second sentence adds useful context about the source of audio files.

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: one required parameter, an output schema, and a clear purpose. The description covers the input source and workflow context, tying into get_media. Minor omissions like format requirements are not critical enough to reduce completeness further.

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

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

Schema description coverage is 0%, so the description must compensate. It does by indicating that 'caminho' refers to a local audio file and by referencing get_media as a source. It lacks details like accepted file extensions, but the single required path parameter is reasonably clear.

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 uses a specific verb ('Transcreve') and resource ('arquivo de áudio local'), and names the exact model (ElevenLabs Scribe v2). It clearly differentiates this tool from siblings like get_media or send_text by focusing on local audio transcription.

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

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

It states the intended context: audio already downloaded by get_media or brought in from elsewhere. It does not explicitly list exclusions, but there is no alternative transcription sibling, so the guidance is sufficient.

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