College Scorecard

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 transparently explains the return data (key metrics like tuition and admission rate) and the input format, giving the agent a good understanding of expected behavior. It doesn't discuss error handling or side effects, but for a read-only comparison tool, the disclosed behavior is sufficient.

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 concise and front-loaded with a clear purpose, followed by return-value details and parameter guidance. Every sentence adds value, and the structure leads with the primary verb, making it easy to scan and understand.

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 the tool has a single parameter and an output schema (making detailed return listing unnecessary), the description is complete. It explains the purpose, the input source, and the type of output, enabling an agent to select and invoke the tool correctly without extra external knowledge.

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?

Although the schema description coverage is 0%, the description fully compensates by clearly explaining the parameter `school_ids` with its format (comma-separated list), a concrete example, and a pointer to `search_schools` for finding valid IDs. This is excellent parameter documentation.

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 function with a specific verb ('Compare') and a well-defined resource ('multiple colleges or universities side by side'). It also lists the exact metrics returned, making the purpose unambiguous and distinguishing it from sibling tools like search_schools and get_school_detail.

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 for when to use this tool (to compare multiple schools) and provides a prerequisite workflow by instructing the user to 'Use search_schools to find IDs.' It does not explicitly mention alternative tools for single-school comparisons, but the workflow guidance earns it a strong score.

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

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

With no annotations, the description carries the burden. It discloses return values (median earnings and debt) and filtering capability. However, it does not mention behavior with no filters, data limits, or error conditions, leaving some ambiguity.

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 well-structured: a clear purpose statement, a brief explanation of return data, and a compact Args list. Every sentence adds value, and it is front-loaded with the most important information.

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 description covers the core functionality and parameters. Since an output schema exists, return details aren't needed. However, it doesn't state default behavior with no filters or edge cases, making it slightly incomplete for a fully self-contained description.

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 description coverage is 0%, and the description compensates by providing meaningful parameter explanations with examples, such as 'field: Field of study name or keyword to search across schools (e.g. 'Computer Science'...'. It clarifies the purpose of each parameter and their optional combination, though it doesn't fully specify the interaction logic.

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 function with a specific verb ('Get') and resource ('earnings and debt data by field of study'). It distinguishes from sibling tools by focusing on field-level data rather than school comparisons or details.

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 explains that it can be filtered by school, field, or both, giving clear usage context. However, it does not explicitly mention alternative tools or when not to use it, so it scores slightly lower than a perfect 5.

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

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

No annotations are provided, so the description carries the burden. It states 'Returns comprehensive information' which implies a read-only operation, and the verb 'get' reinforces safety. However, it does not explicitly mention side effects, auth, or error behavior, though for a simple get tool these may not be necessary.

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 compact and front-loaded, immediately stating purpose. The Args section is precise with no filler, and each sentence adds value (purpose, return categories, and parameter source).

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 one parameter and an output schema exists, so the description need not detail return structure. It already lists the types of data returned and mentions the prerequisite from search_schools, making it sufficiently complete for an agent to select and invoke it.

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 coverage is 0%, so the description must compensate. It adds meaning by explaining 'The College Scorecard school ID (integer)' and directs users to 'Find IDs via search_schools,' providing both origin and how to obtain the value, which goes beyond the schema's bare type.

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?

Description begins with 'Get detailed data for a specific college or university,' clearly stating the verb and resource. It distinguishes itself from siblings by focusing on a single school's comprehensive data, unlike search_schools (search) or compare_schools (comparison).

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 school IDs from search_schools results,' indicating a prerequisite and a workflow. It does not explicitly mention alternatives or when not to use the tool, but the context is enough to guide an agent.

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

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

With no annotations, the description carries the full burden. It discloses important behaviors: 'distance' is only used with 'zip_code', 'limit' has a default and maximum, and 'degree_type' filtering semantics. It also states what data is returned. However, it does not mention potential edge cases like no results or fuzzy matching, so it falls short of a 5.

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 well-structured with a clear purpose statement followed by an 'Args' list. Every sentence adds value, explaining parameters and returns without unnecessary fluff. The front-loaded main purpose ensures quick understanding.

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 the tool's complexity (6 optional parameters) and lack of annotations, the description is remarkably complete. It covers all parameters, explains return fields, and clarifies conditional logic (distance/zip_code). Even though an output schema exists but is not shown, the description's own output explanation suffices for the agent to call and interpret results.

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 zero description coverage, so the description fully compensates. Each parameter is explained with examples, conditional behavior, and allowed values: 'state' format, 'zip_code' and 'distance' relationship, 'degree_type' mapping, and 'limit' constraints. This adds significant meaning beyond the raw schema.

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 a specific verb ('Search') and a specific resource ('colleges and universities in the College Scorecard database'). It also lists the types of information returned, which distinguishes it from siblings like compare_schools or get_school_detail that serve different functions.

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 implies usage for searching by name, state, zip, distance, and degree type, but does not explicitly mention when to use this tool over siblings. It provides clear context but no exclusions or direct references to alternatives, so the guidance is implied rather than explicit.

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