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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's real addition is the cost disclosure ("Free"), which is useful and not in annotations, but it says nothing about failure behavior for an unknown method, rate limits, or whether the generic dispatcher returns network-shaped data.

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

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

The content is front-loaded and dense with useful examples, but the ending abruptly repeats "Free. Free." — a duplicated fragment that wastes space and reads as a copy error, slightly undermining the otherwise tight single-sentence structure.

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 generic dispatcher with no output schema, the description correctly delegates method detail to social_channel_rules and supplies examples, which is the right shape. But it leaves the `data` argument's per-method contract unaddressed in both places, so an agent must infer required payload keys for, e.g., Pinterest boards lookups.

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 only 33%, so the description has to carry weight. It does explain `method` meaningfully by enumerating real values per network, well beyond the bare regex pattern. However, the nested `data` object (up to 10 arbitrary properties) is left entirely unexplained in both schema and description, which is a genuine gap for the one parameter whose contents vary per method.

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?

Names a specific verb+resource ("run one of a channel's lookups") and distinguishes itself from siblings by pointing at social_channel_rules as the method catalog and social_channels as the channel_id source. The per-network examples ("channels" on Discord/Slack, "boards" on Pinterest, "publications" on Medium) make the effect concrete, though it never says what a lookup actually returns.

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?

Establishes the prerequisite discovery path explicitly: methods come from social_channel_rules and channel_id comes from social_channels (reinforced by the schema). It gives no when-not-to-use guidance and does not contrast this against social_channels or social_networks, so an agent could still confuse the two discovery tools.

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