get_school_statsGet full admissions statistics for a specific school: GPA/test percentiles, acceptance rate, class size, tuition, employment outcomes. Public — no authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| school_name | No | School name to search for (partial match). Used when slug is unknown. | |
| school_slug | No | School slug (e.g. "harvard-law-school"). Use search_schools to find slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states 'Public — no authentication required,' addressing a key behavioral trait. It also lists the type of data returned, setting expectations. It doesn't mention error handling or output format, but for a simple read-only getter, this is adequate.
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, front-loaded sentence: 'Get full admissions statistics for a specific school: ...' It efficiently conveys the verb, resource, and scope without redundancy or filler.
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?
The tool is simple with two optional parameters, both thoroughly documented in the schema. The description adds the public-access trait and lists the stats returned, compensating for the lack of an output schema. It doesn't explain which parameter to supply, but the schema covers that, making the overall context complete.
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 schema provides 100% description coverage for both parameters, with detailed explanations for school_name and school_slug. The description adds no additional parameter-specific meaning, so a baseline score of 3 is appropriate.
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 clearly states the tool's verb ('Get') and resource ('full admissions statistics for a specific school'), and enumerates concrete data fields (GPA/test percentiles, acceptance rate, class size, tuition, employment outcomes). This distinguishes it from sibling tools like search_schools, calculate_match_score, and compare_to_applicants, which serve different purposes.
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 specifies the tool is for a specific school and notes it is public with no authentication required. It does not explicitly mention alternatives or exclusions, but the sibling list and the phrase 'for a specific school' make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct primary purpose: searching for schools, retrieving detailed stats for a known school, and calculating match probability from applicant data. There is minor overlap because search_schools also returns admissions statistics, but the difference in focus (discovery vs. details vs. personalized analysis) is clear enough.
All tool names follow a consistent verb_noun pattern with snake_case: calculate_match_score, get_school_stats, and search_schools. The verbs are specific and clearly indicate the action each tool performs.
With 3 tools, the server is tightly scoped and each tool covers a necessary part of the admissions workflow: finding schools, getting statistics, and computing match scores. This is within the ideal 3-15 range and does not feel padded or sparse.
The server covers the core read-only admissions use cases: discovery, stats lookup, and personalized match calculation. A comparison feature or direct ranking list tool would be a nice addition, but agents can accomplish common tasks by combining search and stats with match scoring, so there are no critical dead ends.