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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description adds real value beyond that by disclosing upstream data provenance (NCES, IPEDS), that only public-sector coverage exists, and the proximity caveat. It stops short of describing pagination behavior, what a response contains, or how partial coverage (the strict/include_unresolved axis) manifests in results.

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 core statement is front-loaded and dense: coverage scope plus data source in the first clause. The trailing "Served by Profullstack (https://...)" attribution line is promotional filler that does not help an agent decide or invoke, though it costs little.

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 17-parameter, geocoding-backed search tool with no output schema, the description is thin: it says nothing about the response shape, pagination via next_cursor, or how strict and include_unresolved change returned results. The schema compensates fully for parameter-level documentation, but the multi-path query model (radius vs radius+address geocoding vs keyword) is left for the agent to infer.

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% across all 17 parameters, so every parameter including cursor, strict, include_unresolved and radius_miles is already documented in the schema. The description adds no format, default, or interaction semantics beyond what the schema states, which sets the baseline at 3.

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 the resource precisely (public pre-K-12 school sites from NCES and public colleges/universities from IPEDS) and the geographic scoping mechanism ("within a radius"), which lets an agent distinguish it from the single-record profullstack_education_get sibling. It does not mention that the tool also supports name/district/city/ZIP lookup rather than radius only, so the name-based search mode is not surfaced.

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?

There is no guidance on when to choose this tool, when to use the geographic path (lat/lng vs zip vs city+state vs address), or when to prefer profullstack_education_get. The one advisory sentence, "Proximity is not enrollment eligibility," is a data caveat rather than a usage rule, so an agent gets no explicit selection criteria.

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