server

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

No annotations are provided, so the description must carry full behavioral disclosure. It clearly implies a read-only listing operation and mentions filtering, but does not disclose output details, pagination, potential size limits, or any authentication requirements.

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?

Two concise sentences, front-loaded with the purpose. The second sentence about LLM filtering is somewhat vague and arguably redundant, but the overall length is appropriate and not verbose.

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 1-parameter list tool, it covers the basic purpose but omits explanation of the format parameter, specifics of 'details', and filtering mechanics. Sibling list tools are not mentioned, so context for selection is incomplete.

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?

There is one optional 'format' parameter with a default but schema description coverage is 0%. The description never mentions this parameter or its possible values, so the agent cannot infer how to control the output format, creating a significant gap.

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?

Clear verb 'List' with resource 'available blueprints' and scope 'all', immediately conveying the tool's primary function. It distinguishes from stack creation and validation siblings, but doesn't explicitly differentiate from other list sibling tools like CYCLOID_CATALOG_REPO_LIST or CYCLOID_PIPELINE_LIST.

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?

Implies use when the user needs blueprint listings, and mentions the LLM can filter results based on user requirements. However, it provides no explicit guidance on when to choose this tool over the sibling list tools, and no exclusion conditions.

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

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

With no annotations, the description carries the full burden and fully discloses the interactive elicitation behavior, warning that it will always ask for parameters regardless of provided values. It also specifies what the LLM should never do (provide defaults, guesses, or additional parameters), which is critical for correct use.

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 front-loaded with the purpose but becomes repetitive with multiple CRITICAL warnings and an emoji. It is organized, but some sentences could be tightened without losing meaning.

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?

The description covers the unusual elicitation behavior and calling rules thoroughly, addressing the main risk of guessing parameters. It does not describe return values, but this is not essential for a create operation with no output schema.

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 does not explain the meaning of 'ref,' and the input schema also lacks a description, leaving zero semantic coverage. It mentions parameters (name, use_case, service_catalog_source_canonical) that are not in the schema, adding confusion rather than clarity.

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 opens with 'Create a new Cycloid stack from a blueprint,' clearly identifying the action and resource. It distinguishes this create tool from sibling list tools.

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 provides clear context for when to use the tool and gives explicit instructions about elicitation versus parameter-provided calls. It does not explicitly exclude alternatives, but the create vs list distinction is implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List all available...' without explaining the impact of the 'format' parameter, return structure, pagination, or any side effects. The tool appears read-only, but this is not explicitly stated, and the behavior of the optional parameter is left opaque.

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 concise, just two sentences. The first sentence clearly states the tool's purpose, and the second sentence adds a note about filtering. It is not verbose, though the second sentence is somewhat vague and could be more specific.

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 absence of an output schema and no annotation support, the description should convey what 'details' are returned and how the 'format' parameter affects them. It fails to do so, leaving the agent with incomplete information for a simple but non-trivial listing 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 0%, and the description does not mention the 'format' parameter at all. The statement about filtering does not connect to how the parameter works, leaving the agent with no guidance on parameter syntax, values, or default behavior beyond the schema's type and default.

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 ('List') and the resource ('service catalog repositories') with the added detail 'with their details'. This distinguishes it from sibling list tools like CYCLOID_BLUEPRINT_LIST and CYCLOID_PIPELINE_LIST, making the purpose unambiguous.

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 phrase 'The LLM can filter the results based on user requirements' implies use cases where the user needs to find repositories, but it does not explicitly mention when not to use this tool or provide alternatives. It relies on the tool's name and sibling context for differentiation, so guidance is only implied.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the core read operation and filter options, but does not mention pagination, default behavior, or permission requirements.

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 a single sentence that front-loads the action and resource, lists the key filters, and contains no filler. Every word 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?

With no output schema and no annotations, the description should cover more ground. It provides the essential list-and-filter behavior but skips the 'format' parameter and does not indicate what the response looks like, making it only minimally 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 names four of five parameters (begin, end, severity, type) as optional filters, but omits 'format' and does not explain value formats or allowed values, leaving gaps.

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 uses the verb 'List' with the resource 'organization events' and specifies optional filter parameters, making its function unambiguous. It clearly distinguishes itself from sibling tools which list blueprints, catalog repos, pipelines, etc.

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?

While there is no explicit alternative comparison, the description clearly implies use for listing organization events, and sibling names confirm this is the event-list tool. The context is clear enough without calling out exclusions.

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

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

With no annotations, the description must carry the full behavioral burden. It only states that it lists pipelines, but does not disclose what the output format is, whether results are paginated, or how the 'format' parameter affects behavior. This leaves the agent guessing about the tool's actual behavior.

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 a single short sentence, which is concise and front-loaded with the main action. No unnecessary words are present. However, it lacks supporting details about parameters or output, so it is not as complete as it could be while remaining concise.

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 that there is no output schema, no annotations, and an undocumented parameter, the description is too thin. It does not clarify the return structure or the meaning of the 'format' parameter, making the tool under-specified for an agent that needs to invoke it correctly.

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 input schema defines a 'format' parameter with a default of 'summary', but the description provides zero explanation of it. With 0% schema description coverage, the agent has no idea what values are acceptable or what 'summary' vs. other formats would return. The description does not compensate for this gap.

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 and resource: 'List all pipelines from Cycloid.' This is specific enough to distinguish from sibling tools like CYCLOID_BLUEPRINT_LIST or CYCLOID_CATALOG_REPO_LIST, which target different entity types.

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 guidance is given about when to use this tool versus alternatives. The description does not mention prerequisites, expected use cases, or exclusions such as filtered listing. The agent has to infer the purpose from the name alone.

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

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

With no annotations, the description carries full behavioral disclosure. It mentions the tool uses the Cycloid CLI and provides detailed feedback, but does not disclose whether it is read-only, required auth, or what the feedback format looks like. Some context is added, but it is not comprehensive.

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 short and front-loaded, but the second sentence partially restates the first ('validate' is repeated). It is concise but slightly redundant.

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?

With no output schema and no parameter details, the description leaves important questions unanswered: what is the expected input format, what does the feedback look like, and how are errors surfaced? It is insufficient for an agent to fully understand the tool's behavior.

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% and the description does not explain the 'forms_content' parameter—whether it is a file path, inline YAML content, or the expected format. The description mentions validating a file but does not map the parameter to that file content.

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 explicitly states the tool validates a StackForms (.forms.yml) file using the Cycloid CLI, with a specific verb and resource. This clearly distinguishes it from sibling tools that list blueprints, create stacks, or list events/pipelines.

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 the tool is used when you need to validate StackForms configuration and get feedback for fixing issues. No sibling tool offers validation, so context is clear, though it does not explicitly say when not to use it.

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