open_project

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

No annotations are provided, so the description carries the full burden. It only mentions a return confirmation, but fails to disclose side effects (e.g., loading/locking the project), error behavior, or required permissions. This is minimal transparency for an operation like 'open'.

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 extremely concise and well-structured with Args and Returns sections. Every sentence provides useful information, and there is no redundancy or filler.

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?

Despite having a simple one-parameter schema, the description lacks essential context: no usage guidance, no state-change implications, and no clarity on how this tool fits with siblings. The output schema covers return values, but the description alone is insufficient for an agent to use it appropriately.

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 schema has no parameter descriptions, but the description adds 'path: Path to the .scriv folder', which clarifies the expected format. This is crucial for correct use, though it does not elaborate on constraints like absolute vs relative paths.

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 'Open a Scrivener project' with a specific verb and resource. It implicitly distinguishes from siblings like find_projects or read_document, but does not explicitly contrast them, 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 description provides no guidance on when to use this tool versus alternatives such as find_projects or scan_project. There is no mention of prerequisites, workflow context, or exclusions, leaving the agent to infer usage.

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