enable_api_endpoint

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

With no annotations, the description carries the transparency burden. It discloses that the tool mutates a live MCP server's tool surface, requires confirmation, and has a prerequisite. It does not state return values or error specifics, but covers key behavioral traits.

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 sentences, each with a distinct purpose: purpose, prerequisite, and mutation/confirmation warning. Front-loaded with the verb, no wasted 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 one-parameter tool with no output schema, the description covers the essential context: what it activates, prerequisite, mutation warning, and user confirmation. It could mention the relationship to sibling tools, but it is sufficiently 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?

Schema description coverage is 0%, so the description must compensate. It references 'endpoint id' in the confirmation sentence, implying the api_endpoint_id parameter identifies the target endpoint. But it does not explicitly explain the parameter role or format 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 states the action: 'Activate an API-Platform endpoint' and clarifies the effect: 'turns an inactive tool ON in its MCP-exposed collection.' This is specific and distinguishes it from sibling tools like disable_api_endpoint.

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?

Provides clear context with a prerequisite: 'start the backing recipe (flow_id) first, or enable fails.' It implies when to use (when activating an endpoint) and gives a necessary pre-condition. However, it does not explicitly mention when not to use or list alternative tools.

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