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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real behavioral value beyond them: it clarifies the destruction is scoped to future additions only ('What it already added stays') and warns that the call 'May return needs_confirmation', which maps to the approvalId two-step flow. It stops short of explaining the confirmation 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?

Three short sentences, zero filler, with the effect of the operation front-loaded before the parameter hint and the confirmation caveat. Every sentence carries distinct information.

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

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

For a mutation tool with no output schema and an approval flow, the description covers effect, scope of data retention, prerequisite id, and the possible confirmation response. It could say slightly more about how to proceed after needs_confirmation, but the approvalId parameter fills that 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 all four parameters including workspace and approvalId are already documented in the schema. The description only reinforces the feedId provenance, adding no format or constraint detail beyond what the schema states. Baseline 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?

States a specific verb and resource with precise scope: 'Stops a source from adding new conversations to a dataset.' The follow-up 'What it already added stays' distinguishes it from removal-style siblings like caliper_datasets_remove_item, so an agent can differentiate without opening schemas.

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 supplies a precondition for invoking the tool ('Get the feedId from caliper_source_feeds_list'), which is useful routing context. However, it never states when to stop a feed versus deleting the dataset or removing items, and gives no exclusions, so usage is only implied.

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