Pipepost

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'costs 1 credit,' which is useful context about resource usage. However, it lacks critical behavioral details: it doesn't specify whether this is a read-only or destructive operation (though 'publish' implies mutation), what happens on partial failures (e.g., if some platforms succeed and others fail), authentication requirements, rate limits, or expected response format. For a mutation tool with zero annotation coverage, this is a significant 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 extremely concise—just one sentence—and front-loaded with the core purpose. Every word earns its place: 'Publish to multiple CMS platforms in one call' states the action, and 'costs 1 credit' adds essential behavioral context. There is no wasted verbiage or redundancy.

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

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

Given the complexity (9 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits (e.g., error handling, side effects), output expectations, and usage nuances. While the schema covers parameters well, the description doesn't adequately address the broader context needed for safe and effective tool invocation, especially for a credit-costing mutation tool.

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

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

Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't need to heavily supplement 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 states the tool's purpose: 'Publish to multiple CMS platforms in one call.' It specifies the action (publish) and target (multiple CMS platforms), distinguishing it from single-platform publishing tools like 'publish' or platform-specific tools like 'wordpress_post' (though not explicitly named). However, it doesn't explicitly differentiate from all siblings like 'repurpose' or 'generate_social_posts,' which might have overlapping content distribution functions.

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

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

The description implies usage context by mentioning 'costs 1 credit,' suggesting a resource constraint to consider. It doesn't explicitly state when to use this tool versus alternatives like the single 'publish' tool or platform-specific tools (e.g., 'bluesky_post'), nor does it provide exclusions or prerequisites. The implied guidance is minimal but present.

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