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

No annotations are provided, so the description carries the full burden. It discloses the data source (purdu.edu/registrar via WordPress REST API, live) and the scope (calendar + registrar pages). However, it does not mention read-only behavior, rate limits, or what happens when the query is omitted (though that is covered in the schema). The description adds some behavioral context beyond the schema but is not exhaustive.

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?

Two sentences, no wasted words. The first sentence defines the tool's purpose and scope, the second provides the source. Every sentence is necessary and informative.

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 2 parameters, no output schema, and no annotations, the description provides enough context: what the tool does, what it covers, and the source. It is complete for a simple query tool. It could briefly mention that the return format is a list of calendar events or registrar pages, but the examples in the schema partially compensate.

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 100% with both parameters described in the input schema. The description does not add significant parameter-specific meaning beyond what the schema already provides. The baseline of 3 is appropriate because the schema handles parameter semantics 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 clearly states the tool retrieves the official academic calendar (specific events: first day, breaks, finals, commencement) and also searches any registrar page by keyword. It distinguishes itself from sibling tools like search_events or search_courses by explicitly naming the resource (registrar/academic calendar) and the verb 'retrieve' is implied.

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 when to use the tool: for academic calendar dates or registrar-specific info by keyword. It does not explicitly mention when not to use it or list alternative tools, but the scope is clear enough that an agent can infer it's for registrar-related queries, not for general Purdue events or other topics.

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 full burden. It discloses the data fields returned and source, which is helpful. However, it does not mention that the tool likely returns past, present, and future games (with scores for completed ones) or any limitations (e.g., only future schedule for in-progress sports). The description is adequate but not fully transparent about behavior.

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 extremely concise: two sentences that front-load the purpose and detail. Every word adds value, and no extraneous information is present.

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 limited complexity (2 params, no output schema), the description is sufficient. It explains what data the tool returns, the data source, and the parameters are well-documented in the schema. It lacks mention of return format (e.g., list of games) but is otherwise 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?

Schema description coverage is 100% with both parameters described. The description adds context about what the returned data contains (e.g., final scores for played games) which is beyond the parameter descriptions. It could clarify that 'upcoming_only' hides games that have already been played, but the schema already says that. Baseline 3 plus extra context justifies 4.

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 retrieves a full season schedule for one Purdue team, listing specific data fields (dates, opponents, home/away, venue, final scores) and identifies the source. The verb 'schedule' and resource 'one Purdue team' are specific and differentiate it from sibling tools that handle other topics.

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 the tool should be used to get a team's schedule, but does not explicitly state when to use this vs. siblings like athletics_sports (which lists teams) or athletics_upcoming (which likely shows only upcoming events). No guidance on when not to use it or alternatives is provided.

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 full burden. While it states the data source (purduesports.com API), it does not disclose behavioral traits such as whether the tool requires authentication, has rate limits, how frequently data is refreshed, or what happens if the API is unavailable. The description is too minimal for a tool with no annotations.

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 two short sentences, one focused on output and the other on source. It is efficient with no redundancy. However, it could benefit from a slightly clearer structure or explicit mention of output format. It earns a 4 for being front-loaded and concise.

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 no parameters, no output schema, and no annotations, the description is minimally adequate. It communicates the core output (list of sports and schedule IDs) and data source. However, it lacks completeness in describing the output format or potential edge cases (e.g., empty list, API errors). For a simple tool, this is acceptable but not comprehensive.

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 tool has zero parameters, and schema description coverage is 100% (empty schema). The description adds value by specifying that the tool returns a list of sports and schedule IDs, which goes beyond the empty schema. Since there are no params, the description's purpose is to explain what the tool does without parameter details, scoring above the baseline 4.

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 lists all Purdue varsity sports along with their current schedule IDs. The verb 'list' and resource 'Purdue varsity sports' are specific, and the source attribution adds credibility. It does not explicitly differentiate from siblings like 'athletics_schedule' or 'athletics_upcoming', but the noun 'sports' distinguishes it as a listing of sports themselves, not schedules or upcoming events.

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 implicitly suggests using this tool when you need a list of varsity sports or their schedule IDs, likely as a prerequisite to fetching schedules. However, it provides no explicit guidance on when to use it versus siblings like 'athletics_schedule', nor does it mention when not to use it or any prerequisites. The mention of 'current' implies use for up-to-date data, but this is not explicit.

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 full burden. It discloses the source and sorting order but does not mention rate limits, data freshness, whether results are cached, or if live updates occur. Without annotations, more behavioral detail would be helpful.

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 two sentences, front-loading the purpose and adding a source note. It is efficient and clear, but the source note could be integrated into the first sentence to reduce slight redundancy.

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 no output schema and moderate tool complexity (3 optional params), the description provides enough context for an agent to select and invoke the tool for its intended purpose. It lacks return format details, but the list nature of the tool makes this somewhat acceptable.

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 100%, so baseline is 3. The description adds value by explaining the purpose of the tool (upcoming games, sorted soonest) and implicitly ties parameters to filtering. However, it does not elaborate on each parameter's specific behavior beyond what the schema already provides. The description earns a 4 for contextual framing rather than parameter-specific details.

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 lists upcoming Purdue athletics games across all sports, sorted by soonest first, and specifies the data source (purduesports.com API). This distinguishes it from siblings like athletics_sports or athletics_schedule.

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 it's for finding games to watch this week, but does not explicitly compare with siblings (e.g., athletics_schedule for a specific sport) or provide when-not-to-use guidance. Usage context is implied by the content, but no alternative tools are mentioned.

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 provided, the description carries full burden for behavioral disclosure. It reveals data source (Purdue Banner self-service), ordering (newest first), and a specific behavioral detail about 'View only' terms being closed for registration. A minor gap is not stating that this is a read-only operation, though it is strongly implied by 'list' and the context.

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?

Two sentences, perfectly efficient. First sentence states purpose and ordering, second adds behavioral context. No superfluous words.

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 zero-parameter list tool with no output schema, the description is fully adequate. It tells the agent everything needed: what is returned (terms in registration system), order, source, and a meaningful behavioral property (view-only status). No gaps given the tool's simplicity.

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 has zero parameters and 100% description coverage, so schema handles everything. The description adds value by explaining the nature of the data (registration terms, source, ordering, view-only detail) that schema cannot express.

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 lists banner registration terms from Purdue's live system, including ordering (newest first) and a key behavioral detail (view-only terms). This effectively differentiates it from sibling tools like list_terms which may use a different source or ordering.

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 when to use it (when Purdue Banner registration terms are needed) but doesn't explicitly compare to the sibling list_terms tool. It provides good context about data source and behavior but lacks when-not-to-use or alternative guidance.

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?

Since no annotations are provided, the description carries the full burden. It explicitly notes that the data are timetable times and that CityBus does not provide a public real-time feed, so buses may run early or late. This is a critical behavioral disclosure that goes beyond the schema.

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 two sentences long and immediately states the purpose and key constraint. Every sentence adds value with no wasted words. It is front-loaded and highly scannable.

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 is relatively simple (3 fields, no output schema, no nested objects), the description covers the essential behavior (timetable only, source). It does not describe the return format, but that is acceptable since no output schema exists and the data is straightforward. A small gap is that it doesn't explain how the limit parameter affects output beyond 'default 10' from the schema.

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 provides descriptions for all three parameters (100% coverage). The tool description adds no further elaboration on the parameters. The baseline for full schema coverage is 3, and the description meets that without adding extra parameter insight.

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 provides 'Next scheduled CityBus departures from a stop today, by route and headsign.' It specifies that these are timetable-based times and not real-time, which is a key distinction. The source is also mentioned. This clearly differentiates from sibling tools like bus_stops or bus_routes.

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 implicitly tells the agent when to use this tool (to get departure times) and highlights a limitation (no real-time data). It does not explicitly discuss when not to use it or mention alternatives among siblings, but the constraint is clear enough for an agent to decide.

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?

The description discloses the data source (CityBus GTFS feed), that it reflects scheduled service, and that no public real-time feed is available. This is valuable behavioral context beyond the schema. However, it does not mention other traits like caching behavior or response size bounds; a score of 4 reflects strong but not exhaustive 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?

Two short sentences convey purpose and a key limitation. Every word earns its place, with no redundancy or filler. Excellent conciseness.

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 simple list tool with one optional parameter, the description is fully adequate: it states the scope (all routes), the data source, and a limitation (no real-time feed). No output schema exists, but the return value is straightforward. No gaps remain for an agent to operate correctly.

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% with the 'query' parameter described as 'Filter by route number or name.' The tool description adds no further semantics or examples. Per guidelines, high schema coverage sets a baseline of 3, and no additional meaning is provided here.

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?

Title 'List CityBus routes' and description 'Every CityBus route serving Purdue and Greater Lafayette' use a specific verb ('list') and resource ('routes'), clearly distinguishing it from sibling tools like bus_stops and bus_next_departures.

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 does not explicitly state when to use this tool versus alternatives (e.g., bus_stops for stop info, bus_next_departures for departures). While the sibling list provides context, the description itself offers no usage guidance, exclusions, or preferred scenarios.

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 must carry full behavioral disclosure. It omits key details: whether query and lat/lon can be combined, what happens when both are provided, pagination behavior, and the absence of any mutability warnings. The description is too sparse for a tool with no annotations.

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?

Two sentences with no wasted words. The purpose and source are front-loaded, and the structure is optimal for quick scanning.

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 has 4 optional parameters, no output schema, and no annotations. The description fails to clarify return format, parameter interaction (e.g., can both query and lat/lon be used together?), or the meaning of 'nearest' (radius, ordering). While adequate for a simple tool, gaps remain that could confuse an agent.

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 100%, so baseline is 3. The description adds minimal value beyond parameter descriptions, only mapping 'by name' to query and 'nearest a lat/lon' to lat/lon. It does not clarify mutual exclusivity or default behavior, so it does not exceed the baseline.

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 two modes: searching by name or finding nearest stops by lat/lon. It specifies the source (CityBus GTFS) and implicitly distinguishes from sibling tools like bus_next_departures and bus_routes by focusing on stop location lookup.

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 use cases (search by name or find nearest stops) but does not explicitly contrast with sibling tools or provide when-to-use/when-not-to-use guidance. For a tool with 30+ siblings, more explicit direction would help selection.

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 of behavioral disclosure. It adds useful context by citing the live NOAA/NWS api.weather.gov source, but it does not discuss data freshness, latency, rate limits, or response format. This is moderate transparency for a simple weather tool.

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 two sentences, front-loaded with the core purpose, and the source is a single clear addendum. Every word earns its place with no redundancy.

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 simple, no-required-parameter tool, the description covers the scope (Purdue West Lafayette) and the content (current conditions, forecast, alerts). It could be slightly more explicit about what 'current conditions' includes, but given the lack of output schema and low complexity, the description is largely 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?

Schema description coverage is 100%: both 'hourly' and 'periods' are defined in the schema. The description itself adds no extra parameter details, but that is acceptable given the schema already documents them well.

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 that the tool provides current conditions, forecast, and severe-weather alerts for the Purdue West Lafayette campus. It is specific about the resource and scope, and it naturally distinguishes itself from the unrelated sibling tools.

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?

No explicit when-to-use or when-not-to-use guidance is given, and no alternative weather tools exist among siblings. However, the use case is implied by the description itself: if you need current conditions, forecast, or severe alerts for the Purdue campus, this is the tool to use.

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 states the source (Purdue Banner self-service, public, live) and the type of data returned. While it lacks explicit mention of read-only status or side effects, the context strongly implies it is a safe read operation. A slightly higher score would require explicit behavioral notes.

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 two sentences with zero waste. The first sentence front-loads what the tool returns, the second provides usage guidance and source. Every word earns its place.

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?

Despite having no output schema, the description enumerates return fields (seats, waitlist, CRNs, meeting times, instructors) and clarifies it operates per section. Combined with the schema's parameter descriptions, it provides a complete picture for an agent to use the tool correctly.

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 baseline is 3. The description does not add parameter-level context beyond what the schema already provides. It focuses on output rather than input parameters, which is acceptable given the schema is complete.

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 returns live seat and waitlist counts for course sections, with details like CRNs and instructors. It explicitly distinguishes from sibling tools 'search_courses' and 'course_sections', making the purpose specific and unambiguous.

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 directly advises using this tool over alternatives when the question is 'can I get in', providing explicit context for when to use and when not. It also labels the data as authoritative registration data, further clarifying its appropriate use case.

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 must carry the full burden. It only lists the data returned and cites a data source ('Purdue.io'), but does not disclose any behavioral traits such as whether the operation is read-only, expected performance, rate limits, or authentication requirements. The agent is left to assume it is safe without explicit confirmation.

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 sentence that front-loads the key data items (CRNs, section types, etc.) and includes the source. Every word earns its place, and there is no redundancy. Perfectly concise for a simple query tool.

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 absence of an output schema and the moderate complexity (3 parameters, 2 required), the description lists the returned fields but does not specify the structure, ordering, or error handling. It is adequate for a basic understanding but lacks completeness for fully autonomous use without further instructions.

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 no additional meaning beyond the schema's parameter descriptions; it merely restates the tool's scope. It does not clarify formats, defaults, or relationships between parameters beyond what is already in the 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 the tool returns 'CRNs, section types, meeting days/times, rooms, and instructors for a course in a given term', which is a specific verb+resource combination. However, it does not differentiate from sibling tools like 'section_details' or 'search_courses', so it misses the opportunity to guide selection.

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 provides no guidance on when to use this tool over alternatives. It does not mention when not to use it, such as for a single section lookup (where section_details might be better) or for course search (where search_courses is appropriate). No context or exclusions are given.

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 of disclosing behavior. It adds useful context: the tool sources live data from the Purdue HFS dining API and answers the 'who is serving' question. However, it does not disclose return format, no-match behavior, or whether retail locations are included by default (though the schema hints at include_retail).

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 one concise sentence with a clear main clause, a defining example, and a source attribution. Every element serves a purpose and there is no unnecessary repetition 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?

For a simple search tool with no output schema, the description adequately conveys the tool's function, cross-court scope, date sensitivity, and live data source. It does not describe the response structure or edge cases, but the core selection and invocation context is clear.

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 provides 100% coverage with meaningful descriptions for all four parameters, including examples and defaults. The description only repeats the query idea ('chicken tenders') and date concept ('on a given date'), adding no additional semantic value beyond what the schema already offers. Baseline 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 uses a specific verb ('Search') and clearly defines the resource ('every Purdue dining court's menu') and scope ('for a dish on a given date'). The example 'who is serving chicken tenders today' makes the tool's purpose unmistakable and differentiates it from siblings like dining_menu (which likely shows a single court's menu).

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 a clear use case: finding which dining court serves a specific dish on a given date. It implies cross-court lookup rather than per-court menu browsing, which helps disambiguate from dining_menu. However, it does not explicitly state when not to use the tool or name alternative tools.

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 full burden. It identifies the tool as a read operation ('returns... panel', live API source) but does not explicitly state non-destructive behavior, error handling, or response limitations. For a simple read tool, this is adequate but could be more explicit.

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 plus a brief source note. Every part is necessary and no word is wasted. It is optimally concise.

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 simplicity (one parameter, no output schema), the description adequately covers the input source and purpose. It could mention the expected output format (e.g., JSON object with nutrient fields), but the term 'full nutrition panel' provides sufficient guidance for an AI agent.

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 100% and the parameter description already explains 'Item GUID from dining_menu / dining_find_item'. The tool description repeats this information without adding new semantics, meeting the baseline for high coverage.

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 returns a 'full nutrition panel for one menu item', using an item ID from sibling tools. It distinguishes from dining_menu and dining_find_item which retrieve item lists rather than nutrition data. The verb 'returns' is implied but the purpose is unambiguous.

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 tells the agent to obtain the item ID from dining_menu or dining_find_item before using this tool, providing clear context. However, it does not include explicit when-not-to-use guidance or mention alternatives, though no competing nutrition tools exist among siblings.

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 full burden. It discloses the source (live API, crowdsourced) and implies the data is real-time and may be 'empty' at off-peak times. While this adds transparency, it does not state behaviors like freshness interval, what happens if no reports exist, or any rate limits. It is adequate but not comprehensive for a zeroparam tool.

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 two sentences, front-loads the core purpose, and includes only relevant additional context (off-peak emptiness, source). Every sentence earns its place with no wasted words. Excellent conciseness.

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 no parameters, no output schema, and no annotations, the description provides sufficient context for a simple live data retrieval: what it returns, its source, and a usage hint. It lacks explicit mention of data format or expected output structure, but for a zero-param, read-only style tool, this is mostly 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 tool has zero parameters and schema coverage is 100% (empty properties). The description adds value by explaining what data the tool returns (line-length reports for dining courts) and its nature (crowdsourced, live). For a parameterless tool, this is above baseline; the description meaningfully sets expectations.

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 provides 'real-time line-length reports for Purdue dining courts' and identifies the data source (Purdue HFS dining API). The verb 'Crowdsourced real-time line-length reports' effectively communicates the purpose and distinguishes it from sibling tools like dining_menu or dining_locations, though it could be more explicit about it being a live retrieval, not historical analysis.

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 notes 'Often empty outside peak hours', giving implicit guidance on when the tool returns value vs. less relevant data. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools for dining or campus info. Usage context is hinted but not fully clarified.

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?

Without annotations, the description carries the full burden. It states the source is a live API and that the output includes open status and next meal period, which is moderately transparent. However, it does not disclose potential error conditions, rate limits, or output format details, leaving gaps for an agent.

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?

Two sentences, no wasted words. The first sentence immediately states the tool's purpose and scope, and the second adds the source and output details. Highly efficient and front-loaded.

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 no output schema, the description reasonably covers return values (open now, next meal period) and source. It could clarify the output structure (e.g., list of objects with fields) or mention that location names are included, but for a simple list tool it is mostly 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?

Schema coverage is 100%, so baseline is 3. The description adds value by enumerating the enum values (dining courts, Quick Bites, On-the-GO!) and linking the open_now parameter to 'whether it is open right now', reinforcing the schema descriptions and providing richer context.

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 verb 'List', specifies the resource 'Purdue dining locations', and enumerates the categories (dining courts, quick bites, On-the-GO!). This distinctly sets it apart from sibling tools like dining_menu or dining_line_length by focusing on location listing rather than menus or wait times.

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 provides no guidance on when to use this tool versus alternatives. It does not mention related tools like dining_menu for menus or dining_line_length for wait times, nor does it state conditions like 'use when you need a list of all locations' versus 'use dining_menu for a specific location's menu'.

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 must carry the full burden. It mentions a live API source, but does not disclose behavioral traits like rate limits, authentication, pagination, error handling, or output format. The phrase 'by meal period and station' is ambiguous—station is not a parameter in the schema, which could mislead an agent about available filters.

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 sentence with no wasted words. However, the inclusion of 'station' is ambiguous and slightly detracts from clarity. Still, it is appropriately concise for a simple tool.

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 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, how dietary filters interact, or what happens if no menu is available for a given date/meal. The mention of 'station' without a corresponding parameter creates confusion. An agent would likely need to infer behavior from arbitrary examples.

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 67% (4 of 6 parameters documented). The description reinforces the purpose of 'date', 'meal', and dietary tags, but does not add meaning for the undocumented 'vegan_only' and 'vegetarian_only' parameters. It also mentions 'station' which is not a parameter, reducing clarity. The description fails to compensate for gaps in the 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 the tool returns a 'Full menu for one Purdue dining location on a date, by meal period and station, with dietary tags.' This distinguishes it from siblings like dining_locations (lists locations), dining_find_item (search specific item), dining_item_nutrition (nutrition info), and dining_line_length (wait times). The verb 'Get' in the title is aligned.

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?

No explicit guidance on when to use this tool vs. alternatives. The description implies use when you want a full menu with dietary filters, but does not contrast with dining_find_item (for searching across locations) or dining_line_length (for wait times). With many dining siblings, explicit usage guidance is missing.

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 full responsibility for behavioral disclosure. It only says 'resolve' with an example, but does not describe what the tool returns (e.g., full name, address, coordinates), whether it performs any side effects, or any authentication or rate limits. The behavior of an optional query that lists all when omitted is only hinted in the schema, not reinforced in the description.

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 concise sentence plus a data source tag. It is front-loaded with the core action and includes a helpful example. Every part contributes to understanding, but given the lack of output schema and behavioral details, it could be slightly more informative without becoming verbose.

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 simple lookup tool with one parameter and no output schema, the description is adequate but incomplete. It tells the input and the mapping via example, but it does not specify what the output contains (e.g., full name only, or also location, image, etc.). The omission forces the agent to infer return structure, leaving some uncertainty.

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% for the single parameter 'query', and the schema already explains its behavior ('Omit to list all'). The description adds an example ('LWSN') but does not provide additional semantics such as case sensitivity, exact format, or partial matching rules. With full schema coverage, baseline is 3, and the description adds minimal extra value.

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 purpose: resolving a Purdue building short code or name into its full name, with a concrete example ('LWSN' -> Lawson Computer Science Building). It distinguishes itself from sibling tools (e.g., bus_stops, dining_locations) which cover other campus domains, leaving no ambiguity about the resource being building codes.

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 implicitly tells when to use this tool (when you have a building code or partial name) and includes a data source. However, it does not explicitly state when not to use it or mention any alternatives among siblings, though no direct alternative building lookup tool exists. The omission of explicit usage boundaries keeps it from a 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 full burden. It mentions that data is live (from LibCal), which is helpful context. However, it does not disclose any behavioral traits such as whether the tool requires authentication, rate limits, or what happens if the LibCal source is unavailable. The boolean parameters' effects are hinted but not fully detailed (e.g., 'open_now' returns only currently open libraries).

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 exceptionally concise, using only two sentences that cover purpose, scope, and data source without any wasted words. It is front-loaded with the most critical information ('Today's hours and open/closed status') and provides examples of library names to clarify the query parameter's use.

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 that there are three optional boolean parameters, no output schema, and no annotations, the description fairly sets expectations about what is returned (hours/status for today or a week). It could be more complete by describing the output format (e.g., 'returns library name, hours, and a boolean for open/closed') or by disclosing potential error conditions (e.g., if the source is down). However, for a simple query tool, the description is largely adequate.

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%, meaning each parameter (week, query, open_now) has a description. The tool description adds context by naming specific libraries ('WALC, Hicks, HSSE, Parrish, Archives') and explaining that 'week' returns 'a full week's grid', but it does not explicitly define parameter syntax or constraints beyond what the schema already provides. Baseline 3 is appropriate since the schema and description together give sufficient but not enriched semantics.

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-resource pair ('hours and open/closed status for every Purdue library and study space') and distinguishes itself from the many siblings (e.g., dining, bus, athletics) by focusing exclusively on library hours. It also mentions the data source ('Purdue Libraries LibCal (live)').

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 provides clear context about what the tool returns (today's hours or a full week's grid) and implicitly guides the agent to use it for library hours queries versus any of the 28+ sibling tools. However, it does not explicitly say when NOT to use it or mention alternatives for related but different queries (e.g., library event hours).

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 full burden. It discloses the tool returns subject codes with optional name filtering and cites Purdue.io as source, but does not mention whether subjects are sorted, include inactive codes, or require authentication. The description is adequate but lacks depth for a data discovery tool.

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 sentence plus a source attribution, containing zero fluff. Every word adds value: it specifies the domain (Purdue), the data (subject codes), examples (CS, MA, ENGR), the optional filter, and the source. Highly efficient.

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 is simple (one optional param, no nested objects, no output schema), the description sufficiently explains what the tool returns and its optional filter. It doesn't include pagination or sort order, but for a list of subject codes this is likely unnecessary. The source attribution adds credibility. Complete for its simplicity level.

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% for the single parameter 'query', and the description mentions it filters by name or abbreviation, which adds context beyond the schema's 'Filter by name or abbreviation'. However, since there is only one optional parameter and the schema already describes it, the description's additional value is minimal, baseline 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 lists all course subject codes at Purdue (specific examples given: CS, MA, ENGR) and mentions an optional filter by name. It distinguishes itself from sibling tools like 'list_terms' and 'search_courses' by focusing on subject codes rather than courses or terms.

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 the tool returns unfiltered subject codes unless a query is provided, but does not explicitly state when to use this tool vs siblings (e.g., when to call this before 'search_courses'). No explicit exclusions or alternatives are mentioned, though context signals show many sibling tools exist that might need this subject data.

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 provided, the description carries the full burden of behavioral disclosure. It reveals ordering ('newest first'), content ('codes and date ranges'), and data source ('Purdue.io community catalog mirror'). However, it does not mention that the tool is read-only, any rate limits, or what happens when the 'limit' parameter is omitted (e.g., returns all terms). The description gives useful context but is not exhaustive.

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 three sentences, each serving a distinct purpose: what the tool does, how to use the output, and the source. It is front-loaded with the most important information and contains no wasted words.

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 simplicity (one optional parameter, no output schema, no annotations), the description covers the essential aspects: output content, ordering, and linkage to other tools. It does not detail the return format or pagination, but for a straightforward listing tool, the description is largely 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?

Schema description coverage is 0% (the 'limit' parameter is not mentioned in the description). The description must compensate for low coverage, but it fails to explain the parameter's purpose, behavior, or effect. The schema itself provides min/max, but the description adds no value beyond that.

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 verb ('list'), the resource ('Purdue academic terms'), and the specifics: 'Every term in the Purdue course catalog, newest first, with codes and date ranges.' It also distinguishes itself from sibling tools like 'banner_terms' by naming the source (Purdue.io) and indicating its use with other course tools.

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 provides explicit guidance: 'Use the code with the other course tools,' which tells the agent when to use this tool (to obtain term codes for subsequent course-related tools). It does not explicitly exclude alternatives or mention when not to use it, but the context is clear.

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 full burden for behavioral disclosure. It only says 'Articles from' and 'public feed', which hints at a list of recent articles but does not specify pagination, ordering, rate limits, or whether it returns full text or summaries. The behavior regarding the limit parameter (e.g., how many total articles exist) is unaddressed.

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 with two sentences, front-loading the main resource and topics. Minor redundancy with the title ('student newspaper' appears in both). Nearly perfect, but could be slightly tighter.

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?

Despite low complexity (2 optional parameters, no nested objects), the description fails to hint at the return format (full articles, summaries, titles), which is critical since no output schema exists. The absence of annotations and behavioral details leaves the agent underinformed for invocation and response handling.

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 covers both parameters (limit and section) with descriptions (defaults, min/max, enum values). The description adds no new meaning beyond listing some topics that may correspond to sections, but does not clarify what each enum value contains. Baseline 3 is appropriate given 100% schema coverage.

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 provides articles from the Purdue Exponent, an independent student newspaper, and lists specific topics (campus reporting, student government, local news, sports coverage). It distinguishes from sibling tools like purdue_news by emphasizing editorial independence and the specific source (purdueexponent.org).

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 student newspaper content versus official university news (via the 'editorially independent' phrase), but does not explicitly state when to use this tool over alternatives like purdue_news or athletics_sports. No guidance on parameter selection (limit, section) or when not to use is provided.

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 must disclose behavior. It reveals the data source and live API, but does not mention whether repeated calls count against a rate limit, if results are cached, or what happens when the API is unavailable. This is adequate but not comprehensive for a tool with no annotations.

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, well-structured sentence that front-loads the purpose and optionally adds implementation detail in a parenthetical. Every word adds meaning with no redundancy.

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 simple schema (3 optional params, no output schema), the description covers the core behavior (search news, get headlines or full text) and source. It could mention that results are a list of articles or clarify the 'excerpt' default, but for a straightforward read-only tool it is largely sufficient.

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 context by naming the source and the search type ('keyword'), but does not elaborate on the parameters beyond what the schema already documents. No extra value is given for limit or full_text.

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 retrieves official Purdue newsroom articles with a specific verb-resource combination. It distinguishes itself by naming the source domain and API backend, and the scope (research announcements, university decisions, campus news) is explicit.

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 when to use keyword search ('searchable by keyword') and that omitting the query yields the latest headlines. It does not explicitly contrast with siblings like reddit_purdue or purdue_exponent, but the source (official newsroom) naturally sets it apart.

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 and does well: it discloses the data source (Purdue RecWell live facility counts), update frequency (~every 30s), and the caveat 'every counted space'. This adds meaningful context about data recency and scope, though it doesn't address potential error states or data unavailability.

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 two sentences, front-loaded with the key output, and contains no redundancy. Every phrase adds value: real-time, headcount, percent-of-capacity, scope, source, and update frequency.

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 simple read-only lookup with optional filters and no output schema, the description fully conveys return semantics (headcount and percent), data freshness, and the user-facing question it answers. Given 100% parameter schema coverage, the description is self-sufficient.

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?

All three parameters (sort, query, open_only) have descriptions in the JSON schema, achieving 100% coverage. The tool description adds only minor extra meaning (e.g., example query values) beyond the schema, so the baseline 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 provides real-time headcount and percent-of-capacity for Purdue RecWell spaces, using the verb 'answers' and enumerating specific areas (fitness floors, tracks, courts, climbing walls, pools). This unambiguously distinguishes it from sibling tools focused on other domains like dining or transit.

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 usage context by stating it answers 'how busy is the gym right now' and scopes itself to RecWell facilities. However, it doesn't explicitly mention alternatives such as dining_line_length for real-time crowding in dining venues, so it only partially satisfies the 'when vs alternatives' guidance.

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 bears full responsibility. It discloses the source (Reddit, public feed), content nature (unofficial, opinion-based), and lack of university moderation. However, it does not state whether the tool is read-only, requires authentication, or has rate limits. The description adds value beyond the schema but lacks full behavioral details.

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 the main purpose ('Current posts from r/Purdue') and includes a relevant disclaimer. At three sentences, it is slightly verbose with example categories, but still efficient. No wasted words, but could be trimmed slightly without losing meaning.

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 gives context on content type and source but does not describe the output format (e.g., titles, URLs, text, timestamps). Since there is no output schema, the description should compensate, but it only mentions 'posts' without structural details. The parameters are well-covered, but the return value is underspecified.

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 schema already explains both parameters ('sort' and 'limit') with defaults and constraints. The description adds no additional meaning or guidance for parameter selection, such as recommending 'hot' for trending or 'new' for recent. Baseline 3 is appropriate when the schema is sufficient.

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 provides 'Current posts from r/Purdue' and lists example content (housing, campus gripes, events, advice). It effectively distinguishes from all sibling tools, which are official Purdue services (bus, dining, courses, etc.), making the Reddit community focus unique and unambiguous.

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 informal student opinions ('unofficial student pulse', 'treat as opinion, not fact') but does not explicitly contrast with sibling tools like 'purdue_news' or 'purdue_exponent' for official information. While no direct alternative exists, guidance on when to prefer this over other sources is missing, though the context is implied.

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 provided, the description carries the full burden of behavioral disclosure. It clearly states that data is 'live' from 'BoilerLink / Anthology Engage', implying freshness and external dependency. It also specifies the type of information returned (time, room, host org). A minor gap: it doesn't mention read-only behavior or potential network latency, but the source declaration is strong 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 two sentences with zero waste. It front-loads the purpose, specifies key output fields, distinguishes from a related tool, and cites the data source. Every sentence earns its place.

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 low parameter count (2), full schema coverage, and no output schema, the description covers the essential: what events are returned, their attributes, and the source. It lacks details on return structure (e.g., result count, fields always present) but is largely complete for a filtered search tool.

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 mentions 'keyword' indirectly via examples in the schema, but does not add extra semantics beyond the schema. No new meaning is provided about the 'limit' or 'query' parameters beyond what the schema already documents.

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 uses specific verbs ('search', 'upcoming') and resource ('student organization events on BoilerLink') and distinguishes from sibling tools like search_events and academic_calendar by mentioning 'student org' events, time, room, host org, and the source. It clearly separates from the 'official university calendar'.

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 states the tool is for 'upcoming student organization events' and notes it's 'distinct from the official university calendar', giving context for when to use it. However, it does not explicitly mention when not to use it or name specific sibling alternatives (e.g., search_events for academic events) as a counter-recommendation.

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 provided, the description bears full responsibility for disclosing behavioral traits. It indicates this is a search/query operation (read-only), but does not explicitly state that it is non-destructive, mention rate limits, pagination, default limit behavior, or what happens when no results are found. The description is too minimal to fully inform an agent about side effects or safety.

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 consists of two succinct sentences that front-load the purpose and return values. Every word adds value, and there is no fluff.

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 no output schema, the description explains that the tool returns titles, credit hours, and descriptions, which is sufficient for a basic search. However, it omits details about pagination, ordering, or the interaction between parameters (e.g., all optional). It is mostly complete for a simple search tool but could be slightly more informative.

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 100% and each parameter has a description. The tool description only summarizes the criteria generally (subject, number, title keyword) without adding new semantics beyond the schema. The baseline of 3 is appropriate since the schema already does 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 uses a specific verb 'Find' and resource 'courses', and lists the search criteria (subject, number, title keyword) and return fields (titles, credit hours, descriptions). It clearly states what the tool does but does not differentiate it from sibling tools like course_sections or course_availability.

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?

No guidance is provided on when to use this tool versus alternatives, nor does it specify prerequisites, exclusions, or when not to use it. For example, it doesn't mention that course_sections should be used after a course is found, or that all parameters are optional but at least one is recommended.

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 full burden. It mentions the source is live but does not disclose any behavioral traits such as rate limits, caching, pagination behavior, or whether the query parameter is optional. The agent gets minimal insight beyond the schema.

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 with two sentences, front-loading the purpose and source. It is well-structured and avoids unnecessary verbosity.

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 absence of annotations and output schema, the description provides basic context (event types, source) but lacks details on return format, pagination, or date range behavior. It is adequate but not comprehensive.

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 schema already documents all four parameters with descriptions. The description adds no additional parameter-level meaning beyond stating the source. Baseline 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 it searches the official Purdue campus event calendar, lists specific event types (lectures, athletics, concerts, deadlines, career fairs), and identifies the live source. It effectively distinguishes from sibling tools like search_club_events and academic_calendar.

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 the tool is for searching official campus events but provides no explicit guidance on when to use this tool versus alternatives like search_club_events or athletics_upcoming. No 'when-not-to-use' or selection criteria are given.

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 must disclose behavioral traits. It mentions the source (BoilerLink/Anthology Engage, live) and the number of organizations (~1,200), which is helpful, but it omits key behaviors such as whether the operation is read-only, pagination behavior, order of results, or any side effects. The description adds some context but is insufficient for a search tool with zero annotations.

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 sentence followed by a source attribution. It front-loads the purpose and includes a helpful number of organizations and data source. Every word earns its place, no redundancy.

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 is complete enough for the parameter coverage but lacks any mention of the output format or return structure. Since there is no output schema, the agent is left guessing what fields are returned (e.g., organization name, description, contact info). For a search tool, this is a notable gap. The description otherwise covers the source and scope adequately.

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% (both parameters have descriptions in the input schema). The description does not add additional meaning beyond what the schema already provides: 'query' is described as 'Keyword, e.g. 'robotics', 'a cappella', 'finance' and 'limit' has default and range. Baseline 3 is appropriate when schema covers all parameters.

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?

Clearly states the verb 'Search' and the resource 'BoilerLink's directory of ~1,200 registered student organizations by name or keyword.' This differentiates it from sibling tools like search_events or search_club_events which search different entities.

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?

No guidance on when to use this tool over alternatives or when not to use it. The description only states what it does, implying usage context but lacking explicit when-to-use or when-not-to-use advice. Among many search-related siblings, this omission could confuse the 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?

No annotations are provided, so the description carries the full burden. It discloses the source as 'public, live' and hints at non-destructive behavior. However, it does not mention authentication requirements, rate limits, or whether the data is cached, missing some behavioral context that annotations would typically cover.

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?

Three sentences with no filler. The first sentence front-loads the tool's value ('Everything Banner knows about one section'), followed by a purpose statement and a sibling clarification. Every sentence serves a distinct purpose.

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 simplicity (2 parameters, no output schema), the description adequately covers return values (seats, waitlist, etc.) and distinguishes from related tools. It could mention that results are for a single CRN (implied in title) or note any pagination limits, but it is largely complete for this complexity level.

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 100% with both parameters already described in the schema. The description adds purpose context but does not enhance parameter meaning beyond what the schema provides (e.g., it doesn't elaborate on the 'term' parameter beyond the default behavior). Baseline 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 uses specific verbs and resources: 'Everything Banner knows about one section', listing concrete data types (seats, waitlist, prerequisites, restrictions). It answers a clear user question ('why can't I register') and distinguishes from siblings by noting meeting times come from other tools.

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?

It explicitly directs the agent to course_availability or course_sections for meeting times, providing clear context on when this tool is not needed. However, it does not explicitly state when to use this tool over other registration-related siblings like search_courses, leaving some inference to the agent.

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