Socializioz — AI Social Media Manager

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

Annotations already signal a mutating and idempotent operation, so the description adds value by explaining the scheduling fallback behavior: use schedule_at, otherwise an existing schedule, otherwise ASAP. This is meaningful behavioral detail beyond what annotations say.

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 terse sentences: the first states the action and precondition, the second explains scheduling behavior. There is no filler, no repetition of schema fields, 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?

The description covers the target state, scheduling semantics, and expected behavior well enough for an agent to invoke the tool correctly. Since there is no output schema, a note about return values would improve completeness, but it is not a blocking gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value by defining the fallback behavior for schedule_at, which is not apparent from the schema's basic ISO 8601 description.

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

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

The description uses a specific verb ('Approves'), names the target resource state ('PENDING_APPROVAL post'), and states the key side effect ('schedules it'). This clearly differentiates it from sibling tools like invoke_reject_post, invoke_publish_now, and invoke_schedule_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 PENDING_APPROVAL condition provides clear context for when to use this tool, and the schedule_at guidance explains how to control timing. It does not explicitly name alternatives or when-not scenarios, but the state-based condition is specific enough for an agent to make the right decision.

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

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

Annotations already convey that this is a mutating, non-destructive operation. The description adds meaningful caveats: chat attachments are not auto-injected, file/file_url must not be fabricated, and media should be pre-imported before attaching. This goes beyond the structured annotations without contradicting them.

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, purposeful sentences provide the core action, the preferred workflow, and the important caveat. The most important information is front-loaded and there is no redundant summary 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 100% schema coverage and clear description-level guidance, the tool is fully comprehensible. The description covers the target post state, the input modes, the option hierarchy, and the critical automatic-injection ambiguity an agent might otherwise assume.

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 preferred workflow across parameters: prefer asset_ids for existing media, import external media first, and treat file/file_url as supply-conditional rather than default inputs.

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 leads with a specific verb-object pair: attach media to the authenticated user's DRAFT. It clearly targets the draft post and distinguishes the tool from siblings like detach_assets_from_post and import_media_from_url by framing it as an attachment action.

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 actionable selection guidance: prefer existing asset_ids, import fresh external media first and use the returned Asset ID, and only use file/file_url when the client actually supplies them. It does not explicitly name alternative tools or spell out when not to use it, but the usage context is clear.

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

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

Annotations already declare destructiveHint and idempotentHint, and the description adds useful behavioral nuance: the post and its media are preserved even though the scheduled action is canceled. It does not disclose permission requirements or status transitions, but the annotations lower the burden and there is no contradiction.

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

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

A single sentence with no filler: the action is front-loaded, the resource is specific, and the deletion caveat is an essential qualifier rather than extra verbosity.

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 operation with no output schema and no nested objects, the description plus annotations and schema provide enough to invoke the tool correctly. It could mention state prerequisites or what happens after cancellation, but that is a minor gap 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 adds little parameter-specific detail, but the schema already clearly documents post_id and request_id, including the client correlation id purpose.

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 ('cancels') and resource ('a scheduled post'), and adds a clarifying negative scope ('without deleting it or its media'). This makes the tool's purpose immediately clear and distinguishes it from schedule/reschedule and deletion-related operations.

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 prefer this tool over related siblings such as invoke_reschedule_post, invoke_schedule_post, or invoke_publish_now. It implies use for scheduled posts but does not state conditions, prerequisites, or 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?

Annotations already signal a destructive write, and the description adds meaning beyond that: the result is a DRAFT post, and downstream lifecycle steps are not triggered. It does not fully articulate what happens to the original plan item, but it is not tautological or misleading.

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 succinct sentences carry the key facts: the transformation and the fact that downstream steps stay separate. No filler or repetition.

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

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

For a simple 2-parameter, no-nested-object mutation, the description is mostly complete: it states the state change and boundary. Most missing context is already covered by the annotations and the 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%, so parameters are already well described. The tool description does not materially add to the parameter meaning, particularly around the optional `social_account_id` and what happens if it is omitted.

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 and resource: it 'converts' a 'campaign plan item' into a 'DRAFT post'. It clearly distinguishes itself from publish/schedule/approval by explicitly stating those remain separate.

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 provides a clear boundary: approval, scheduling, and publishing are not part of this operation. It does not explicitly name a sibling to choose instead, but it clearly communicates when not to expect the other downstream steps.

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

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

The description states only that a campaign is created in a workspace, which is a high-level effect but adds little beyond the tool name and annotations. It does not disclose side effects, return value, prerequisite conditions, or non-idempotency, and the available annotations (readOnlyHint false, destructiveHint false) do little to fill that gap.

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

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

The description is short and front-loaded with the action, with no filler language. However, it is under-specified for a 10-parameter creation tool; brevity here crosses into thinness rather than optimal conciseness.

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 10 parameters, no output schema, and a mutating behavior, the description is far too sparse. It does not explain what happens after creation, what the created resource actually contains, or what minimum inputs beyond name are needed in realistic multi-workspace environments.

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 parameters with clear descriptions, so the tool description does not need to repeat them. However, the description adds no extra semantic value or clarifying relationships between parameters, e.g., how workspace_id or primary_social_accounts interact.

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 ('Creates') and names a clear resource and scope: a campaign in a workspace. It does not explicitly differentiate itself from siblings like invoke_create_campaign_plan_item or invoke_update_campaign, but the core 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?

There is no guidance on when to use this tool versus alternatives such as invoke_create_campaign_plan_item or invoke_update_campaign. The only contextual hint about workspace_id being required when multiple workspaces exist is buried in the schema, not in the description.

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

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

The description aligns with annotations: readOnlyHint=false and destructiveHint=false, consistent with a non-destructive create. It does not go beyond that to mention duplicate behavior, return value, or whether plan items are created in a pending/draft state, so the added behavioral context is limited.

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 clear, front-loaded sentence with no filler or redundant restatement of the tool name. It immediately conveys the core operation and target resource.

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 simple create operation, the schema covers all five parameters in depth, and annotations are explicit, the description is largely sufficient for selecting and invoking the tool. The main minor gaps are no guidance about the return value and no explicit statement about duplication or required state, but these are small in the absence of 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 description coverage is 100%, so the schema already explains all parameters clearly. The description paraphrases 'content idea' and 'brief', which loosely aligns with the title and description parameters, but it adds no new meaning beyond what the input schema provides.

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

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

The description names a specific action ('Adds') and an exact resource ('a content idea or brief to a campaign plan'). It distinguishes the tool from sibling create/update operations such as create_campaign, update_campaign_plan_item, and convert_plan_item_to_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?

No explicit usage context is provided. The description does not explain when to choose this tool over update_campaign_plan_item, list_campaign_plan_items, or convert_plan_item_to_post, nor does it mention prerequisites such as an existing campaign.

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

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

Annotations already establish this is a write operation. The description adds behavioral context: it is scoped to one connected account, it does not publish content, and passing client_request_id prevents duplicate drafts. No contradiction with the annotations is present.

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

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

The description is compact and front-loaded: one sentence defines the operation and scope, and one follows up with prerequisites and idempotency. There is no wasted phrasing.

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 10 parameters and a nested youtube_settings object, the description plus 100% schema coverage is adequate. It does not describe output shape or explicitly route to follow-up tools like update_draft_post or publish_now, but the agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a useful combined-content requirement ('plus text or assets'), but most parameter meaning is already carried by the schema, including client_request_id's idempotency 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?

States a specific verb and object ('Creates a DRAFT') and the resource scope ('one connected account'). The word 'DRAFT' clearly distinguishes this from publishing, scheduling, or approving 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?

It gives clear context: the call creates only a draft for one connected account, and requires a social_account_id plus text or assets. It also mentions the client_request_id deduplication mechanism, though it doesn't explicitly name sibling tools such as update_draft_post or schedule_post.

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

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

Annotations already state destructiveHint=true and readOnlyHint=false, so the description carries less burden. It nonetheless adds useful context by clarifying the destructive scope: only selected attachments are removed; the underlying Asset records are kept. This prevents an agent from assuming the assets themselves are deleted.

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-formed sentence with two clauses, both of which carry essential information: the operation ('Removes selected attachments') and its key behavioral caveat ('Asset records stay in the library'). It is front-loaded and contains zero filler.

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

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

For an operation with only two primitive parameters, no output schema, and a clear high-level effect, the description plus annotations fully cover the necessary behavior. The library-preservation caveat fills the main possible misunderstanding around destructiveness. No additional return format or failure details are required at this complexity level.

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

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

Schema description coverage is 100%, and both post_id and asset_ids are documented in the schema with straightforward descriptions. The tool description adds no new parameter-level meaning, but because the schema fully covers both params, a baseline 3 is warranted.

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 explicitly says 'Removes selected attachments', giving a specific action and resource, and immediately clarifies that the Asset records remain in the library—distinguishing this detach operation from an asset deletion or from adding assets. This makes its purpose unambiguous even among sibling tools like invoke_attach_assets_to_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 description implies the usage context: use this when you need to remove assets from a post while preserving them in the library. However, it never explicitly contrasts this with the attach/reorder siblings or states when not to use it. No exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the scope of 'full details for one workspace asset' and is consistent with annotations, but it does not disclose behavior around invalid asset IDs, permissions, or the exact response 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?

A single, front-loaded sentence with no filler. Every element—returns, full details, one, workspace asset—carries meaning and directly supports an agent's understanding.

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

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

For a simple one-parameter read-only getter with strong annotations and a complete parameter schema, this description is sufficient. 'Full details' signals the return value appropriately even without an output schema, and there are no hidden side effects or alternative paths to clarify.

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%: asset_id is described as 'Workspace Asset ID.' The description itself adds no parameter-level information beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description 'Returns full details for one workspace asset' states a specific verb ('Returns'), a resource ('workspace asset'), and a scoping specificity ('one'). It is clearly distinguished from siblings such as invoke_list_workspace_assets (list vs. single) and invoke_get_post (asset vs. 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 description conveys clear usage context: call this when you need the full details of a specific workspace asset rather than a list. It does not explicitly name alternatives such as invoke_list_workspace_assets, but the single-vs-many framing makes the intended use clear.

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

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

Annotations already fully cover the behavior that matters most: readOnlyHint=true, idempotentHint=true, and destructiveHint=false make it clear this is a safe read operation. The description adds a small additional behavior by listing 'core-profile completeness', suggesting the result includes a completeness assessment beyond just raw attributes. It does not contradict annotations, but it does not deeply disclose edge-case behaviors such as what happens when no brand profile exists.

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

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

The description is a single focused sentence, efficiently listing the profile components without elaborate background or irrelevant detail. It is front-loaded with the core content ('Brand identity, audience, voice, goals...') and is appropriately sized for a simple read tool. The only reason not to award 5 is that rewording into an explicit verb-based sentence would make its purpose even clearer.

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

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

With only two optional parameters, no output schema, and strong annotations, the description covers the essential domain of the call. It is missing some contextual information that would make it fully self-sufficient, such as what the response looks like, whether a brand profile can be absent, and how workspace_id behaves when multiple workspaces exist despite not being schema-required. For a simple read-only retrieval tool, this is adequate but still has 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 description coverage is 100%, so the description is not required to explain the parameters in depth. The 'workspace' scope in the prose aligns with workspace_id, and request_id is adequately described in the schema as an echo/tracing field. The description adds minimal meaning beyond the schema, which is acceptable given the high 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 identifies the tool as returning the brand profile for a workspace, enumerating the exact content areas: identity, audience, voice, goals, guidelines, and completeness. It is distinguishable from sibling tools like invoke_get_user_profile and invoke_get_workspace_context because it is specifically scoped to brand data. However, it omits a verb such as 'retrieves' or 'returns', so the action is inferred from the tool name, not the description.

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

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

The phrase 'for one workspace' implies the tool is for retrieving brand-level data for a specific workspace, which contextually distinguishes it from user-level or asset-level getters. It does not explicitly state when to use it versus invoke_get_workspace_context or invoke_get_user_profile, nor does it mention any exclusions. The guidance is mostly implicit, so it earns a mid-range score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description's 'only when needed' phrase adds some context but not a new behavioral trait beyond what annotations already communicate. This is adequate and consistent.

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

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

Two sentences, no filler, with the core behavior and the required argument shown upfront. Every sentence contributes meaning and the format is easy to parse.

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

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

For a one-parameter, read-only help tool with complete annotations and a single input, the description supplies all required context: what it returns, when to use it, and the exact parameter format. No other information is needed for correct invocation.

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

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

Although the schema already describes the topic parameter at 100% coverage, the description enriches it by enumerating valid topic values (workspace, brand, connections, x, posts, etc.) and clarifying that an exact tool name is also acceptable. This goes beyond a bare schema definition.

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

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

The description names a specific verb ('Returns') and resource ('deeper Socializioz MCP rules'), and differentiates this tool from all sibling tools by being the only help/rules access point. It also lists the accepted topics, so 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 states when to invoke it ('only when needed') and specifies the input form ('a topic ... or a tool name'), giving actionable guidance. However, it doesn't explicitly name the alternatives or explain what counts as 'needed,' so the guidance is good but not 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?

Annotations already cover readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description aligns with those and adds only a slightly richer notion of returning 'current action flags,' but it does not disclose any other behavioral traits like authentication needs, possible errors, or post not-found behavior. It adds some context beyond annotations but not substantial 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?

One concise, front-loaded sentence that exactly identifies the operation and scope. No filler or redundant phrases. The information 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 read-only getter with one required parameter and fully described schema and annotations, the description is largely sufficient. The only missing contextual piece is an explicit link to the sibling list_posts operation for broader post retrieval scenarios, but that falls more under usage guidance than completeness.

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

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

Schema description coverage is 100%, and each parameter (post_id, request_id) already has a clear description. The tool description does not add supplementary meaning to the parameters, but the baseline schemas and schema descriptions carry the burden effectively.

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 the exact verb/resource: 'Returns full details and current action flags for one post.' This is specific and clearly distinguishes it from listing or mutating posts. However, it does not explicitly name or route around the sibling list_posts tool, so it lacks the explicit sibling differentiation that would earn a 5.

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

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

The description implies 'use this when you need details for a specific post,' but it does not give explicit guidance on when to use this tool instead of alternatives like list_posts or other post-related operations. No when-not-to-use conditions or alternative tool references are 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral context beyond the annotations by enumerating the returned aspects: user, selected workspace, plan, brand/account summaries, and capabilities, and by flagging the workspace_id requirement in multi-workspace OAuth setups.

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 compact sentences, front-loading the core purpose and return coverage, then adding the relevant parameter condition. There is no fluff or redundant restatement of the tool name.

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

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

The description is sufficient for a low-complexity read-only tool: it states the context, return-like content, and the workspace parameter caveat. It does not explain the response structure, but since there is no output schema and the annotations already imply read-only/idempotent behavior, the coverage 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 describes both parameters thoroughly (100% coverage), and the description mostly restates the workspace_id condition with only the addition of 'native OAuth'. The description does not meaningfully expand on request_id or add substantial param meaning beyond the schema.

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

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

The description clearly identifies the resource (user profile) and the scope of what it returns: user, selected workspace, plan, brand/account summaries, and capabilities. This differentiates it from siblings like get_workspace_context and get_brand_profile, though it does state the intended purpose less directly as 'session orientation' rather than an explicit verb.

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

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

The description gives a specific usage condition for the workspace_id parameter (pass it when native OAuth has multiple workspaces), but does not explicitly say when this tool should be chosen over similar alternatives such as get_workspace_context or get_brand_profile. Usage guidance is mostly implied, not differentiated.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the safety profile is clear. The description adds some context by listing what data it returns, but it does not disclose things like role/permission requirements, error behavior, or what happens if workspace_id is omitted when multiple workspaces exist.

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, no filler, and the core resource/content is placed first. The key operational hint about workspace_id is mentioned in the second sentence without overshadowing the tool's 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?

For a simple read-only getter, the description adequately covers the returned concept areas and the one important parameter condition. It lacks explicit behavior for omitted workspace_id and does not describe the response shape, but those are minor gaps given the tool's simplicity and the absence of 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 description coverage is 100%, so the parameters are already documented: request_id is an optional correlation id and workspace_id is required when multiple workspaces exist. The description repeats the workspace_id guidance without adding deeper semantics about format, defaults, or 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 clearly identifies 'get workspace context' as a read of workspace-level data: role, readiness, plan, counts, and capabilities. It distinguishes itself from sibling getters like get_post and get_user_profile, though it does not explicitly name a sibling to separate it from.

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 only usage guidance is 'Pass workspace_id when more than one workspace exists,' which is a useful prerequisite. However, it does not describe when to prefer this tool over related siblings like invoke_list_user_workspaces or invoke_get_brand_profile, so the broader selection context is only implied.

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

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

The description adds valuable behavioral detail beyond the annotations: it discloses downloading, validation, storage upload via Core.UploadFile, Asset creation, and the returned Asset ID. This is more transparent than simply stating 'imports media.' It does not discuss failure behavior or idempotency, but annotations already signal that the operation is not idempotent, softening that gap.

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

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

A single, information-dense sentence that front-loads the core purpose and separately lists the side effects and return value. There is no filler or redundant restating of the tool name.

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

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

For a tool with one required parameter, high schema coverage, and a clear side-effect chain, the description covers what matters: input type, behavior, destination, and return value. The absence of an output schema is compensated by stating the returned Asset ID. No critical context is missing.

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

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

Schema description coverage is 100%, so the schema already documents url, filename, and workspace_id adequately. The description adds a small amount of semantic context (e.g., public HTTPS for url and importing into a workspace), but it doesn't significantly go beyond the structured schema information. Baseline 3 is appropriate.

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

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

The description names a specific verb ('Imports'), a specific resource (public HTTPS image/video), and the complete pipeline (download, validate, upload, create Asset, return ID). This clearly distinguishes it from asset retrieval or listing tools like invoke_get_asset and invoke_list_workspace_assets.

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 conveys when to use the tool: when a public HTTPS image/video needs to be brought into Socializioz as an Asset. It also adds a meaningful constraint (public HTTPS URL). It does not explicitly name alternatives or exclusion cases, so it falls slightly short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description only notes pagination, which adds minimal behavior not already evident from annotations, but does not burden the agent with hidden 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?

One clean sentence with no filler. The verb, resource, and pagination feature are front-loaded, making the description quick to parse and exactly as long as needed for a simple list operation.

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 straightforward read-only list operation with full parameter schema coverage and safe annotations, this is largely complete. It does not describe the response structure or next_offset semantics in the description, but the schema covers the necessary fields and no output schema exists.

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?

Since schema description coverage is 100%, all three parameters (campaign_id, limit, offset) already have clear meanings. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Lists') and resource ('campaign content-plan items'), which clearly distinguishes it from sibling tools like list_campaigns and list_posts. It also mentions pagination, making the purpose concrete.

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 the tool—when you need to list campaign plan items—but it does not explicitly state alternatives or exclusions. It lacks guidance such as 'use this instead of list_posts' or any conditions, leaving some routing decisions to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral facts of filtering by status and pagination, but does not describe response shape, default return breadth, or other non-obvious behavior.

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

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

A single sentence that conveys the operation, the resource, and the key options. No filler or redundant content; 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?

The tool is simple, all parameters are optional, and the annotations plus schema cover most concerns. The main small gap is the absence of any description of the response format or pagination behavior, such as how next_offset is returned, but this is not critical for a straightforward list.

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 descriptions for limit, offset, and status. The description mostly rephrases what the schema already provides, adding no deeper meaning about parameter formats, allowed values, or interactions between status and pagination.

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

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

The description states a clear verb and resource ('Lists campaigns') and adds optional status/pagination behavior. It does not explicitly distinguish itself from sibling list tools like invoke_list_campaign_plan_items, but the noun 'campaigns' is specific enough to avoid major ambiguity.

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 optional status filter and pagination imply the main use case, but there is no explicit statement about when to prefer this tool over other list tools or when not to use it. The context is only implied by the tool's purpose rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the substantial security transparency is handled. The description adds useful context about returned account properties (capabilities), but it does not disclose output format, pagination, or the exact meaning of identity/health flags. It also introduces 'capability flags' without linking them to the input or output schema, which creates slight confusion. No contradiction with annotations.

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

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

The description is short, with no verbose filler. The first sentence is informative and the second gives a practical use-reminder. However, the second sentence is slightly ambiguous and could mislead an agent into expecting a capability-flags input parameter, which is not present in the schema.

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

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

For a simple, read-only listing tool with only two well-documented parameters and a rich annotation block, the description is nearly sufficient. It outlines what data the tool exposes and gives a target-selection workflow hint. It is missing an explicit return-value shape or note on how 'capability flags' map to other tools, but for this complexity level, the description is adequately 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 fully explains both parameters (request_id as an echoed tracing field, workspace_id as conditionally required). With 100% schema coverage, the description does not need to explain them, but it also adds no method hint. The phrase 'capability flags' does not correspond to any schema parameter, so the description does not assist with parameter 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 identifies the resource as connected accounts and conveys a listing operation, especially through the title 'List Connected Accounts'. It distinguishes itself from sibling list tools (e.g., list_posts, list_workspace_assets) by enumerating account capabilities: identity, health, and publish/inbox/comment/insight.

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

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

The description gives a practical use hint ('Use capability flags to choose targets'), implying this tool is a starting point for selecting accounts. However, it does not explicitly state when to prefer this tool over sibling list tools, nor does it give any exclude guidance. The intended usage is therefore more implied than explicitly scoped.

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?

In addition to the annotations (readOnly, idempotent, non-destructive), the description adds the 'visible' scope and a specific pagination contract: layering on next_offset until has_more is false. These are useful behavioral details beyond the annotations, even though sorting and return format are not described.

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 carry all essential information: purpose first, then the pagination rule. There is no fluff, redundancy, or verbose preamble.

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?

Combined with the rich schema, the description gives enough context for an agent to list posts and paginate correctly. 'Visible' is not fully defined and the return shape is not explicit, but for a read-only list tool with no output schema, these are moderate gaps covered by the pagination note and 'posts' wording.

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 all seven parameters with descriptions, including defaults and allowed values, so schema coverage is 100%. The tool description does not need to add parameter-level semantics; it also mentions next_offset/has_more, but those are response fields, not input 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 identifies the action ('lists') and the resource ('visible posts') and mentions filters and pagination. It is distinct from sibling list tools by focusing on posts, though it does not explicitly compare itself with invoke_get_post or other list 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 provides pagination instructions but does not state when to use this tool versus alternatives like invoke_get_post or invoke_list_campaigns. There are no exclusions, alternative conditions, or explicit context selection cues beyond the generic phrase 'Lists visible 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?

Annotations already cover readiness and safety: readOnlyHint, idempotentHint, and non-destructive false. The description adds 'available to the authenticated user', which gives useful scoping context, but it does not describe the response shape, pagination, or what happens when no workspaces are available.

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 clear sentence with no filler or redundancy. It presents the core function in a directly usable way.

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 read-only list operation with annotations declaring safety, the description is nearly complete. It states a simple, realistic outcome, though it does not mention any output details, which are minor for this simple 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 takes no parameters, so there are no parameter semantics to explain. The empty schema is fully covered, and the description has no obligation to define nonexistent arguments.

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 ('Lists') and a specific resource ('workspaces'), and clarifies the scope to the authenticated user. It clearly reads as a list-operation and is distinct from sibling list tools by naming the workspace resource explicitly.

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

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

No guidance is provided about when to choose this tool over alternatives such as invoke_get_workspace_context or invoke_list_workspace_assets. The description states what the tool does but gives no comparison, exclusion, or situational advice.

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

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

Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds pagination and filtering behavior, which is useful, but it does not disclose details like default page size or how to use next_offset beyond what the schema already states.

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 with zero fluff. It leads with the main action and resource, then layers on the two use qualifiers without wasting 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 read-only list operation with strongly worded annotations and full schema coverage, this is mostly complete. The only gap is that with no output schema, the description does not explicitly state the response shape beyond implying a paginated list.

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 input schema already documents all four parameters. The description adds a high-level summary of pagination and type filtering but does not add new parameter-level meaning beyond the schema.

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

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

The description states a specific verb ('Lists'), a specific resource ('workspace assets'), and key capabilities ('pagination', 'optional type filter'). This clearly distinguishes it from sibling tools such as get_asset and attach_assets_to_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 description implies the tool is used when you need to enumerate workspace assets and optionally filter by type, but it does not explicitly state when to prefer it over alternatives or exclude cases such as retrieving a single asset. No alternative sibling route 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?

Annotations already provide readOnlyHint, idempotentHint, and non-destructive guarantees, so the description's extra behavioral context of returning 'valid or the required fix' adds clarity beyond the annotations. It communicates that this is a check-only operation with an actionable result. It does not mention rate limits or auth requirements, but for a read-only preflight tool with annotations covering safety, this 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 two short sentences with zero filler. It front-loads the validation scope and immediately states the output outcome. Every sentence adds direct value.

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

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

For a simple, read-only, one-required-parameter tool, the description captures purpose, timing, output, and effect. The schema handles all parameter documentation, and annotations handle safety behavior, so nothing needed by an agent to invoke the tool correctly is missing.

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

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

Schema coverage is 100%, so every parameter already has a clear description. The tool description adds no new meaning for individual parameters beyond mapping the concept of 'platform/content type' to those optional fields. The baseline of 3 is appropriate because the schema handles parameter semantics well.

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

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

The description names a specific verb ('Checks'), the resource being validated ('a post's media'), and the criteria ('against its platform/content type'). It also distinguishes itself from sibling action tools by stating it is a preflight validation before schedule, publish, or retry rather than being one of those actions.

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 identifies when to use the tool: 'before schedule, publish, or retry'. This gives clear contextual guidance without naming a sibling alternative, which is acceptable because no other sibling appears to offer a preflight validation pass. It stops short of a 5 because it does not state exclusions or explicitly name alternative tools.

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

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

Annotations already declare mutating, destructive, idempotent, and open-world behavior, so the description does not need to restate those. It adds valuable state-gating context: pending review requires explicit override, and failed posts are deliberately out of scope. It could go further by stating the effect on the existing schedule once published, but that is partially implied by 'publish now' and covered by the destructive hint.

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 with no filler. The main action and allowable states are front-loaded, and the exception/routing guidance is packed efficiently into the second sentence without any redundant restating of schema fields.

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 has only 2 parameters and no output schema, the description covers the required contexts: draft/scheduled usage, approval override intent, and failed-post exclusion via the retry sibling. It does not describe the response format, but no output schema means that is 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 already 100%, so post_id and override_approval are individually documented. The description adds an extra layer by connecting override_approval to the pending-review workflow and explicitly telling users that FAILED post IDs should not be used with this tool, which meaningfully guides correct parameter selection.

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?

It is specific about verb and resource: it 'Publishes a DRAFT or SCHEDULED post now' and clearly distinguishes the target states. This also separates it from sibling tools such as schedule_post and retry_failed_publication without needing to open those definitions.

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

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

The description says exactly when to use the tool: for draft or scheduled posts, with explicit note that pending-review posts need override_approval=true. It also explicitly routes FAILED posts to retry_failed_publication instead, which is strong alternative guidance.

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

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

Annotations already signal readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds useful nuance by explicitly stating the lifecycle transition and emphasizing that content is not deleted, which helps reconcile the destructiveHint. It does not fully explore irreversibility or side effects, but it adds value beyond the structured annotations.

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

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

A single sentence conveys the core action, the applicable state, the resulting state, and the key non-destructive guarantee. The information is front-loaded and there is no 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 two-parameter state-transition tool with annotations covering read-only and idempotency behavior, the description is sufficient. It answers what, when, and what happens, while the input schema covers the parameter details. No critical call-affecting information is missing.

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

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

Schema description coverage is 100%: post_id and reason are already well documented in the input schema. The description's 'PENDING_APPROVAL post' provides context about the affected resource, but it does not add new parameter-level semantics beyond what the schema already states.

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

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

States a specific action (rejects), a specific resource state (PENDING_APPROVAL post), and a clear outcome (moves lifecycle to CANCELLED). The clarification 'without deleting content' further distinguishes it from destructive actions and nearby workflow 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 clearly identifies the intended context: only PENDING_APPROVAL posts should be rejected, and the result is a lifecycle move to CANCELLED. It does not explicitly name alternatives or exclusions, but the precondition is concrete enough for an agent to decide when this tool applies.

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

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

Annotations already mark this as destructive and idempotent. The description adds the key behavioral constraint that callers must supply the same IDs, meaning omitted IDs are not allowed or would break the operation. This is useful beyond the raw annotations and there is no contradiction.

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

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

A single front-loaded sentence captures the action and the critical constraint. Every word earns its place, and there is no redundant filler.

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

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

For a two-parameter tool with full schema coverage and safety annotations, the description is complete. The required post_id and the list of all current asset IDs are both covered, and the agent can invoke the tool correctly without further 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 documents both parameters fully, including that asset_ids must be 'all currently attached Asset IDs in the desired order.' The description mostly restates the asset_ids semantics, adding little beyond the schema.

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

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

The description uses a specific verb ('reorders') and a clear resource ('existing post assets'), and distinguishes itself from the sibling attach/detach tools by emphasizing that the ID list contains the same IDs in a new order, not a modified set.

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: use this when you want to reorder already attached assets. It implies the contrast with attach/detach tools, though it does not explicitly name them or state 'when not to use'.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the precondition that the post must be SCHEDULED, which is useful, but it does not disclose what happens to the prior scheduled time or any state transitions beyond the basic 'changes' verb.

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

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

A single, efficient sentence that places the core action first and the key constraint ('SCHEDULED post') right after. No filler, repeated information, or unnecessary 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 3-parameter tool with a fully self-describing schema, the description covers the essential distinction from siblings. It doesn't explain return values, but no output schema exists and the tool's outcome is implicit in the action 'changes the future publish time'.

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 parameters are already well-documented in the schema. The description adds no new parameter meaning beyond what the input schema already states about post_id, timezone, and schedule_at.

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 action (changes), the target (the future publish time), and the scope (a SCHEDULED post). It distinguishes itself from siblings like invoke_schedule_post or invoke_publish_now by focusing on rescheduling an already-scheduled 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 phrase 'of a SCHEDULED post' gives clear context that this tool applies only to posts already in the scheduled state. It does not explicitly name alternatives or exclusions, but the precondition is unambiguous enough for an agent to route correctly.

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

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

The annotations already convey destructive, idempotent, and non-read-only behavior. The description adds the precondition that only failed posts and post-media-validation scenarios apply, but it does not explain side effects like status changes or duplicate risk.

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

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

One short, front-loaded sentence with no fluff. The action, subject, status requirement, and precondition are all present in a compact form.

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 mostly sufficient. It could clarify the observable result of a successful retry, but the core workflow is fairly 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 describes post_id as 'Socializioz post ID' with 100% coverage, so the description adds no additional parameter meaning. This is the baseline case where the schema already 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 states a specific verb ('Retries'), a target ('FAILED post'), and a condition ('after media validation'). It is distinct from scheduling, publishing, and preflight siblings, though it does not explicitly mention the publication outcome it retries.

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 'FAILED post after media validation' implies when this tool should be used and sets a prerequisite. It does not define explicit alternatives or exclusions versus sibling tools such as invoke_publish_now or invoke_schedule_post.

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

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

The description adds a meaningful behavioral detail: scheduling a pending-review post requires approval unless explicitly overridden. It does not explain the destructiveHint=true behavior, such as whether scheduling overwrites an existing schedule, which would have been valuable context beyond the annotations.

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

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

The description is compact and front-loaded with the core action. The second sentence delivers a genuinely important approval condition, with no filler or redundant wording.

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 plus schema covers the main scheduling workflow, but leaves the destructive behavior and missing output schema unaddressed, so the agent cannot infer what the return value or side effects will be when scheduling is invoked. Some sibling differentiation around rescheduling would also improve completeness.

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

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

Schema description coverage is 100%, and the schema already documents post_id, timezone, schedule_at, and override_approval. The description only restates the override_approval condition without adding meaningful new parameter semantics.

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

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

The description states a clear action ('Schedules a post') and adds the approval flow, which gives it more specificity than a bare restatement of the title. It does not explicitly distinguish itself from reschedule_post, but the approval caveat makes its role reasonably clear.

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

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

The description provides workflow guidance: pending-review posts require approve_post or explicit override_approval=true. However, it does not clarify when to use this tool instead of publish_now, reschedule_post, or cancel_scheduled_post, leaving tool selection partly to inference.

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

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

The description goes beyond the annotations by specifying the exact behavior: moving from DRAFT to PENDING_APPROVAL and creating an approval request. Annotations already cover idempotency and destructiveness; the description supplements them usefully with the target state. It does not elaborate on side effects of the destructive hint, but the core behavior is 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, compact sentence that front-loads the purpose and includes the most decision-relevant information: the state change and the creation of an approval request. No word is wasted.

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

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

For a two-parameter tool with a clear state transition, the description is largely complete. The only minor gap is that it doesn't describe what outcomes the caller can expect beyond the transition and doesn't mention any preconditions for the draft, though these are partly inferable from the schema and annotations.

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 documents all parameters with 100% coverage, describing post_id as 'Socializioz post ID' and request_id as an optional correlation id. The description does not add further parameter semantics, which is acceptable given the schema's completeness.

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 ('Moves') plus a precise resource and state transition: 'Moves a DRAFT to PENDING_APPROVAL and creates a human approval request.' This clearly separates it from siblings like invoke_approve_post, invoke_reject_post, or invoke_publish_now.

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

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

Usage is implied through the state transition: the tool is for taking a draft and sending it through an approval request. However, the description does not explicitly state when to use this tool versus alternatives such as invoke_approve_post or invoke_publish_now, and doesn't provide exclusions or requirements.

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

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

Beyond the annotations, the description adds the important behavior that only the supplied fields are changed. This clarifies that unspecified fields are left as-is and that the call is not a full replacement or upsert. Annotations already indicate this is a non-read, destructive operation, and the description does not contradict them.

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

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

One sentence with no filler. It front-loads the operation, the object, and the partial-update semantics. Every word adds value.

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 small, non-nested update tool with fully documented parameters and annotations indicating destructive behavior and idempotency, the description covers the essential operational context. It could mention the return value, but in the absence of an output schema this is a minor gap.

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

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

The input schema documents all five parameters with 100% coverage, so the schema already explains the fields. The description adds meaning by indicating that whatever fields are supplied apply as updates and that others are not affected, which clarifies the role of optional parameters and the required id.

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 ('Updates') and names the resource ('campaign fields') and clearly scopes it to a partial update ('only the supplied campaign fields'). This differentiates it from create-campaign and campaign-plan-item tools, though it does not explicitly name alternatives.

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 when-to-use guidance and does not mention alternatives or exclusions. An agent has to infer from the sibling names which update tool to choose, and for an operation with multiple 'update_*' siblings this is a notable 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?

The description adds a meaningful behavioral detail beyond what annotations provide: it explicitly states that only the supplied fields are updated, implying omitted fields remain unchanged. This valuable PATCH-like behavior is not fully expressed by the readOnly hint or destructive hint and helps reduce risk during invocation.

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

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

The description is a single front-loaded sentence with no filler: 'Updates only the supplied plan-item fields.' The phrasing is compact and immediately readable while still conveying the core operation and its partial-update scope.

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?

This is a simple update operation with a 4-field schema, 100% schema coverage, and annotations for safety and idempotency. The only notable gap is missing guidance about how this tool relates to sibling operations like update_campaign or create_campaign_plan_item, but the description plus schema gives enough information to plausibly select and call it in most contexts.

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?

Since the schema covers 100% of parameters, the description's role is smaller. However, 'only the supplied fields' clarifies that optional parameters are truly optional and that omitting them leaves their existing value unchanged, highlighting a semantic nuance that would otherwise be guessed.

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 'Updates' and resource 'campaign plan', then adds an important scoping qualifier: 'only the supplied fields.' This conveys partial update semantics and differentiates the tool from create/list plan-item operations, even though it does not explicitly name the alternative tool.

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

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

There is no guidance on when to use this tool versus alternatives such as invoke_create_campaign_plan_item or invoke_update_campaign. The reader must infer the appropriate selection solely from the tool name and sibling list, providing no confidence about when this is the right choice.

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

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

The description adds a meaningful behavioral restriction beyond what the annotations alone provide: only drafts are editable, and attempts on other states will fail. The destructiveHint and idempotentHint annotations already convey the mutation profile, and the schema's 'Replacement' wording covers replacing fields. No contradiction exists between the description and annotations.

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

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

Two short sentences say everything necessary: what the tool does and which states are excluded. There is no filler, redundancy, or irrelevant context, and the most important state restriction is placed prominently.

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?

Together with the complete schema descriptions and rich annotations, the description is enough for correct invocation: it identifies the target state, the operation, and the impossibility of other states. The only minor gap is that it does not mention what the response or return value is, but with no output schema this is not a required part of successful invocation.

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

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

Schema description coverage is 100%, so the input schema already documents all eight parameters, their purposes, and their roles. The description itself does not add parameter-level detail, which is acceptable because the schema carries that burden. Baseline 3 is appropriate here.

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 and resource: 'Updates a DRAFT post,' which immediately distinguishes this tool from scheduling, approving, or publishing tools. The explicit constraint 'Other states are not editable here' further clarifies the exact scope of the operation, leaving no ambiguity about what the tool does.

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

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

The description gives a clear when-to-use condition: only for draft posts. It also gives an explicit when-not-to-use boundary: other states are not editable here. While it does not name a specific alternative tool, the state restriction is unambiguous and enough for an agent to decide whether to invoke this 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?

The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail by stating that every call re-verifies workspace/account/token binding and refreshes tokens when needed, which is not fully covered by the annotation hints. No contradiction exists between the description and annotations.

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

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

The description is two sentences, but each sentence is substantive. The first sentence concisely scopes the operations by category, and the second adds behavioral detail about auth verification and token refresh. No redundant or filler content is present.

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

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

The description provides enough context for a multi-action gateway, especially given the rich schema and annotations. It covers the important auth behavior and the breadth of operations; the lack of a detailed output description is mitigated because the schema's pagination_token field already explains how to handle response cursors.

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

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

Schema description coverage is 100%, so every parameter is already well-documented in the input schema. The description does not add additional parameter-level meaning, which keeps the score at the baseline expected for a fully documented 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 identifies a specific resource and operation class: a verified X read/search gateway, listing the covered content types such as posts, recent search, full-archive search, mentions, users, followers/following, and DM events. It is clear and detailed, though it does not explicitly distinguish itself from sibling tools like invoke_get_post and invoke_list_posts, which may be relevant to the same read actions.

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 the appropriate context: use this tool for authenticated X read/search operations, and it calls out that it verifies workspace/account/token bindings on every call. However, it gives no explicit guidance about when to prefer this gateway over sibling tools or when not to use it, so the usage context is mostly implied.

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