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. It does well by stating that the tool uses StudiePoint's matching algorithm and scoring criteria (GPA fit, field alignment, visa accessibility, deadline urgency, acceptance rate) and explicitly describes the output (match score, reasoning, direct application links). It does not mention side effects, errors, or rate limits, but for a non-destructive recommendation tool this is sufficient transparency.

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 efficient and front-loaded: the first sentence states the core purpose, the second explains the algorithm, and the third covers the output. Every sentence earns its place, with zero fluff or repetition of schema details. This is a model of concise, structured writing.

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 tool with 5 parameters, no annotations, and no output schema, the description is remarkably complete. It states the target user, the input basis, the scoring logic, and the exact return content (match score, reasoning, application links). The schema covers parameter specifics like defaults and enum values, so nothing an agent needs to call the tool correctly is missing.

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 input schema already describes all 5 parameters with 100% coverage, so the baseline is 3. The tool description adds some connective meaning by tying parameters to algorithm criteria (e.g., 'GPA fit' and 'field alignment' map to converted_gpa and field), but it does not provide new per-parameter details beyond what the schema gives. It also says nothing about the limit parameter, leaving the schema to do the heavy lifting.

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 opens with a specific verb and resource: 'Get personalised, ranked scholarship recommendations for an African student based on their full profile.' It clearly defines the tool's purpose and differentiates it from siblings like search_scholarships (which implies plain search) and get_scholarship (which implies retrieval of a single scholarship). The mention of StudiePoint's matching algorithm and output structure further pins down what makes this tool distinct.

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 clear context — use this tool when you need personalised, ranked recommendations for an African student, not just a search or single-scholarship lookup. It implies the right scenario through phrases like 'personalised,' 'ranked,' and 'based on their full profile.' However, it does not explicitly name alternative tools or state when not to use this tool, which keeps it slightly below the explicit standard.

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