search-priya-profile

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The description references DCR (Dynamic Context Retrieval) but doesn't explain what that means behaviorally—rate limits, whether it performs external lookups, latency, or whether it mutates any state. It appears to be a read-only retrieval tool, but nothing states that or describes what gets returned beyond 'relevant profile sections.'

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 focused sentence that establishes the purpose and usage trigger, followed by a short list of covered content areas. It is front-loaded and efficient with no wasted words. Could arguably combine more seamlessly, but it's appropriately concise for a tool of this simplicity.

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 retrieval tool with 2 parameters fully documented in the schema, the description covers the essential scope. However, it does not specify return shape or behavior (given no output schema), and the mention of DCR without explanation leaves some ambiguity about expected behavior. Adequate but not rich; a mention of what 'relevant profile sections' maps to (i.e., the list of siblings like get-skills, get-projects) would improve it.

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 schema already documents both parameters ('query' as the user's question, 'limit' as max relevant sections). The description adds the semantic detail that queries relate to Priya Gautam's background, which maps to the query parameter. However, this is minimal value-add since the schema and tool title already convey this. Baseline 3 is appropriate given full schema coverage.

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 a specific verb ('Search') plus a specific resource ('Priya Gautam's professional profile') and enumerates the covered topics (education, skills, experience, projects, technologies). It clearly distinguishes itself from generic search tools by being person-specific. However, it doesn't explicitly differentiate from the sibling 'search-profile' beyond the Priya-specific scope, which is evident from the name itself.

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 gives explicit when-to-use guidance ('Use this tool whenever the user asks about Priya Gautam's education, skills, experience, projects, technologies, certifications, achievements, or professional background'). It clearly scopes the tool to Priya-specific queries, which implicitly distinguishes it from the generic 'search-profile' sibling. However, it doesn't state when NOT to use it (e.g., it does not mention what other tools handle non-Priya queries), leaving some ambiguity.

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