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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds one genuinely useful behavioral fact, the 50-result cap, which warns about potential truncation. It does not disclose matching semantics (partial vs. exact prefix), result ordering, or what an empty result set looks like.

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?

Two tight sentences with no filler, and the core purpose is front-loaded before the result-count note. Nothing is redundant, though the second sentence is the only piece of operational detail present.

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?

This is a simple one-parameter search tool with full annotation coverage and no output schema, so the bar is modest. The description covers purpose, matched fields, and the result cap, which is nearly enough; minor gaps around matching behavior and empty results remain.

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 carries the burden. It does clarify that the single parameter accepts a university name or short name, which is real added meaning beyond the bare string type. However, it omits the minLength of 2 and says nothing about whether matching is substring, prefix, or case-insensitive.

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 names a specific verb (search) and resource (universities) and states the fields matched, name or short name. It is clear what the tool does, but it never mentions the sibling tools kampus_list or kampus_get, so the agent must infer when a query-driven lookup beats a listing or a single-record fetch.

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?

Usage is only implied: the agent can deduce this is the right tool when it has a name fragment. There is no explicit when-not guidance, no pointer to kampus_get for exact retrieval or kampus_list for enumeration, and no mention of the two-character minimum query constraint.

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