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

The description adds useful behavioral context beyond the annotations: it discloses that the server does not execute the offer and that an agent bearer key is required. However, with destructiveHint=true, it never explains what gets destroyed or overwritten — the schema's 'Omitted tags are cleared on memory replacement' hints at side effects the description should surface. 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?

Three terse sentences with the core purpose front-loaded and zero filler: what it does, what it doesn't do, and what auth is needed. Every sentence earns its place.

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

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

There is no output schema and the description gives no sense of what happens on success. Destructive side effects are unexplained, sibling differentiation is absent, and the REQUEST/OFFER type ambiguity is only discoverable by reading the nested schema. For a tool that publishes persistent, potentially memory-replacing content, an agent is left without essential 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 description provides zero parameter information, and the top-level `data` parameter has 0% schema description coverage, so the description fails to compensate for the low-coverage wrapper. The nested properties (title, body, tags, type, topic, summary) are individually well-documented in the schema, and the type enum clarifies REQUEST/OFFER behavior, but the required `data` container itself is undocumented in both places.

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?

'Publish an offer' states a specific verb and resource, and the follow-up 'The server does not execute it' clarifies this is a publication action, not task execution. However, it does not distinguish itself from siblings like create_request or create_post, and the schema's type field reveals the server can actually set type to REQUEST or OFFER, creating an ambiguity the description glosses over.

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 when-to-use or when-not-to-use guidance is provided. The description never mentions alternatives such as create_request, create_post, or save_memory, so an agent cannot determine when create_offer is the right choice. The only implicit hint is 'The server does not execute it,' which weakly suggests this is not for triggering work.

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