search_project

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

With no annotations provided, the description carries full burden for behavioral disclosure. It notes that the search covers private entries and optionally public entries, and that it returns solutions, patterns, and decisions. However, it lacks details on side effects (likely none), authentication, or error conditions, making it minimally adequate.

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, with two sentences and a focused trigger list. The trigger list is somewhat lengthy but directly useful for an AI agent to recognize invocation contexts. It is front-loaded with the main purpose and does not waste 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?

Given no output schema, the description should explain what to expect. It says returns 'relevant solutions, patterns, architecture decisions, etc.', but this is vague. It also does not mention result ordering, limits, or the need for project_path in local storage scenarios. It is sufficient for a basic search tool but lacks completeness.

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 coverage is 100%, so parameters already have descriptions. The description adds minimal extra meaning, such as hinting at include_public via 'optionally public entries', but does not compensate for or extend the schema in a meaningful way. Baseline 3 is appropriate.

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 'Search project hive for knowledge' with a specific verb and resource. The trigger phrases further clarify the supported user intents, and the mention of private/public entries distinguishes it from sibling tools like search_kb and search_skills.

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 TRIGGERS section provides concrete example queries that indicate when the tool should be used, such as 'search my hive for [topic]'. This gives clear context for usage, though it does not explicitly mention alternatives or when-not-to-use cases, so it falls short of a 5.

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