Deploy Project to Production

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

The openWorldHint annotation is present, and the description adds meaningful context beyond it by disclosing the real-world consequence: rules are published to a deployment repository for runtime execution, meaning the deployment affects production behavior. This is exactly the kind of side-effect disclosure that helps an agent. It stops short of 5 because it doesn't address whether an existing deployment is overwritten or whether this action is reversible.

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, each earning its place: the core action, the behavioral consequence, and the critical name-vs-ID gotcha with a concrete example. No filler, no repetition of schema-level defaults.

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 production-deployment tool with openWorldHint and no output schema, the description covers the core semantics well but leaves gaps: no mention of what the response contains, no guidance on when to choose openl_redeploy_project over this tool, and no indication of whether deploying over an existing deployment is allowed. The params are well-documented in the schema, which carries some weight here, but the deploy-vs-redeploy decision is an important missing piece.

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 100%, so the baseline of 3 applies — every parameter already carries a rich description, including the exact source of projectId and the name-vs-ID rule for productionRepositoryId. The description's repository-name warning repeats what the schema already documents, adding no net new meaning for parameters.

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 states a specific verb ('Deploy'), resource ('a project'), and target ('production environment'), and adds what the operation actually accomplishes ('Publishes rules to a deployment repository for runtime execution'). It is clearly distinguishable from most siblings, but it does not explicitly differentiate itself from the closely related openl_redeploy_project, so it misses the top score.

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 core usage context is implied clearly: use this when deploying a project to production and publishing its rules for runtime execution. However, no alternatives or exclusions are named — notably there is no 'use openl_redeploy_project for existing deployments' guidance, which an agent would need given that sibling exists. The practical 'use repository name, not ID' advice is helpful but is a parameter-format rule, not a tool-selection rule.

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