create_project

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

No annotations are provided, so the description alone must communicate behavioral context. It only discloses creation and locality; it does not explain side effects, behavior on duplicate project IDs, persistence guarantees, or permissions. The project_id constraint adds minor guidance but is not enough for a mutating tool.

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 two short sentences with no filler, and it front-loads the core action before the naming constraint. Every sentence earns its place, and the structure is easy to scan.

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?

Although the output schema exists, the tool has no annotations and 0% parameter schema coverage, which raises the burden on the description. Missing context includes overwrite/conflict behavior, whether creation can fail, and required inputs beyond a terse project_id hint.

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 for all three parameters. It adds one useful constraint for project_id (lowercase, non-sensitive) but leaves name and description entirely unexplained, including their purpose or format.

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 verb ('Create') and resource ('a new local project'), and the word 'local' distinguishes it from any remote or cloud project concept. Among siblings like get_project and draft_estimate, its role is immediately apparent.

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 should be used when creating a new project, and contrasts implicitly with get_project for retrievals. However, it never explicitly states when not to use it or mentions alternatives, leaving some inference to the agent.

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