PostLake

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

Even though there are no annotations, the description discloses key behavioral traits: the tool only works in the 'scheduled' state, and cancelling is free with no refund because nothing was spent. This goes beyond a simple action statement, though it does not detail error handling or return 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 concise sentences, each adding value: purpose, condition, and alternative. No redundant or tangential information. Front-loaded with the core action.

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 tool with one parameter and no output schema, the description covers purpose, precondition, alternative, and cost. It could additionally explain what happens on failure (e.g., if post is not found or not in scheduled state), but overall it is quite complete for the tool's complexity.

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

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

The schema has 100% description coverage for the 'id' parameter, so the schema already explains it as 'The scheduled post id (post_…).' The description adds no additional parameter context. Baseline 3 is appropriate since 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?

The description clearly states the verb ('cancel') and resource ('scheduled post') and its intended effect ('so it never fires'). It also distinguishes itself from the sibling tool delete_post by specifying that delete_post is for posts that have already gone out, making the 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?

Explicitly states when to use this tool ('while it is still in 'scheduled' state') and when to use an alternative ('Once it has gone out, use delete_post to retract it from the networks instead'). This provides clear decision-making guidance for the agent.

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. It discloses that the tool only works on credential-based networks, requires an app password (revocable and limited), and that calling with just platform returns field requirements. However, it does not mention potential side effects like overwriting an existing connection or the exact return value, 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 six sentences, but every sentence earns its place: action, condition, concrete example, alternative, security warning, and discovery hint. It is front-loaded with the core purpose and no unnecessary filler. Length is justified by the critical constraints.

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 the absence of an output schema and annotations, the description does well to explain the dynamic behavior (discover fields) and the consent-screen alternative. However, it does not describe what a successful response looks like or mention any prerequisites (e.g., the tool may require prior authentication), so it is not 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the 'fields' parameter as credentials and the discovery workflow ('Call without it once to be told the field names'). It also clarifies that 'platform' is the network (e.g., Bluesky). This goes beyond the schema's basic descriptions.

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+resource: 'Connect a social channel using credentials its owner gives you.' It clearly distinguishes from the sibling tool get_connect_link by contrasting credential-based vs. consent-screen flows, and the sibling disconnect_account implies the reverse operation. The purpose is unambiguous.

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

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

The description explicitly states when to use this tool ('only works on networks that authenticate with a credential') and when not to, directing users to get_connect_link for consent-screen networks. It also provides concrete security guidance (never ask for main account password; use app passwords) and a usage hint to call with just platform to discover required fields. This is explicit and actionable.

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

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

With no annotations, the description carries full burden of disclosing safety-critical behavior. It reveals that the key has full account access, is shown only once, cannot be retrieved again, and should be stored/passed immediately. This goes well beyond generic mutation warnings.

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 three tightly packed sentences. Each sentence earns its place: purpose, usage context, and critical behavioral caveats. There is no redundancy or fluff, 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?

For a one-parameter tool with no output schema and no annotations, the description covers everything an agent needs: what it does, when to use it, security caveats, and parameter naming guidance. Nothing meaningful 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?

The schema already describes the 'name' parameter fully (100% coverage), so the baseline is 3. However, the description adds crucial practical meaning: the name is all anyone has later when deciding if the key is still needed. This reinforces and extends the schema description, making it more actionable.

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: 'Create a new PostLake API key.' It clearly distinguishes this tool from siblings by focusing on API key credentials and explicitly states the use case for setting up another agent or service.

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: when setting up another agent/service that needs its own credentials rather than sharing yours. It implies the alternative of sharing credentials but does not provide an explicit when-not or name alternative tools. Clear enough for most agents.

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 transparency burden. It discloses the normalized per-platform result with live URLs, scheduling behavior, and best-effort firstComment failure handling in the parameter docs. It doesn't enumerate all side effects, but the key publishing behavior is clearly communicated.

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 purpose, using backticks for parameter names. No filler; every sentence contributes target-selection, timing, or return-value 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 complex 15-parameter tool with no output schema and no annotations, the description covers the core workflow, target resolution, scheduling, and the result shape. The rich schema descriptions fill in the rest, though a pointer to validate_post or upload_media as adjacent steps would make it even more 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 baseline is 3. The main description adds meaning by explaining how 'profile', 'platforms', and 'accounts' relate and by stating the 'at least one' targeting constraint—valuable context beyond individual schema descriptions.

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 'Publish (or schedule) one post to one or more connected accounts'—a specific verb with a clear resource and scope. This clearly distinguishes it from sibling tools like edit_post, delete_post, and validate_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?

Provides clear context for use: explains the simple 'profile' + 'platforms' targeting vs the precise 'accounts' targeting, requires at least one, and notes that omitting scheduledAt publishes now. It doesn't explicitly mention alternatives like validate_post for dry-runs, but the guidance is otherwise 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the slugification process, explaining that the name is converted into an identifier used on other calls, and that the response indicates the resulting slug. This is useful beyond basic 'create' semantics.

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 three concise sentences, each contributing value: definition, parameter guidance, and usage timing. It is front-loaded with the main purpose and contains no unnecessary 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is remarkably complete. It explains what the tool does, how to use the parameter, and when it should be used, including the crucial slugification detail.

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 already provides a good parameter description with an example, so the baseline is 3. The description adds meaningful guidance about style ('as a person would write it') and clarifies the identifier's role in subsequent calls, enhancing the parameter's 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 clearly states the tool's purpose: 'Create a profile: a named set of connected channels, usually one brand or client.' It uses a specific verb and resource and distinguishes create_profile from sibling tools like rename_profile and update_profile by focusing on the creation of a profile 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?

Provides explicit timing guidance: 'Create one before connecting channels when an account is running more than one brand.' This gives clear context for when to use the tool, though it does not explicitly name alternatives 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It thoroughly explains the tool's side effects: removes from each network, reports targets separately, handles networks that don't allow deletion, and is irreversible. This gives the agent a clear model of what happens.

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 core action, and every detail earns its place. It covers purpose, alternatives, edge cases, and consequences without fluff.

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

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

For a single-parameter tool with no output schema, the description is complete. It explains the return behavior (per-target reporting), network limitations, irreversibility, and differentiation from cancel_post, giving the agent all needed 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?

The only parameter (id) is fully documented in the schema with 100% coverage. The description does not add additional meaning beyond the schema's 'The post id (post_…).' Since schema coverage is complete, 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 clearly states the tool retracts a live post and removes it from networks, immediately distinguishing it from cancel_post for scheduled posts. It uses strong verbs and specific context ('ALREADY LIVE', 'undo') that make the purpose unmistakable even among 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?

Explicitly says when to use ('when a post was wrong') and directly names the alternative tool for different cases ('Use cancel_post instead for something scheduled'). Also warns about irreversibility, which is essential usage guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that the operation disconnects every channel, that reconnecting requires owner approval which the user cannot provide, that it refuses by default, and that it reports exactly which channels would be affected. This is thorough and safety-critical.

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 three sentences, starts with a clear action, and then provides necessary warnings. No filler 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?

Given the tool's high-risk nature, the description covers the core behavior, the side effects, the safeguard (refusal) and the force condition. No output schema exists, so return values need not be explained, but the error behavior is indicated. Sufficient for an agent to invoke safely.

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 input schema provides base descriptions for both parameters, but the tool description adds critical meaning to 'force' by explaining the default refusal and the consequences of force. It clarifies that force should only be used after human consent, going beyond the schema's one-line note.

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 'Delete a profile,' a clear verb and resource, and then describes the side effect. It distinguishes itself from sibling tools like delete_post and disconnect_account by focusing on profile deletion. The wording 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 description explicitly states when not to use the tool (when channels are attached, unless force), and when force is appropriate (only after human agreement). It doesn't name an alternative sibling tool, but it gives clear conditions for safe usage.

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 behavioral disclosure. It explicitly states that published content is unaffected, no posts are deleted, and reconnection requires owner approval. This goes beyond a simple action description and prevents user misconceptions about 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?

The description is four sentences, all directly relevant. The first sentence states the core purpose, and subsequent sentences add critical behavioral caveats and usage instructions. Every sentence earns its place; there is no redundancy or irrelevant 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 one-parameter tool with no output schema, this description is complete. It covers the purpose, side effects, reconnection caveat, and parameter source. No important information is missing for proper tool invocation and understanding.

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 description for account_id already states 'The social account id from list_social_accounts.' The description repeats this information without adding new meaning. Since schema coverage is 100%, a baseline of 3 is appropriate; the description adds no extra semantic value beyond what the schema already 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?

The description clearly states the action: 'Disconnect one social channel from PostLake.' The verb 'disconnect' is specific, and the resource is clearly identified. It distinguishes itself from sibling tools like connect_account and list_social_accounts by explicitly describing the opposite action and its scope.

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 provides explicit usage guidance: 'only disconnect when someone has actually asked you to' and warns about the reconnection requirement (owner approval). It also directs the user to the correct id source, list_social_accounts, which is critical for proper invocation.

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 discloses key behavioral constraints: only scheduled posts can be edited, new time must be future, and targets are fixed. It doesn't mention return values or error behavior, but the main safety and mutation aspects are conveyed.

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 action, and every sentence adds necessary context. 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 mutation tool with no output schema, the description provides solid contextual guidance: when to use, constraints, and alternatives. It omits what the tool returns and does not mention the textOverrides parameter, but schema covers that. Overall, it is nearly complete, with minor gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it reiterates the future time constraint already in scheduledAt's schema description, and does not mention textOverrides. However, it does explain that text and scheduledAt are the editable fields.

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 clearly states the tool changes a scheduled post's text and/or fire time, which is a specific verb+resource. It also distinguishes from siblings by explicitly saying to change targets one must cancel and create a new post, differentiating from cancel_post and create_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?

It explicitly states when to use: only for scheduled posts, and provides an alternative action ('cancel it and create a new one') for changing targets. This gives clear contextual guidance and 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, the description bears the burden of disclosing side effects. It adds valuable context: cost on X (6 credits, free elsewhere), behavior on unsupported networks (refuses and explains), and a guarantee that nothing silently does nothing. It doesn't cover rate limits or idempotency, but the disclosed traits are significant.

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 moderately detailed but every sentence earns its place, covering the action list, target types, cost, and error behavior. It could be slightly more structured but remains concise without fluff.

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 no output schema or annotations, the description covers purpose, target semantics, cost, and error behavior. It doesn't detail return values or all possible failure modes, but it includes enough context for an agent to invoke it correctly in most scenarios.

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 basic parameter descriptions, but the description adds critical nuance: target is a post URI/URL for like/repost and a handle for follow/block/mute. It also clarifies the action parameter is an enumeration and account is a connected id. This goes beyond the schema's minimal 'What to do.'

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 clearly identifies the tool as an engagement tool with a specific list of actions (like, repost, follow, etc.) on posts or accounts. This distinguishes it from sibling tools like create_post/delete_post which manage the user's own content, and list_social_accounts which merely lists accounts.

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 'One tool for all of them: pass the action' explicitly states this is the single tool for all engagement actions, and the target mapping (post for like/repost, person for follow/block/mute) provides clear guidance on when to use it. However, it doesn't explicitly mention alternative tools for similar tasks, but the scope is unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It adds valuable behavioral context: 'Missing data is reported honestly, never fabricated' and signals the tool provides synthesized insights ('decisions, not just measurements'). It does not explicitly state read-only behavior, but the analytics context implies it.

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 three sentences and approximately 50 words. It front-loads the purpose, then enumerates outputs, and includes an honesty guarantee. The final sentence about periodDays is slightly redundant with the schema but not wasteful.

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 thoroughly explains all return components: readable summary, totals, per-platform breakdown with engagement rates, recent daily activity, top posts, best posting times, and recommendations with reason/confidence. It also addresses data quality behavior, making it complete for an agent.

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 the parameter fully described in the schema ('Lookback window in days (1–365, default 30)'). The description repeats the default but adds no additional semantic meaning beyond what the schema already 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?

The description states it provides 'cross-platform analytics over a period' and enumerates specific outputs (summary, totals, per-platform breakdown, recommendations). This clearly differentiates it from sibling tools like get_post_analytics (per-post) and list_posts (listing posts).

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 clearly implies use for account-level period analytics ('cross-platform analytics over a period') but does not explicitly mention alternatives or when not to use it. It provides clear context but no 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 provided, the description carries full burden. It discloses critical behaviors: the human approval requirement, the link being signed, single-use, and 30-minute expiry. This adds meaningful context beyond a simple 'create link' definition.

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 somewhat lengthy but each sentence adds value: purpose, rationale, usage trigger, link behavior, and optional parameter. It is front-loaded with the core action and well-organized, though it could be slightly tighter.

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 with one optional parameter and no output schema, but the description covers the key context: when to use it, why human involvement is needed, link properties, and the profile option. It does not detail response format, but that is likely inferable from the described link.

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 clear description for the only parameter. The tool description echoes the optional profile parameter without adding substantial new meaning, so the baseline score 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?

The description clearly states the tool creates a one-tap link for connecting a social channel, which is a specific verb-resource combination. It distinguishes itself from siblings like connect_account by emphasizing the human approval requirement and the link-based flow.

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?

Explicit conditions are given: call this when list_social_accounts is empty or a channel shows needs_reauth. It also tells the agent to give the person the link rather than directing them to the dashboard, providing clear usage context and implied alternatives.

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's clearly a read-only query (get/returns) and explains exactly what data is returned. However, it doesn't mention authentication, rate limits, or other potential behavior, though for a simple getter this is mostly acceptable.

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?

Four sentences, each with a distinct purpose: what it returns, why credits matter, when to use it, and alternative. It's front-loaded with the core purpose and free of 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 schema, annotations, or output schema, the description provides all essential context: the exact data fields, the relevance to batch planning, and the relationship to whoami. It fully equips an agent to select and invoke this 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific info because none exist, but it does clarify the semantic meaning of what the return values represent (total, allowance, remaining, pack credits).

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 clearly states the tool returns the account's credit balance (total, monthly allowance, remaining, and pack credits). It distinguishes itself from sibling whoami by explicitly noting it's for when you only need the balance.

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 advises checking before planning a batch to avoid exceeding the balance, and explains that publishing/reads/etc. spend credits. It also contrasts with whoami, suggesting an alternative when more account details are needed.

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 transparency burden. It discloses the output contents, warns about the ~4k token size when `full` is true, and notes the default behavior when `platform` is omitted. It does not explicitly state that the call is read-only, but the nature of 'get capabilities' makes side effects unlikely.

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 compact, front-loaded set of sentences that immediately communicate the tool's purpose, key output facets, and a crucial usage directive. Every sentence earns its place without 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?

Despite having no output schema, the description fully inventories the return contents, making the output predictable. Combined with usage instructions and parameter behavior, it provides enough context for an agent to select and invoke the tool 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?

The input schema already provides 100% descriptive coverage for both parameters, including details about `full` returning everything and token size, and `platform` being optional. The tool description adds no significant parameter semantics beyond what is already in the schema, though it reinforces the omission behavior.

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 ('get') and resource ('platform capabilities'), enumerating exactly what data is returned: character limits, media rules, first comment support, async publishing, and platformOptions fields. This clearly differentiates it from sibling tools like get_analytics or get_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?

Explicitly instructs to 'Call this before create_post to construct a valid post', giving a clear when-to-use directive. It also explains the `platform` parameter omission behavior, providing actionable guidance for both comprehensive and per-platform usage.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the return is the complete record and enumerates its contents, which is useful behavioral information. However, it does not cover edge-case behavior such as what happens when the id doesn't exist, error handling, or permissions, leaving some transparency 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?

Two sentences: the first is a front-loaded summary of the tool's output, the second provides usage guidance. Every clause adds value; there is 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?

With one simple parameter, no output schema, and no annotations, the description compensates by explicitly listing what the returned record includes and when to use the tool. It provides enough context for an agent to invoke the tool correctly and interpret the result, despite lacking explicit error-handling notes.

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 'id' parameter is described as 'The post id (post_…)'). The description adds no semantic value beyond reinforcing the id format; it does not mention any constraints or additional meaning. 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?

The description uses a specific verb 'Fetch' and resource 'post by id', and clearly states the scope: 'the COMPLETE record' with a detailed list of contents. It distinguishes itself from siblings by naming create_post and list_posts as alternatives with different levels of detail.

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?

Explicit usage guidance is provided: 'Use this when you need the whole object' contrasted with 'create_post already told you what happened' and 'list_posts gives you the summary rows.' This tells the agent exactly when to pick this tool over those alternatives.

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 behavioral disclosure. It explains the important behavior that unavailable analytics are shown as 'no data' rather than zeros, and justifies the deliberate omission of follower counts. This adds valuable context beyond just stating what the tool does.

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 two sentences that front-load the core purpose, then provide essential behavioral nuance. 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?

For a simple one-parameter tool with no output schema, the description is remarkably complete. It specifies the metrics returned, the per-platform scope, the live URL, the 'no data' vs zero distinction, and the absence of follower counts. Nothing critical is missing for an agent to use it correctly.

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

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

The schema already covers the single parameter 'id' with 100% coverage. The description adds no additional parameter-level semantics beyond confirming it refers to 'one post'. Per the baseline rule for high schema coverage, a score 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?

The description clearly states the tool's purpose: 'Get normalised performance metrics for one post, per platform' and lists specific metrics. The scope is explicitly limited to a single post, which distinguishes it from the broader sibling tool 'get_analytics'.

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 clearly implies when to use this tool: when needing per-post analytics. It also provides guidance on what to expect (live URL, per-platform breakdown) and explicitly warns about the absence of follower counts. However, it does not name alternative tools for other use cases, so it's clear context without 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?

No annotations are provided, so the description carries the full burden. It discloses the specific data returned (privacy options, comment/duet/stitch settings, max duration) and the 'Live' qualifier implies a read-only operation. However, it does not explicitly state side-effect-free behavior, error conditions, or authentication requirements, which are left implicit.

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 two sentences. The first sentence front-loads the resource and its key data fields; the second provides a direct usage instruction. Every word earns its place, with no irrelevant 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 one-parameter getter with no output schema, the description adequately explains what data will be returned and why to use it. It names the specific fields returned, which is sufficient for a basic tool. It could mention behavior for invalid account IDs, but this is not critical for a low-complexity 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?

The schema covers 100% of the single parameter with a clear description ('A connected account id (acc_…) from list_social_accounts'). The tool description does not add meaning beyond that, so the baseline score 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?

The description clearly states the tool's purpose: retrieving live creator-level publish constraints for one connected account. It lists specific data (privacy options, comments/duet/stitch permissions, max video duration) and distinguishes itself from broader tools like get_platform_capabilities by scoping to a specific creator and account.

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

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

The description provides explicit usage guidance: 'Use it to pick a valid privacyLevel before posting to TikTok.' This gives clear context for when to invoke the tool. It doesn't name alternatives or exclusions, but the instructional context is sufficient for a simple getter.

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?

Given no annotations, the description carries the full burden. It implicitly indicates a read-only list operation, explains the empty return behavior for platforms without sub-destinations, and tells how to use the output. It does not cover errors or auth, but for a simple read tool this is adequate.

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 three sentences, each earning its place: purpose, usage, and edge case. It is front-loaded with the core function and contains no redundant words.

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

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

For a simple tool with one parameter and full schema coverage, the description covers purpose, how to use the result, and an important caveat. The absence of an output schema is acceptable given the straightforward 'list' nature and the extra context 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?

The schema already provides 100% parameter description with the accountId field, so the baseline is 3. The description does not add additional parameter-level meaning beyond what the schema states; it only mentions the returned id, which concerns output, not the input parameter.

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

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

The description uses a specific verb 'List' and clearly identifies the resource: 'postable destinations INSIDE one connected account.' It also provides concrete platform examples (Facebook Pages, Pinterest boards, YouTube channels) that distinguish it from the sibling tool list_social_accounts.

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 clear context on when this tool is useful (platforms where a single login exposes several destinations) and instructs using the returned id in platformOptions. It lacks an explicit statement of when not to use or naming alternative tools, but the context is sufficient.

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. It discloses pagination behavior, ordering, and error handling via 'problems names any network that could not be read.' These are meaningful beyond what the name alone implies, though it could explicitly state read-only nature 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?

Three concise sentences, each adding value: what it lists, when to use it, and behavioral details. No redundant phrasing 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?

Without an output schema, the description covers return contents (participants, last message, unread count), ordering, pagination, and partial failures. It is sufficient for a list tool, though it could mention what happens when no networks have DMs.

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 description adds little beyond that. The 'Cursor-paged' note reinforces the cursor parameter's purpose, but otherwise the schema already explains limit, cursor, and account.

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 clearly states the tool lists direct message threads across connected networks, with specifics like ordering, participants, last message, and unread count. It distinguishes itself from sibling tools like read_conversation (which reads a single conversation) and list_posts.

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?

Provides a clear usage trigger: 'Start here for any new DMs.' This effectively tells when to use this tool. It does not explicitly mention alternatives a user might consider, but the context is strong enough to guide selection.

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

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

With no annotations, the description carries the full burden and does well: it explains cursor-paged behavior ('pass the returned cursor back verbatim') and the `problems` field semantics, which prevents silent empty results. It also implies read-only behavior by describing a list operation. This goes beyond basic schema info, though it doesn't address authorization or rate limits explicitly.

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 three sentences, each serving a distinct purpose: what it returns, when to use it, and how pagination/error reporting work. It is front-loaded with the core purpose and wastes no words. Every sentence adds value, making it a model of concise, well-structured tool documentation.

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 list tool with no output schema, the description covers all essential aspects: content scope, ordering, pagination mechanics, and error semantics (`problems`). It also clarifies the edge case of an empty list, which is valuable context. The description is sufficiently complete for an agent to understand what to expect and how to handle the response.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaningful context beyond the schema: it explains the cursor is opaque and should be passed back verbatim, and that omitting `account` reads every connected network. This supplements the schema's descriptions, particularly for cursor usage and the account's default behavior.

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: 'What happened across every connected network' and enumerates concrete event types (likes, replies, mentions, follows, reposts, quotes), newest first, in ONE normalised shape. This clearly distinguishes it from siblings like list_posts or list_conversations, which cover different content types. The phrase 'the read to start from' reinforces its specific role among the sibling 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?

The description explicitly defines when to use this tool: 'when asked what needs my attention or did anyone reply'. It gives a clear use-case context that is not present in the schema. However, it does not name alternative tools or state when not to use it, so it falls short of the full 'when/when-not/alternatives' bar.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It adds meaningful detail: posts are listed most recent first, each with per-platform status, and it explains pagination semantics (limit default 50, cursor from nextCursor). It does not explicitly state read-only, but that is inherent in the verb 'list' and the absence of mutation hints.

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 three short sentences, each earning its place: the first states the primary purpose and result, the second gives a specific usage example, and the third covers pagination. No filler or redundancy; it is front-loaded and scannable.

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 no output schema and no annotations, the description covers essential operational details: ordering, per-platform status, state filtering, and pagination. It does not explain what 'per-platform status' looks like in the response or what happens when state is omitted, but these are minor gaps given the tool's simplicity.

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. The description enhances the schema by explaining that state='scheduled' shows the upcoming schedule, giving semantic meaning to that filter. It also reinforces the cursor/limit mechanics, though these are already in the schema descriptions. This added context pushes the score above 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 opens with a specific action and scope: 'List the caller's posts', includes ordering ('most recent first') and a distinguishing detail ('each with per-platform status'). It clearly differentiates from sibling tools like get_post by focusing on listing multiple posts and from create_post by being a read operation.

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?

Provides clear context for using the tool: how to see the upcoming schedule via state='scheduled' and how to paginate with limit and cursor. However, it does not explicitly state when to choose this tool over alternatives (e.g., get_post for a single post) or 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?

With no annotations, the description carries the full burden. The verb 'List' implies a safe, read-only operation. It adds context about profiles being named buckets and the typical default, which helps set expectations, but doesn't mention edge cases like empty results or 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?

Three sentences, each earning its place. The first states the purpose, the second provides usage guidance, and the third offers a typical-case insight. No wasted words.

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

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

For a zero-parameter, no-output-schema tool, the description is fairly complete. It explains what profiles are, when to call, and the default case. It could be slightly more explicit about the return format, but the mention of passing the name implies the output includes a name field.

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, so the baseline is 4. The description adds relevant context about the `profile` name used in publishing, which indirectly clarifies what the output will contain, even though no parameter details are needed.

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 clearly states the tool's function with a specific verb+resource ('List the caller's profiles') and explains what profiles are. It also distinguishes from sibling profile management tools by framing it as the listing/read operation.

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?

Provides explicit usage guidance: 'call this first if you are not sure which one to post from.' It implies that if you already know your profile, you may not need to call it, but does not explicitly list alternatives or when-not-to-use scenarios.

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. It discloses the scope ('every connected social account'), the meaning of connection statuses, and how the returned ids relate to create_post. It does not mention pagination or error conditions, but for a simple list operation, the added context is sufficient.

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 three sentences, each earning its place: the first states the core function and output fields, the second gives usage guidance tied to create_post, and the third explains a status value and fallback actions. No redundant 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 zero-parameter, no-output-schema tool, the description covers purpose, output contents, usage timing, alternatives when no accounts exist, and status semantics. This is unusually complete and actionably prepares the agent to use the tool effectively in a workflow.

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 schema description coverage is 100%. The description adds no parameter-specific detail, but none is needed. It does clarify the purpose of the ids returned, which indirectly helps the agent understand how they will be used in create_post.

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 clearly states the tool's function with a specific verb ('List') and resource ('every connected social account'), and enumerates the returned fields (id, profile, platform, handle, connection status). It distinguishes itself from sibling tools like list_profiles and list_account_targets by focusing specifically on connected social accounts.

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?

Provides explicit usage context: 'Call this before publishing: the ids are what create_post takes in `accounts`.' It also gives direct alternatives when no accounts are connected ('use get_connect_link for OAuth networks or connect_account for supported credential-based networks') and explains what 'needs_reauth' means.

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 burden of disclosing behavior. It explains the side effect (next list_notifications shows new items only) and the skipping behavior for unsupported networks. However, it does not mention permissions, reversibility, or idempotency, leaving some behavioral aspects undisclosed.

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 two short sentences, front-loaded with the core action. Every clause delivers useful information without redundancy, making it highly concise and well-structured.

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 a simple mutation with one optional parameter and no output schema, the description adequately covers purpose, usage timing, and behavioral nuances. It lacks only minor details like return values or error handling, but these are not essential for this 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?

The schema already provides 100% coverage of the single optional parameter 'account', including its format and meaning. The description adds no additional parameter semantics beyond the schema, so a baseline score 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?

The description clearly states the action: mark notifications as read on networks that support it. It distinguishes itself from sibling list_notifications by specifying the effect on the next list, making the tool's purpose unmistakable.

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 explicitly says to call it after acting on notifications, giving a clear usage context. It also notes networks without a 'seen' concept are skipped, which helps the agent understand when it's safe to invoke. No alternative tools are mentioned as alternatives, but this is a specialized action with no direct 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?

No annotations exist, so the description carries the transparency burden. It explains the aggregation and normalized shape, but doesn't disclose pagination behavior, response format, or side effects (though read-only is implied by the verb). This is moderate for a read tool with simple parameters.

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

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

Two sentences, front-loaded with the main purpose and usage. Every phrase earns its place, no redundancy or fluff.

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 3 simple parameters and no output schema, the description covers the core purpose, input constraint, and usage scenarios. It could explicitly mention pagination or the return type, but the cursor/limit params are self-explanatory and the read behavior 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 coverage is 100%, providing baseline 3. The description adds critical semantics by emphasizing the id must be a PostLake post id (post_…), not a network id. This goes beyond the schema's generic 'The post id (post_…)' and helps avoid misuse.

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 clearly states a specific verb (Read) and resource (replies people left on a post you published), with the scope 'across every network it went to, in one normalised shape.' This distinguishes it from sibling tools like read_conversation (for conversations) and reply_to_comment (for writing).

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 provides clear context on when to use it ('see how a post landed, or to find what needs answering') and an important constraint ('Takes the PostLake post id (post_…), not a network id'). It doesn't explicitly mention alternatives, but this is adequate for a focused read tool.

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 discloses the newest-first ordering, the presence of the fromMe field on each message, and the scoping constraint that conversation IDs are only meaningful on one connection. This is useful, though pagination behavior is left for the schema.

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

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

The description is three sentences, each containing essential information: scope, ordering, message property, and required parameters. It is concise, front-loaded, and has 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?

The description, combined with fully documented schema parameters and no output schema, gives the agent enough to understand the tool's purpose, key behavioral traits, and parameter relationships. It does not explain pagination explicitly, but the schema covers limit and cursor adequately.

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. The description adds real value by explaining that id comes from list_conversations, that account is the connected account id, and that the combination is necessary because IDs are connection-scoped. This goes beyond the schema's field descriptions.

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 clearly states the tool reads messages in one DM thread, sorted newest first. This specific verb-resource combination distinguishes it from siblings like list_conversations (which lists threads) and read_comments (which reads comments).

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 provides clear usage context by explaining that both the conversation id and account are required, and why the account is necessary. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to know when 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 full burden, and it excels. It discloses that channels/posts are untouched, the identifier is re-derived, the old profile string stops resolving, and the response indicates whether the identifier moved. This gives the agent critical side-effect and state-change information.

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 purpose, and every sentence adds value. No redundancy or filler. The structure is tight 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?

Given the tool's moderate complexity (2 params, no output schema, no annotations), the description covers key behavior: non-destructive to contents, identifier implications, and response semantics. Missing details like error handling are not critical for selection. Slight deduction for not explicitly mentioning what happens if the profile does not exist, but overall 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% with clear descriptions for both 'profile' (current identifier) and 'name' (new name). The description adds context by referencing 'old profile string' and 'new name,' but does not introduce new parameter details beyond the schema, so a baseline score 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?

The description clearly states the verb and resource: 'Rename a profile.' It further explains the effect (re-derived identifier, old string stops resolving), which distinguishes it from sibling tools like update_profile. The purpose is unambiguous.

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

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

The description implies usage context (when you need to rename and update references) but does not explicitly say when to use this tool versus alternatives like update_profile. For example, it doesn't mention 'use update_profile for other setting changes.' Thus usage guidance is implicit 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?

No annotations are provided, so the description discloses important behavioral traits: credit costs (6 on X, free elsewhere), that unsupported networks explicitly refuse, and that the comment id comes from read_comments. This goes beyond the bare schema and helps the agent anticipate side effects and 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?

The description is three succinct sentences, front-loaded with the primary purpose, and wastes no words.

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

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

For a simple reply action with no output schema, the description covers purpose, usage, network constraints, and cost. It doesn't specify the return format or success behavior, but for a write operation that's acceptable given the provided 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?

The schema already describes all three parameters with 100% coverage. The description repeats the comment id source from read_comments, which is already in the schema, adding no new semantic information for parameters.

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 clearly states the tool's function: replying to a comment using the comment's id. It also distinguishes from create_post by contrasting with publishing new content, making the 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?

It provides explicit context for when to use this tool: when an agent needs to answer a person's comment, referencing read_comments for the comment id. It also contrasts with create_post, and notes network-specific behavior (free except X, refusal from unsupported networks), giving clear usage guidelines.

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 of disclosure. It reveals that links and mentions are made real, and it discloses cost differences across networks ('Free on supported networks except X, where the write costs 6 credits'). These add meaningful behavioral context beyond basic operation, though it doesn't cover return values or error handling.

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 three sentences long and every sentence adds value: purpose, parameter usage, behavioral/cost notes. It is front-loaded with the core action and efficiently communicates all necessary information without fluff.

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 tool's main behavioral aspects and parameter semantics, but since there is no output schema, it does not describe what the response contains. Given the moderate complexity and the mutation nature, the description is largely complete, though a note on the return value would make it fully robust.

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?

Although the schema already documents all four parameters, the description adds crucial semantics: the mutual exclusivity of 'conversation' and 'to', and the fact that you don't need to create a conversation first. This additional context helps the agent use parameters correctly beyond their individual schemas.

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 'Send a direct message', a specific verb+resource statement. It distinguishes itself from siblings like create_post and reply_to_comment by clarifying it targets direct messages, and further defines two operating modes via 'conversation' or 'to'.

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 clear guidance on when to use which parameter: 'Give `conversation` to reply in an existing thread, or `to` (a handle) to start a new one.' It also reassures that no prior conversation creation is needed. However, it doesn't explicitly contrast with alternative tools, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden and discloses important behaviors: partial update semantics, image handling via public URLs with automatic upload, and the fact that some networks may refuse the operation and will communicate this. This goes beyond a generic update tool, though it does not detail permission requirements or response formats.

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 concise at three sentences, front-loaded with the primary purpose, and contains no redundant information. Every sentence adds value: purpose, update semantics, and image/network behavior.

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

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

Given the tool's moderate complexity (5 params, no output schema, no annotations), the description provides sufficient context for correct invocation: what fields exist, how updates behave, and image handling. It does not explain return values or permissions, but for a profile update tool with no output schema, the provided context is largely 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?

The schema fully documents all parameters, so the baseline is 3. The description adds meaningful value by explaining partial update behavior ('Only the fields you give are changed; the rest are left alone') and clarifying that images are provided as URLs and uploaded automatically, enriching the semantics of avatarUrl and bannerUrl.

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 clearly states the tool's function: 'Change a connected account's own profile' and enumerates the specific fields (display name, bio, avatar, banner). This distinguishes it from sibling tools like create_profile (creating new) and rename_profile (specifically renaming), making its 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?

The description clarifies that it modifies an existing connected account's profile and that only provided fields are changed, which implies use for partial updates. It does not explicitly name alternatives or exclusions, but the context of 'connected account's own profile' and the field list gives clear guidance for most use cases.

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?

Even without annotations, the description fully discloses behavior: it fetches public URLs, returns a short-lived upload target for local files, validates type/size limits for images and videos, and produces a med_ id. This goes beyond basic semantics and covers important operational details.

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 concise yet comprehensive, using a clear conditional structure ('For a public asset…', 'For a file…') followed by a shared validation note and a final warning. Every sentence adds value, and there is 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?

Given the tool's complexity (dual upload modes, validation rules, and no output schema), the description is remarkably complete. It explains both paths, size/type constraints, the med_ id output, and the follow-up PUT action, ensuring an agent can use it correctly without additional 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?

While the schema already describes each parameter (100% coverage), the tool description adds crucial semantic relationships: url is for public assets, contentType is required for local files, and sizeBytes is recommended for binding the signed target to the exact size. This enriches the parameter understanding beyond the schema's field-level descriptions.

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 clearly states the tool's purpose: 'Prepare or upload media so it can be attached to posts.' It specifies the action (upload/prepare), the resource (media), and the output (a med_… id). It also differentiates from sibling tools like create_post by focusing on the media preparation step.

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 usage guidance for two distinct scenarios: public URLs (pass url) and local files (omit url, pass contentType and sizeBytes). It also provides a critical negative instruction: 'Never put file bytes or base64 in the tool call.' This clearly directs when and how to invoke the tool.

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 of behavioral disclosure. It explicitly states the tool does not publish, runs the same validation as create_post, returns per-target errors and warnings, and is free. This transparently conveys the tool's non-destructive, read-only nature and its output shape.

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 exactly two sentences: the first comprehensively states the tool's purpose and scope, and the second offers a usage tip. No word is wasted, and the key 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?

Despite having 14 parameters and no output schema, the description provides enough context: it names the return type ('errors and warnings'), clarifies the validation scope, and gives usage timing. The schema covers all parameter semantics, so the description complements rather than duplicates.

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 already provides detailed descriptions for all 14 parameters, with 100% coverage, so the baseline is 3. The description adds no additional parameter-level semantics beyond referencing general validation categories; it leaves parameter details to 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?

The description opens with 'Dry-run a post WITHOUT publishing,' which clearly states the verb (dry-run/validate) and resource (post). It explicitly contrasts with create_post by noting it runs the exact validation create_post would run, and lists the validation categories, making it indistinguishable from 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?

The description gives explicit timing advice: 'call it before create_post,' and notes that the tool is free, providing a cost rationale for using it as a preflight check. It doesn't explicitly list exclusion scenarios, but the 'before create_post' instruction implies when not to use it (when actually publishing). This is clear context, though not fully exhaustive.

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 fully discloses behavior: it is a read-only introspection call that returns account details, connected channels, credit balance, and agent-specific limits. It also reveals that limits are set by the account owner in the dashboard and cannot be changed from here, adding important context about constraints. The description is transparent about what the tool does and does not do.

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 concise but information-dense, with four sentences that each add value: purpose, return contents, usage advice, and source of limits. It front-loads the core purpose and avoids redundant or generic phrasing. Every sentence earns its place without 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 or annotations, the description must convey what the tool returns, and it does so thoroughly: account, channels, credit balance, posting profiles/networks, daily cap, used/remaining posts. It also provides situational context ("when an agent is calling") and clarifies the source of limits. This fully equips an agent to understand the tool's role.

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 description carries no parameter burden. Per the rubric, a zero-parameter tool receives a baseline score of 4, and the description adds no param details because none exist. The description focuses on return values, which is appropriate for a parameterless introspection tool.

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

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

The description clearly states what the tool does: "Who you are and what you are allowed to do" and then enumerates exactly what it returns (account, channels, credit balance, and agent limits). It uniquely identifies itself as the self-introspection tool among siblings, distinguishing it from more specific tools like get_credits or list_profiles.

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 "Call this first" and explains the rationale: it enables planning work you can complete instead of discovering boundaries through refusal. This provides clear guidance on when to use the tool, although it does not mention alternatives because this tool is uniquely the starting point.

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