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: it specifies the exact return breakdown (tuition, living, flights, health insurance, visa fee, total) and explains the scholarship_mode behavior ('show the self-funding gap when tuition is already covered by a scholarship'). Minor gaps remain — currency, data vintage, and estimation assumptions are not disclosed — but the core behavior is transparent.

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 front-loaded with its core purpose, then proceeds logically through scope, output format, and special mode. The destination enumeration is long but earns its place by giving the agent concrete valid values. Every sentence contributes; nothing is wasted.

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 there is no output schema and no annotations, the description carries substantial burden — and it largely delivers: return format, destination scope, target audience, and the scholarship_mode toggle are all explained. The remaining gaps (currency of the cost figures, underlying assumptions or data vintage) are minor for a cost-estimation tool but would help an agent set user expectations.

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 baseline is 3. The description adds modest value beyond the schema: it frames scholarship_mode as revealing the 'self-funding gap' and categorizes destinations into tiers, which complements the schema's flat ID list. It adds nothing for lifestyle or degree_level, which the schema already documents adequately.

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: 'Estimate and compare the total annual cost of studying in one or more countries for an African postgraduate student.' It names the audience, the scope (32 destinations across three tiers), and the output (annual cost breakdown). This clearly distinguishes it from sibling tools focused on visas, GPA conversion, and scholarships.

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 purpose strongly implies when to use the tool (cost estimation/comparison questions), and the siblings are functionally distinct enough that confusion is unlikely. However, the description never explicitly states when not to use it or points to alternatives — notably, scholarship_mode overlaps conceptually with the scholarship-related siblings (get_scholarship, match_scholarships, search_scholarships), and that boundary is never addressed.

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