socialclaw

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

With no annotations, the description carries full burden. It discloses the nature of the return data (media allowances, text limits, publishing status) and the filtering behavior. While it doesn't explicitly state read-only or mention permissions, the verb 'Get' implies non-mutating access, making this sufficiently transparent for a simple read operation.

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, front-loaded with the main purpose, and the second sentence efficiently covers parameter usage. No redundancy or excessive 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?

Despite lacking an output schema, the description adequately covers return content (media, text limits, publishability) and parameter options. For a tool with two optional parameters, this is complete and self-contained, requiring no additional context to invoke correctly.

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

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

Schema already provides descriptions for both parameters. The description adds value by explaining the combinational semantics: accountId and provider are optional, can be used alone or together? Actually says 'or' implying exclusive, and 'neither' for all. This clarifies how the parameters interact beyond their individual 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 retrieves publish capabilities and provider rules for connected accounts, listing specific aspects (media, text limits, publishability). It distinguishes itself from siblings like get_analytics and get_post by focusing on capability checks rather than usage or content retrieval.

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

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

Provides clear instruction on parameter usage: passing accountId for one account, provider to filter, or neither for all. This gives strong contextual guidance, though it doesn't explicitly compare to alternative tools or state when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses that posts are scheduled or published through connected accounts and that idempotencyKey safeguards retries, but it omits important traits such as failure behavior, prerequisites for connected accounts, side effects, or whether the run is asynchronous. This is adequate but has clear 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 exactly two sentences: the first states purpose, the second provides key usage advice. It is front-loaded, specific, and contains no redundant or vague language.

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 involves a complex nested schedule object and no output schema, so the description should compensate by explaining run lifecycle, how to check status (e.g., via run_status), or required connections. It explains the creation and idempotency but leaves these aspects underspecified, making it only partially 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?

The schema description coverage is 100%, providing detailed semantics for both parameters, including the minimal schedule shape, campaign documents, and TikTok draft settings. The tool description itself adds no additional parameter-level information, so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: 'Create a publishing run from a schedule document.' This specific verb-resource combination distinguishes it from siblings like validate_schedule, preview_campaign, and publish_draft, which serve different functions in the workflow.

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: it is used when you have a schedule document and want to execute it through connected accounts. It also gives practical guidance on using an idempotencyKey to avoid duplicate runs. However, it does not explicitly mention alternatives or exclusions (e.g., use validate_schedule first), so it falls short of a 5.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses the timing constraint ('before it publishes') but does not describe side effects, idempotency, or error cases.

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

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

Single clear sentence, front-loaded with the 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 mutation tool with no annotations and an undocumented parameter, the description is too thin. It lacks information about outcomes, errors, or prerequisites.

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 has one parameter with no description, and schema coverage is 0%. The description does not explicitly define postId, though it's implied. It fails to compensate for the missing schema documentation.

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

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

The description clearly states the tool cancels a scheduled post, using a specific verb and resource. It is distinct from siblings like publish_draft or retry_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 that this applies to scheduled posts before publishing, but does not explicitly mention alternatives 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?

There are no annotations, so the description carries the full burden. It discloses the OAuth authorizeUrl behavior and the required inputs for Telegram and Discord, but does not elaborate on side effects (e.g., whether the connection is immediately active), authentication requirements for the tool itself, or error scenarios.

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

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

Three short sentences, front-loaded with the main action, and no unnecessary detail. Every clause adds information about the connection flow or provider requirements.

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 adequately covers the main flows and provider-specific requirements. The lack of an output schema is partially mitigated by mentioning the authorizeUrl return for OAuth, but it does not explain the return value for Telegram/Discord or describe the overall connection lifecycle.

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 has 100% coverage with descriptions for each parameter. The description adds provider-dependent parameter semantics, noting that botToken/chatId are needed for Telegram and webhookUrl for Discord, which goes beyond the individual property 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 and resource ('Start connecting a new social account') and clarifies the tool's role relative to siblings like list_accounts and account_capabilities. It also mentions provider-specific behaviors (OAuth authorizeUrl, Telegram/Discord parameters), which further distinguishes the tool's purpose.

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 explains when to use the tool (to start connecting a new account) and provides conditional guidance: OAuth providers require a browser authorization step, while Telegram and Discord take specific parameter sets. However, it stops short of explicitly naming alternative tools or stating 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 burden of behavioral disclosure. It implies a read-only operation via 'Get' and clarifies the scope/id relationship, but it does not explicitly state read-only behavior, describe return format, or clarify the meaning of 'snapshot' (e.g., cached vs. live data).

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

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

Two concise sentences with no filler. The main action and required constraints are front-loaded, making the purpose immediately clear.

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 analytics getter, the description plus schema are sufficient. The schema documents the optional 'window' parameter, and the description covers the two required parameters. No output schema exists, but the return value is implicitly analytics data; a bit more detail about the 'snapshot' nature could improve completeness, but it is not critical.

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 description adds meaning beyond the schema by explaining that 'scope' must be one of post/account/run and that 'id' is the matching identifier for that scope. This is valuable given the schema only describes 'window' and leaves 'id' and 'scope' without descriptions (33% schema coverage).

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 ('Get') and the resource ('analytics snapshots'), and specifies three distinct scopes (post, account, run). It differentiates itself from sibling tools like get_post or run_status by focusing on analytics rather than raw resource retrieval.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only outlines required parameters (scope, id) but does not mention any conditions, exclusions, or comparison with sibling tools like workspace_usage or run_status.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the response contents and does not disclose error behavior, authentication needs, or side effects. For a read operation, it is insufficiently transparent.

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

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

The description is a single, front-loaded sentence that immediately conveys the core function. It contains no filler or redundant information, 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?

For a simple get tool, the description conveys the main output but lacks behavioral details and usage context. Given the absence of annotations and output schema, it is minimally viable but incomplete in explaining error cases or prerequisites.

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 description omits the postId parameter entirely, and schema description coverage is 0%. While the parameter name is self-explanatory, the description adds no meaning beyond the schema and fails to compensate for the lack of parameter documentation.

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

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

The description clearly states the verb 'Get', the resource 'one post', and specifies key output details (delivery state, provider identifiers). This distinguishes it from siblings like list_posts and post_attempts.

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 for fetching a single post's details, but it does not explicitly mention when to use this tool versus alternatives like list_posts or provide exclusions. The context is clear enough for a simple get operation, but no direct guidance is given.

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

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

No annotations are provided, so the description must convey behavioral traits. It indicates a read-only listing operation ('List') and that it shows 'connected' accounts, but does not disclose details like rate limits, pagination, or authorization requirements. For a simple read operation, the behavior is mostly transparent, but the description could add more safety info.

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

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

The description is a single sentence that clearly states the purpose and then lists provider options. No wasted words, and the key action is front-loaded. The provider list is long but necessary for usability.

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 list tool, the description is mostly complete: it names the workspace, the resource type, and the filter. It does not mention the return format or pagination, but with no output schema, the implicit expectation is a list of account objects. Could be slightly more explicit but is adequate.

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

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

Schema coverage is 100%, so the schema fully documents the single 'provider' parameter. The description adds value by enumerating accepted provider values (x, facebook, etc.) which are not in the schema as enums. This extra context helps agents select valid filters.

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

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

The description clearly states 'List connected social accounts in the SocialClaw workspace' with a specific verb and resource. It distinguishes from sibling tools like connect_account or list_posts by focusing on 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 implies when to use this tool: when you need to see connected accounts. It also mentions an optional filter, but does not explicitly exclude alternatives or state when not to use it. The context is clear, though no exclusionary guidance is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the ordering ('newest first'), the nature of the returned data ('Each asset includes a publicUrl'), and the scope ('the user has uploaded'). These add meaningful context beyond a simple list call, though it does not discuss error cases 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?

The description is three sentences, each serving a purpose: stating the core function and ordering, noting the publicUrl usefulness, and giving a concrete use case with optional filters. There is no filler or redundancy, making it concise and front-loaded with the most important 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?

Despite having no output schema, the description covers the essential context: what the tool returns (media with publicUrl), how it can be used with other tools, and the available filters. It sufficiently informs the agent about how to invoke it for finding previously uploaded files. It doesn't mention the array format explicitly, but 'List' implies it.

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 each parameter having a clear description. The tool description mentions kind, mime, and query filters, but these repeat what the schema already provides. It does not add significant new semantics beyond the structured parameter definitions, 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 function: 'List media (images/videos) the user has uploaded to their SocialClaw library, newest first.' It identifies a specific verb (list), resource (media assets), and scope (user's library). It also distinguishes from sibling tools by mentioning publicUrl and its use in validate_schedule/apply_schedule, which is unique to asset handling.

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 it: 'Use this to find a previously uploaded file (e.g. from the dashboard) to post.' It also explains how the output integrates with other tools ('usable directly as media_link in validate_schedule/apply_schedule'). No explicit exclusions are given, but the context clearly differentiates it from listing accounts or posts.

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 but only says 'List posts...' with no mention of read-only behavior, pagination, filtering semantics, or any side effects. It adds no behavioral detail beyond the basic action.

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

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

The description is a single sentence with no fluff, which is efficient. However, it is so brief that it lacks structure that could help an agent parse key details, so it is not a 5.

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 7 parameters and no output schema, this description is sparse. It does not mention default limit, paging via offset, filter types, or return format, leaving the agent underinformed about the tool's expected behavior.

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 57% and the description merely says 'optional filters' without naming any. It fails to clarify undocumented parameters like provider, runId, or campaignId, and adds no 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 clearly states the tool lists posts in the workspace, with a specific verb and resource. It distinguishes from siblings like get_post (singular) and list_accounts by resource, but does not explicitly note the difference, so it misses full sibling differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or references to sibling tools like get_post or post_attempts, leaving the agent to infer 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. It discloses the operation type (list) and that results include provider errors, but does not mention pagination, permissions, or whether all attempts or only failed ones are returned. It is sufficient for a simple list tool but not rich in behavioral detail.

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 main action and purpose. No redundant or filler content; every word earns its place.

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

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

The tool is simple (one parameter, no output schema), and the description provides the essential purpose and usage context. It does not explain return format or specific failure behavior, but for a list operation with low complexity, this is adequate and not a significant gap.

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

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

Schema coverage is 0%, but the description's phrase 'for a post' clarifies that postId is the post identifier, adding some meaning beyond the bare schema. However, it does not provide format, constraints, or examples, so it only partially compensates for the lack of 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?

The description clearly states the tool's function with a specific verb ('List') and resource ('publish attempts for a post'), and adds a distinguishing detail ('including provider errors') that separates it from siblings like list_posts and 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?

The second sentence explicitly gives a use case: 'Use this to debug failed posts.' This provides clear context, though it does not explicitly mention alternatives or when not to use, which is a minor gap.

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

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

Given no annotations, the description carries the full burden of behavioral disclosure. It clearly states the non-destructive nature ('without creating anything') and the core behavior ('expands into concrete posts and steps'). While it does not cover auth, rate limits, or error handling, the critical safety trait is explicitly disclosed, which is essential for a preview tool.

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

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

The description is a single, front-loaded sentence that conveys all essential information without redundancy. Every word earns its place, 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?

For a tool with one parameter and no output schema, the description provides adequate context: it explains the purpose, the non-mutating behavior, and the nature of the output (expanded posts and steps). It does not fully detail the return format, but the simplicity of the tool and the rich input schema mitigate this gap.

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

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

The input schema provides 100% coverage of the 'schedule' parameter with a detailed description of minimal shapes and settings. The tool description itself adds no additional parameter semantics beyond what the schema already offers, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Preview') with a clear resource ('campaign schedule document') and outcome ('expands into concrete posts and steps'). It also explicitly states 'without creating anything', distinguishing it from apply_schedule and validate_schedule, making the tool's unique function 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?

The description implies usage when one wants to see the expansion of a campaign schedule before committing to creation, reinforced by 'without creating anything'. It does not name alternative tools, but the context is clear enough to indicate when to use this preview tool. No exclusions are given, but the non-mutating aspect provides strong 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, the description carries full responsibility for behavioral disclosure. It only restates the action and optional start time, without explaining consequences, permissions, or idempotency. This is a significant gap for a mutating tool.

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

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

The description is a single, direct sentence that is concise and front-loaded, with zero redundancy. It could be more informative, but the structure and brevity are appropriate.

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

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

For a simple two-parameter tool, the description covers the core purpose and the start time option. However, it omits contextual details like immediate vs. scheduled publishing and the effect on the draft status, which would matter to an agent with no additional annotations or output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the ISO-8601 format already in the schema but adds no new semantic meaning beyond that.

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

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

The description states a specific action ('Publish') and resource ('previously created draft run'), clearly distinguishing it from siblings like cancel_post or retry_post. It unambiguously identifies the tool's function.

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 when a draft run exists and needs to be published, but provides no explicit guidance on when not to use it or alternatives (e.g., apply_schedule). It lacks clear context for tool 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Retry a failed post,' which adds no information beyond the tool's name. It does not mention side effects, whether it creates a new attempt, required permissions, or failure/retry behavior. This is effectively a tautology.

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

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

The description is a single, front-loaded sentence with no redundant words, earning credit for conciseness. However, it is under-specified to the point of being minimal, lacking essential behavioral context. It is efficient but at the cost of completeness.

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 no annotations, no output schema, and only one parameter, the tool is simple, but the description is too sparse. It does not explain what 'retry' entails (e.g., whether it reschedules, republishes, or creates a new attempt), nor how it relates to sibling tools like post_attempts or publish_draft. The description is not sufficient for reliable invocation in a broader 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 has one parameter, postId, with no description coverage (0%). The tool description does not explain postId's meaning or format beyond the name itself. While postId is self-explanatory, the description adds no value in clarifying the parameter's role or constraints, failing to compensate for the low schema coverage.

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 ('Retry') and resource ('a failed post'), clearly indicating the tool's function. It distinguishes from siblings like cancel_post or publish_draft, though it does not explicitly name alternatives. The purpose is clear and non-tautological.

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

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

No explicit guidance is given on when to use this tool versus alternatives. The phrase 'a failed post' implies it should be used after a post fails, but the description does not provide conditions, prerequisites, or exclusions. With many sibling tools, this lack of guidance leaves the agent to infer usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'status summary' but does not clarify what statuses are possible, whether the operation is read-only, or how errors are handled, which are significant 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 a single sentence with no filler or redundant information. It is appropriately front-loaded with the core purpose.

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

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

The tool has no output schema, so the description should provide more detail on return values and usage context. It only says 'status summary' without specifying status types, data structure, or when to use it, leaving the agent under-informed.

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 0% description coverage for runId, and the description does not explain what runId is, its format, or how to obtain it. The agent is left with an ambiguous string parameter and no guidance, making parameter semantics very weak.

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 'status summary of a publishing run and its posts', which clearly identifies the tool's function. It is distinct from sibling tools like get_post or list_posts, but it doesn't explicitly call out this distinction.

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

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

No guidance is given on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply states what it does, leaving the agent to infer appropriate 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 burden of disclosing behavior. It explains that the server downloads from a public URL or accepts base64, and returns an asset id and public URL. However, it omits important traits like file size limits, supported formats (beyond 'image or video'), and authentication requirements. This provides some transparency but not full.

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 primary action and resource. Every word contributes: target storage, input methods, and return value. 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 low-complexity tool with no output schema, the description covers the essential return values (asset id, public URL) and usage context (media_link). It doesn't mention edge cases like both parameters being provided or error handling, but those are not critical for basic invocation. Minor gaps like size limits are acceptable given the 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 baseline is 3. The description adds value by stating that sourceUrl is a public URL the server downloads and that contentBase64 is an alternative, implying mutual exclusivity and the server-side fetching behavior. This goes beyond the schema's basic property 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?

Description uses a specific verb 'Upload' and names the resource 'media to SocialClaw hosted storage'. It clearly distinguishes from sibling tools like list_assets and get_post by focusing on the write operation. The scope is well-defined: images or videos.

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 conveys when to use the tool (to upload media for use as media_link in schedules) and explains two input methods (sourceUrl or contentBase64). It does not explicitly exclude any scenarios or name alternative tools, but there are no apparent upload-specific siblings, so 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 must disclose behavioral traits itself. It clearly states the tool does not create posts, a key safety property. However, it does not mention what happens on invalid schedules, return format, or any permission/rate-limit requirements, leaving some uncertainty about the tool's exact behavior.

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

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

The description is exactly two sentences, front-loaded with the purpose immediately. It contains zero filler words, every phrase adds value: the validation criteria, the non-mutating guarantee, and the usage order relative to apply_schedule.

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

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

The tool has no output schema and no annotations, so the description must carry more weight. It covers the core purpose and usage, but omits details such as the return value (e.g., validation errors vs. success) and error handling. Given the simple single-parameter interface, the description is adequate but 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?

The input schema provides a detailed description of the 'schedule' parameter, including minimal shape, campaign variants, and per-post settings example. Schema coverage is 100%, so the baseline of 3 applies. The tool description adds no parameter information beyond what the schema already contains.

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

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

The description states a specific verb ('Validate') with a specific resource ('a schedule document') and enumerates the validation criteria (provider rules, media limits, account state, publish times). It explicitly distinguishes itself from apply_schedule by noting it runs 'WITHOUT creating any posts,' making its 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?

The description gives an explicit directive: 'Always run this before apply_schedule.' This clearly specifies when to use the tool versus its primary sibling. The additional phrase 'WITHOUT creating any posts' further clarifies that this is a safe pre-publish check, not an alternative to apply_schedule.

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

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

With no annotations, the description must carry the full burden. It mentions the connection state and the provider filtering behavior, but does not disclose return format, side effects, or error scenarios. It adds some behavioral nuance beyond the name, but not much.

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 concise sentences, front-loaded with the main action and a clear optional parameter usage. Every word earns its place.

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

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

For a simple health-check tool with one optional parameter and no output schema, the description is adequate but incomplete. It tells what it checks (connection state) but does not describe output shape or potential response types, which could be relevant without an output schema.

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

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

Schema coverage is 100% with a descriptive parameter. The description's 'Pass provider to check one provider's connections' essentially restates the schema's 'Optional provider to check connection health for', adding minimal extra meaning. 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 gets workspace health and includes connection state across providers, which is a specific verb+resource. It does not explicitly distinguish from siblings like workspace_usage, but the reference to connection state is specific enough to understand its purpose.

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 usage context by explaining the optional provider parameter, but does not mention when to use this tool versus alternatives. It implies usage for checking health but lacks explicit when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It implies a read operation via 'Get' but does not disclose any behavioral traits such as authentication requirements, rate limits, data granularity, or whether the counts are real-time or cached. The description simply restates the tool's function without adding contextual depth.

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

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

The description is a single, well-structured sentence that conveys the core purpose without any filler. It is appropriately concise for a zero-parameter tool, with every word earning its place.

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

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

While the description states the essential purpose, it does not specify what the counters include (e.g., API calls, storage, active users) or how plan entitlement consumption is reported. Given that there is no output schema and no annotations, a bit more detail would help the agent understand what to expect from the response. Still, for a zero-parameter read-only tool, the description is minimally viable.

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 there is no parameter meaning to add. According to the baseline, a zero-parameter tool receives a 4 because the schema is complete and the description does not need to compensate.

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 identifies the resource ('workspace usage counters and plan entitlement consumption'), which clearly distinguishes it from siblings like workspace_health or get_analytics. The tool's purpose is immediately actionable.

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

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

No guidance is provided about when to use this tool versus alternatives such as workspace_health, get_analytics, or account_capabilities. There are no usage criteria, exclusions, or alternative tool references.

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