Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OSU MCP Server Show me upcoming Ohio State football games"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive MCP (Model Context Protocol) server that provides access to The Ohio State University's content APIs across multiple campus services including transportation, academics, dining, recreation, libraries, events, and more.
This server provides 50+ tools across 14 different service categories for LLMs:
get_athletics_all: Get information about all OSU athletics programs and schedules
search_sports: Search for specific sports or teams
get_sport_by_gender: Find sports programs by gender
get_upcoming_games: Get upcoming games and events across all sports
get_buildings: Get information about all OSU buildings
search_buildings: Search for buildings by name or building number
get_building_details: Get detailed information about a specific building
find_room_type: Find buildings with specific room types (lactation, sanctuary, wellness, gender inclusive restrooms)
get_bus_routes: Get information about all OSU bus routes
get_bus_stops: Get stops and route information for a specific bus line
get_bus_vehicles: Get real-time vehicle locations for a specific route
get_academic_calendar: Get the academic calendar with important dates
get_university_holidays: Get university holidays
search_calendar_events: Search for specific events in the academic calendar
get_holidays_by_year: Get holidays for a specific year
search_classes: Search for OSU classes by keyword, subject, instructor, etc.
get_campus_events: Get information about all campus events
search_campus_events: Search for campus events by title or description
get_events_by_tag: Find events by specific tags or categories
get_events_by_location: Find events at a specific location
get_events_by_date_range: Find events within a specific date range
get_dining_locations: Get all OSU dining locations with basic information
get_dining_locations_with_menus: Get dining locations with menu section information
get_dining_menu: Get detailed menu items for a specific dining location section
get_university_directory: Get the university directory information
search_people: Search for people in the OSU directory by first and/or last name
get_foodtruck_events: Get information about all food truck events on campus
search_foodtrucks: Search for food trucks by name or cuisine type
get_foodtrucks_by_location: Find food trucks at a specific location
get_library_locations: Get information about all OSU library locations
search_library_locations: Search for library locations by name
get_library_rooms: Get information about all available library study rooms
search_library_rooms: Search for library study rooms by name or location
get_rooms_by_capacity: Find library study rooms by capacity
get_rooms_with_amenities: Find library study rooms with specific amenities
get_buckid_merchants: Get information about all merchants that accept BuckID
search_merchants: Search for merchants by name or category
get_merchants_by_food_type: Find merchants by food/cuisine type
get_merchants_with_meal_plan: Find merchants that accept meal plans
get_parking_availability: Get real-time parking availability for all OSU parking garages
get_recsports_facilities: Get information about all OSU recreation sports facilities
search_recsports_facilities: Search for recreation sports facilities by name
get_facility_details: Get detailed information about a specific recreation facility
get_facility_hours: Get current operating hours for all recreation facilities
get_facility_events: Get scheduled events for recreation sports facilities
get_student_organizations: Get information about all student organizations
search_student_orgs: Search for student organizations by name or keywords
get_orgs_by_type: Find student organizations by type or category
get_orgs_by_career_level: Find organizations for specific career levels
Related MCP server: Canvas MCP Server
Clone this repository
Install dependencies:
npm installBuild the server:
npm run buildAdd this server to your Claude Desktop configuration file:
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"osu": {
"command": "node",
"args": ["/path/to/ohio-state-mcp-server/build/index.js"]
}
}
}You can also run the server directly:
npm startTo run in development mode with automatic rebuilding:
npm run devThis server uses The Ohio State University's content APIs.
MIT
Find buildings that contain specific room types (lactation rooms, sanctuaries, wellness spaces, gender inclusive restrooms)
| Name | Required | Description | Default |
|---|---|---|---|
| room_type | Yes | Type of room to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a straightforward read operation but does not disclose behavior if no buildings match or any authentication needs. Adequate for simple query but lacks depth.
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?
Single sentence front-loaded with verb and resource, no wasted words. Efficiently communicates the tool's 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?
For a simple one-parameter tool with no output schema, the description is mostly complete. It could mention return format (e.g., building names/IDs) but still sufficient for agent to select and invoke 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 coverage is 100% with a clear enum and description. The tool description adds minimal value beyond the schema (contextualizes as 'buildings that contain' vs just 'room type'). 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 finds buildings containing specific room types, listing examples. This verb+resource combination distinguishes it from sibling building tools like get_buildings or search_buildings.
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 finding buildings by room type but provides no explicit when-to-use or when-not-to-use guidance. No mention of alternatives like search_buildings for name-based searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the academic calendar with important dates
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It only states what is retrieved, without mentioning response format, scope (e.g., current year only), update frequency, or any limitations.
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?
One short, clear sentence with no wasted words. Could be slightly more informative without losing 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 parameterless tool, the description is moderately complete. However, the lack of output schema and overlap with siblings mean more detail would improve completeness.
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?
There are no parameters, so schema coverage is 100%. The description adds 'with important dates' which slightly clarifies the content but is minimal. 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 retrieves the academic calendar with important dates, using a specific verb and resource. However, it does not differentiate from similar sibling tools like get_university_holidays or search_calendar_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?
No guidance is provided on when to use this tool versus alternatives. With multiple calendar-related siblings, explicit usage context is needed but absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all OSU athletics programs and schedules
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get information' implies a read-only operation, which is appropriate. However, it does not disclose any additional behavioral traits such as potential large response size, rate limits, or authentication needs.
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, clear sentence with no wasted words. It is appropriately sized for a tool with no parameters.
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 largely complete. However, it could be improved by indicating the type of information returned (e.g., list of programs, schedules) or noting that the response may be large.
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?
There are no parameters (schema coverage 100%), so the description does not need to add parameter information. The baseline for 0 parameters is 4, and the description meets 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 'Get information about all OSU athletics programs and schedules' clearly states the verb 'get', the resource 'athletics programs and schedules', and the scope 'all'. This distinguishes it from siblings like 'search_sports' (filtered search) and 'get_upcoming_games' (specific subset).
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 a comprehensive list without filtering, but does not explicitly state when to use this tool versus siblings like 'search_sports' or 'get_sport_by_gender'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all merchants that accept BuckID
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only indicates a read operation ('Get information') but lacks details on performance, rate limits, authentication needs, or whether the result is paginated. Minimal 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?
One clear, front-loaded sentence. 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?
For a zero-parameter tool returning a list of all merchants accepting BuckID, the description is mostly complete. However, given no output schema, a mention of the return format (e.g., list of merchant names and details) would improve completeness.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed.
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 'Get' and the resource 'information about all merchants that accept BuckID'. It distinguishes from sibling tools like 'get_merchants_by_food_type' which filter by food type.
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 versus alternatives such as 'search_merchants' or 'get_merchants_with_meal_plan'. The description does not provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific building including rooms, departments, and special spaces
| Name | Required | Description | Default |
|---|---|---|---|
| building_number | Yes | Building number to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool returns detailed information including rooms, departments, and special spaces, but does not disclose read-only status, permission requirements, or any side effects. For a read operation, this is insufficient 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 a single sentence that efficiently conveys the tool's purpose and output, with no extraneous information. It is appropriately 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 the tool's simplicity (one required parameter, no output schema, no nested objects), the description is fairly complete by specifying the types of information returned (rooms, departments, special spaces). However, with no annotations, a mention of expected behavior or error cases could enhance completeness.
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 parameter 'building_number' described in both schema and description. However, the description adds minimal meaning beyond the schema, merely implying it refers to a specific building. No format or additional context is provided.
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 ('Get detailed information') and resource ('a specific building'), and clearly distinguishes from sibling tools like get_buildings (list all) and search_buildings (search).
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 provided. The usage context is implied (when you have a building number), but no alternatives or exclusions are mentioned, even though sibling tools like search_buildings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all OSU buildings including addresses, locations, departments, and room details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states 'Get information' but does not disclose whether authentication is required, if there are rate limits, or how 'all' is handled (e.g., pagination). The tool could be a read-only operation, but this is not confirmed beyond the verb 'Get'.
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 immediately conveys the tool's purpose and the types of information included. It is concise and front-loaded with the key action and resource.
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 parameters and no output schema, the description adequately explains what the tool returns (addresses, locations, departments, room details). However, it lacks details on response format, ordering, or pagination, which would improve completeness.
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% schema description coverage. The description adds context about the returned data but does not need to explain parameters. Baseline 4 for 0 parameters 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 retrieves information about all OSU buildings, listing specific data types (addresses, locations, departments, room details). It distinguishes itself from sibling tools like 'search_buildings' (which implies filtering) and 'get_building_details' (singular).
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 provide explicit guidance on when to use this tool versus alternatives like 'search_buildings' or 'get_building_details'. While the name implies a listing of all buildings, there is no mention of use cases or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all OSU bus routes/lines
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get information' implying read-only behavior, but does not disclose any other traits like side effects, permissions, or rate limits. Minimal behavioral transparency beyond the basic operation.
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?
Single sentence with no superfluous words. Information is front-loaded and 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?
Low complexity tool with no parameters and no output schema. The description is minimal but does not specify the format or details of the returned information, leaving room for ambiguity. Adequate but not 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?
No parameters; schema coverage is 100%. The description does not need to add parameter semantics, and baseline 4 applies for zero 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?
The description specifies the verb 'Get' and the resource 'all OSU bus routes/lines', clearly distinguishing from sibling tools like get_bus_stops and get_bus_vehicles. However, 'information' is vague and could be more specific.
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 versus alternatives or when not to use it. No context provided for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all stops and route information for a specific bus line
| Name | Required | Description | Default |
|---|---|---|---|
| route_code | Yes | Bus route code (ACK, BE, CC, CLS, ER, MC, MM, NWC, WMC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it offers no behavioral details beyond the basic action. It does not disclose what constitutes 'route information', whether results are ordered, or any side effects (e.g., network calls). The description is too sparse to enable informed invocation.
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 of 12 words with no redundancy. Every word contributes to purpose. No waste.
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 (one parameter, no output schema), the description fails to specify what 'route information' includes or what the output format looks like. Without output schema, the description should at least mention typical fields (e.g., stop names, coordinates). The minimal description leaves the agent guessing.
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% (one parameter fully documented as an enum). The description adds no extra meaning beyond what the schema provides: 'for a specific bus line' is already implicit in the parameter name and enum. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('all stops and route information') and scope ('for a specific bus line'). It distinguishes from sibling tools like 'get_bus_routes' (which likely lists lines) and 'get_bus_vehicles' (which tracks vehicles).
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 context ('for a specific bus line') but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or prerequisites are mentioned, though the sibling set suggests 'get_bus_routes' as a prerequisite to obtain route codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time vehicle/bus locations for a specific route
| Name | Required | Description | Default |
|---|---|---|---|
| route_code | Yes | Bus route code (ACK, BE, CC, CLS, ER, MC, MM, NWC, WMC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states 'real-time' but does not explain the output format (e.g., coordinates, vehicle IDs), whether it requires authentication, or any caching/rate limit behavior. The description is minimal at best.
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 that immediately conveys the tool's purpose. There is no unnecessary wording, making it 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 simplicity of the tool (one parameter, no output schema), the description is somewhat adequate but lacks details about return values, potential errors, or how to interpret results. For a tool fetching real-time data, more context on data freshness or limits would improve completeness.
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 parameter having a clear enum and description. The tool description adds no additional semantics beyond what the schema already provides. The baseline of 3 applies because the schema handles parameter documentation 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 uses a specific verb 'Get' and resource 'real-time vehicle/bus locations for a specific route'. It clearly distinguishes from sibling tools like get_bus_routes (which provide static route info) and get_bus_stops (which provide stop info).
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 when real-time vehicle locations for a route are needed, but it does not explicitly state when to use this tool versus alternatives like get_bus_routes or get_bus_stops. No when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all campus events
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It does not mention data source, event date range, ordering, or any constraints. The agent cannot assess side effects or limitations.
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 terse sentence. It is concise but lacks structure or additional useful details. It earns its place but could be more 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?
With no parameters, no output schema, and no annotations, the description should explain what 'information' is returned. It does not mention event fields, pagination, or scope, leaving the agent underinformed.
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?
Baseline 4 for 0 parameters. The description adds no param info beyond schema, but schema is trivial (empty). It correctly indicates no inputs are needed.
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 clear verb-resource pairing ('Get information about all campus events'). It implies a broad fetch, but does not explicitly distinguish it from siblings like search_campus_events or filtered event 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 guidance is provided on when to use this tool versus alternatives such as search_campus_events, get_events_by_tag, or get_events_by_date_range. The agent has no decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all OSU dining locations with basic information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions 'basic information' but lacks specifics on what fields are returned (e.g., name, address, hours). No safety or effect information.
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?
Single sentence, front-loaded with action and scope, no unnecessary words. Highly 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?
Tool has no output schema, so description should clarify return format. 'Basic information' is vague and insufficient for an agent to understand what data will be available.
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 has no parameters, so baseline is 4. Description adds context about OSU dining locations, but adds nothing beyond what schema already conveys (which is nothing).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns all OSU dining locations with basic information. The sibling 'get_dining_locations_with_menus' implies this one excludes menus, providing distinction.
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 over siblings. Implied by description (basic info vs with menus) but no exclusions or alternatives stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find events within a specific date range
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | End date in YYYY-MM-DD format | |
| start_date | Yes | Start date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as pagination, sorting, authentication requirements, or scope limitations. It only states the basic function without revealing how events are returned or if any constraints apply.
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, making it efficient. However, it is under-specified; a bit more detail could be added 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?
Given no output schema, no annotations, and many sibling tools, the description is incomplete. It does not specify what data is returned, event details, or any limitations, leaving the agent without sufficient context to use the tool effectively.
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 schema. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and resource 'events' with the constraint 'within a specific date range'. It distinguishes itself from sibling tools that filter by tag, location, or other criteria.
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 for date range queries but does not explicitly provide guidance on when to use this tool versus alternatives like search_campus_events or get_events_by_tag. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find events at a specific location
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location to search for events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully disclose behavior. It only states 'Find events at a specific location' without details on scope (e.g., date range, event types), authorization needs, or side effects (e.g., read-only). This is insufficient for a tool with no annotation coverage.
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?
Very concise single sentence, front-loads the purpose. However, it sacrifices completeness for brevity; more detail could be added without becoming wordy.
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 simplicity (1 param, no output schema, no annotations) and the abundance of sibling event tools, the description does not provide enough context about the scope, return format, or how it differs from others. Incomplete for reliable selection.
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 one parameter 'location' described as 'Location to search for events'. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Find' and resource 'events' with a specific filter 'at a specific location'. It distinguishes from siblings like get_events_by_tag and get_events_by_date_range by focusing on location-based filtering.
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 vs alternatives. Sibling tools include get_events_by_tag, get_events_by_date_range, get_campus_events, etc., but no explicit when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find events by specific tags or categories
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag or category to filter events by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states basic purpose. Does not disclose whether events are upcoming, all events, required authentication, or response structure.
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?
Single sentence with no waste, but lacks structure or front-loading of critical info. Could be more efficient by including usage context.
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 filter tool with one parameter and no output schema, the description provides minimal necessary info, but omits key behavioral traits like result structure or pagination.
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 description adds little beyond the schema's own description of 'tag'. No additional parameter semantics or constraints provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds events by tag or category, distinguishing it from siblings that filter by location or date range. However, it does not explicitly state that results are events matching the given tag.
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 versus alternatives like search_campus_events or get_events_by_date_range. Lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific recreation sports facility
| Name | Required | Description | Default |
|---|---|---|---|
| facility_id | Yes | Facility ID to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'get detailed information' without revealing side effects, authentication requirements, rate limits, or what constitutes 'detailed information.' The tool is likely read-only, but this is not confirmed.
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 with no unnecessary words. It is appropriately front-loaded and 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 lack of an output schema, the description should compensate by summarizing the return fields or behavior. It only says 'detailed information,' leaving the agent uninformed about the response structure. This is insufficient.
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 the description adds limited value beyond the schema. It provides domain context ('recreation sports facility') but does not elaborate on the facility_id parameter's format or constraints beyond what is 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 retrieves detailed information about a specific recreation sports facility, using a specific verb ('Get') and resource ('detailed information about a specific recreation sports facility'). It effectively distinguishes from sibling tools like get_recsports_facilities (list) and search_recsports_facilities (search).
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 when a specific facility ID is known and full details are needed, but it does not explicitly state when to use this tool versus alternatives (e.g., listing or searching). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scheduled events for recreation sports facilities
| Name | Required | Description | Default |
|---|---|---|---|
| facility_id | No | Optional facility ID to filter events for a specific facility |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Indicates a read operation with no side effects, but does not disclose pagination, date range, or what time period of events is returned.
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?
Single sentence is efficient and front-loaded. Could be expanded to include more contextual information 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?
Given one optional parameter and no output schema, description is adequate. Lacks details on return format or limitations, but tool complexity is low.
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 fully describes the only parameter (facility_id) as 'Optional facility ID to filter events'. Description adds no additional semantic value beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Get) and resource (scheduled events for recreation sports facilities). It distinguishes from siblings like get_facility_hours and get_campus_events by specifying 'recreation sports'.
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 vs alternatives like get_facility_hours or get_campus_events. Lacks context on prerequisites or filtering beyond the optional facility_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current operating hours and open/closed status for all recreation facilities
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'current operating hours' but does not disclose if the data is cached, how fresh it is, or any potential latency. No behavioral traits beyond the basic functionality are mentioned.
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, clear sentence with no extraneous words. Every part contributes to understanding the tool's 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 has no parameters, no output schema, and simple functionality, the description sufficiently explains what it does. It could potentially mention the format of the hours (e.g., days of week) but is otherwise complete for an agent to understand its use.
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?
There are no parameters, and schema description coverage is 100%. The description adds value by specifying what the tool returns (hours and status for all facilities), which is beyond the schema. Baseline 4 is appropriate as no parameters need explanation.
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 'Get' and the specific resource: 'current operating hours and open/closed status for all recreation facilities'. This directly distinguishes it from sibling tools like 'get_facility_details' or 'get_recsports_facilities'.
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 indicates it returns hours for 'all recreation facilities', implying a broad listing without filtering. It provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. For a simple, no-parameter tool, this is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all food truck events on campus
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get information', implying a read operation, but fails to mention any potential rate limits, authentication needs, or what constitutes an 'event'. The minimal description does not compensate for the missing annotation safety hints.
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, straightforward sentence with no wasted words. It is concise and front-loaded, but it could be expanded to include more context without losing efficiency, given the tool's simplicity.
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, no-output-schema tool, the description is minimally adequate: it states what the tool returns ('information about all food truck events on campus'). However, it does not specify the structure or fields of the response, which may be needed for proper invocation.
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, so the schema coverage is effectively 100%. The baseline for 0 parameters is 4, and the description adds no extra meaning beyond the schema, which is appropriate given there are no parameters to document.
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 'Get' and resource 'food truck events on campus', making the purpose obvious. However, it does not differentiate from sibling tools like search_foodtrucks or get_foodtrucks_by_location, which may cause confusion about what 'events' means compared to other food truck queries.
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 such as search_foodtrucks or get_foodtrucks_by_location. There is no context about prerequisites, ideal use cases, or situations where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find food trucks at a specific location
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location to search for food trucks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only states the purpose without revealing read-only nature, expected output, or any side effects. This lacks necessary 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 a single sentence, making it concise but not optimally structured. It lacks front-loading of critical information or formatting to enhance scannability, though it does not waste 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 absence of an output schema and only one parameter, the description should provide at least a hint about what the tool returns (e.g., list of food trucks). It does not, leaving the agent without expected outcome context.
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 a single parameter 'location' described as 'Location to search for food trucks'. The tool description adds no additional meaning beyond the schema, so a 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 'Find food trucks at a specific location' clearly states the verb (find), resource (food trucks), and context (by location). The name and description align well, and the tool is differentiated from siblings like search_foodtrucks by focusing on location-based queries, though not explicitly stated.
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 when a location is known, but provides no guidance on when not to use it or alternatives. Sibling tools like search_foodtrucks might serve broader queries, but no explicit comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get holidays for a specific year
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Year to get holidays for |
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 correctly implies a read operation with no side effects, but adds no extra details about result format, pagination, or potential errors. This is adequate but minimal for a simple retrieval 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, concise sentence that conveys the tool's purpose without any redundant or unnecessary words. It is appropriately front-loaded and easy to parse.
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, no nested objects), the description is largely complete. It explains what the tool does and what input it expects. It could benefit from noting the output format or adding a brief example, but for a straightforward lookup, it is 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?
The input schema has 100% coverage, describing the 'year' parameter as 'Year to get holidays for'. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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 action (Get) and resource (holidays for a specific year), matching the name. However, it does not differentiate from the sibling tool 'get_university_holidays', which likely has a similar purpose, reducing clarity slightly.
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 like 'get_university_holidays' or 'get_academic_calendar'. There is no mention of prerequisites, preferred use cases, or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all OSU library locations including addresses, hours, and contact details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose whether the operation is read-only, data freshness, authentication needs, or side effects. Only states returned fields.
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?
Single sentence, front-loaded with verb and resource, no extraneous words. Perfectly concise and structured.
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 parameters and no output schema, description provides adequate context (returns addresses, hours, contact). However, does not mention return format or handling of empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is implied 100%. Description adds no parameter info, which is acceptable as there are none. Baseline score of 4 for zero params.
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 'get', resource 'library locations', and scope 'all' with specific details (addresses, hours, contact). Differentiates from sibling 'search_library_locations' which implies filtering.
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 versus siblings. The presence of 'search_library_locations' suggests a distinction but not mentioned. No prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all available library study rooms for reservation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states 'all available' but does not clarify what 'available' means or how availability is determined. It also omits details about return format or required permissions, making it minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, conveying the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks details about the output, such as what fields are returned or how 'availability' is defined. Given no output schema, more context would be helpful for 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?
The input schema has zero parameters with 100% coverage, so the description does not need to add parameter information. Baseline score of 4 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 verb 'Get information' and the resource 'all available library study rooms for reservation', which is specific and distinguishes it from sibling tools like search_library_rooms or get_rooms_by_capacity that imply filtering.
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 when you want all available rooms, but it does not explicitly state when to use this tool vs alternatives like search_library_rooms or get_rooms_with_amenities. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find merchants by food/cuisine type
| Name | Required | Description | Default |
|---|---|---|---|
| food_type | Yes | Food or cuisine type to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention query behavior (e.g., partial match, pagination), response format, or any side effects. The minimal description adds little beyond the tool name.
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 (one sentence), but it essentially repeats the tool name. It is not information-dense; it could be more concise if it added more value, but as is, it is minimally acceptable.
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 one parameter and no output schema, the description is incomplete. It lacks details on result format, matching behavior, and any constraints. While the tool is straightforward, the description should clarify what is returned and any limitations.
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 'food_type'. The description restates 'food/cuisine type', adding no significant extra meaning or context beyond the schema. With full coverage, 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 finds merchants by food/cuisine type, using a specific verb ('Find') and resource ('merchants'). However, among siblings like 'search_merchants' and 'get_merchants_with_meal_plan', it lacks differentiation of scope or usage.
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. There is no mention of prerequisites, exclusions, or when it is preferred over sibling tools like 'search_merchants'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find merchants that accept meal plans
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the purpose without disclosing any behavioral traits such as read-only nature, output format, or potential restrictions.
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 with no wasted words. It is front-loaded with the verb and resource.
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 no annotations, the description is minimal. It does not explain the output format or how meal plan acceptance is determined, leaving gaps for an agent. However, for a simple lookup, it may be 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?
There are no parameters, so the description does not need to add param info. The baseline for 0 params is 4, as the schema already fully covers 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?
The description clearly states the tool finds merchants that accept meal plans. It distinguishes from siblings like search_merchants (all merchants) or get_merchants_by_food_type (filtered by food type), though it could be more explicit about the scope.
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 vs alternatives. For example, if the user wants all merchants, search_merchants would be more appropriate, but this is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find organizations for specific career levels (undergraduate, graduate, professional)
| Name | Required | Description | Default |
|---|---|---|---|
| career_level | Yes | Career level: undergraduate, graduate, or professional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits beyond the basic function. It only states what the tool does (find orgs by career level) and does not disclose side effects, authentication needs, rate limits, pagination, or output format. This is insufficient 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 sentence with no unnecessary words. It is front-loaded and efficient. However, it could benefit from slight expansion to improve completeness without losing 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?
With no output schema, the description should explain what the tool returns (e.g., list of organization names/IDs). It does not. The tool is simple but the missing information could lead to incorrect expectations. The sibling context suggests it returns student organizations, but this is not explicit.
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 100% coverage with a description and enum for the single parameter. The description adds no further meaning; it only repeats the enum values in parentheses. Thus, it provides no additional value beyond the schema, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find organizations for specific career levels' with a verb and resource, and lists the possible levels. This distinguishes it from sibling tools like 'get_student_organizations' (likely listing all orgs) and 'get_orgs_by_type' (filtering by type). However, it does not explicitly say what is returned (e.g., names, IDs), so it is not maximally specific.
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 like 'search_student_orgs' or 'get_orgs_by_type'. There is no mention of when not to use it or what prerequisites exist, which limits effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find student organizations by type or category
| Name | Required | Description | Default |
|---|---|---|---|
| org_type | Yes | Organization type or category to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the filtering action but does not mention behavior on invalid types, pagination, authentication requirements, or rate limits. Minimal 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?
Single sentence with no unnecessary words. Efficiently conveys the tool's 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 simplicity (one parameter, no output schema, no annotations), the description covers the essential usage. It could benefit from mentioning behavior on no results or invalid types, but it is largely complete for a straightforward filter 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 coverage is 100% (one parameter fully described). The description adds no new semantic information beyond 'Organization type or category to search for', which is already in the schema. Baseline of 3 applies since description does not add 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 action ('find') and resource ('student organizations') with the filtering criterion ('by type or category'). It distinguishes from siblings like 'search_student_orgs' (general search) and 'get_orgs_by_career_level' (filtered by career level).
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 versus alternatives like 'get_student_organizations' or 'search_student_orgs'. The usage is implied by the description (filtering by type), but no exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time parking availability for all OSU parking garages
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'real-time' but does not disclose data freshness, caching behavior, rate limits, or what happens when no data is available. The behavioral disclosure is minimal.
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-front-loaded sentence with no waste. 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?
Given the tool has no parameters and no output schema, the description is fairly complete. It states the action, resource, and scope. However, an example or note on response format would be helpful, but it is 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?
There are no parameters, so baseline is 4. The description adds context that the data is real-time and covers all garages, which is sufficient for understanding the no-parameter call.
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 action ('Get'), the resource ('real-time parking availability'), and the scope ('all OSU parking garages'). It is specific and distinguishes from sibling tools that cover different domains like dining, athletics, and buses.
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, and there is no mention of any prerequisites or context. Although there are no sibling parking tools, the description lacks any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all OSU recreation sports facilities including hours, availability, and events
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It accurately states the tool returns facility information including hours, availability, and events, implying a read-only operation. However, it does not detail response format, data completeness, or any limitations.
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 of 16 words, efficiently conveying the tool's purpose. No unnecessary words, but it could be slightly more structured with a bullet list if needed.
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 context of many sibling tools and no output schema, the description provides a minimal outline of what is returned (hours, availability, events). However, it lacks details on data structure, pagination, or how this tool differs from its siblings, making it adequate but not fully 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?
There are no parameters, so the baseline is 4. The description effectively communicates that this tool retrieves all facilities without filtering, which compensates for the lack of 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?
The description clearly states the tool returns information about all OSU recreation sports facilities, specifying details including hours, availability, and events. However, it does not explicitly distinguish this broad list from more targeted sibling tools like get_facility_details or get_facility_hours, leading to potential ambiguity.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like search_recsports_facilities, get_facility_details, or get_facility_hours, which exist as siblings and might be more appropriate for specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find library study rooms that can accommodate a specific number of people
| Name | Required | Description | Default |
|---|---|---|---|
| max_capacity | No | Maximum number of people (optional) | |
| min_capacity | Yes | Minimum number of people the room should accommodate |
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 accurately describes a read operation but does not disclose details like pagination, availability status, or authentication requirements. Adequate but 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?
Single sentence, perfectly concise. No wasted words, front-loads the core 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?
For a simple capacity-filtered retrieval tool, the description provides sufficient context. However, it could mention the return format or note that results are limited to study rooms (vs general library spaces). Still, it is largely complete 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?
Schema description coverage is 100% as both parameters have descriptions. The description adds context ('accommodate a specific number of people') but does not enhance understanding beyond the schema's own descriptions of min/max capacity.
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 'find' and the resource 'library study rooms', with a specific criterion (capacity). It distinguishes from siblings like get_library_rooms and search_library_rooms, which are broader or differently scoped.
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 when capacity is important, but does not explicitly state when to use this tool vs alternatives (e.g., get_library_rooms for all rooms). No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find library study rooms that have specific amenities
| Name | Required | Description | Default |
|---|---|---|---|
| amenities | Yes | List of required amenities |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Find', implying a read operation but not confirming. It lacks details on rate limits, destructiveness, or expected behavior. The agent cannot infer safety or constraints.
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?
A single, front-loaded sentence that efficiently conveys the tool's purpose with zero 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 should at least hint at what is returned (e.g., list of rooms with details). It only covers the input criterion, leaving the agent uncertain about the response format.
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 the schema already documents the parameter. The description adds 'specific amenities' but no further semantics (e.g., whether all amenities must be present). 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 finds library study rooms filtered by specific amenities. It distinguishes itself from siblings like get_library_rooms (which likely returns all rooms) and get_rooms_by_capacity (filtered by capacity). However, it doesn't explicitly differentiate.
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 vs alternatives like search_library_rooms or get_rooms_by_capacity. The description implies usage for amenity filtering but provides no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find sports programs by gender
| Name | Required | Description | Default |
|---|---|---|---|
| gender | Yes | Gender category: men, women, or mixed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the basic purpose and does not disclose whether the operation is read-only, requires authentication, or any other behavioral 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?
The description is extremely concise: one sentence with no wasted words. It is front-loaded with the verb 'Find' and directly communicates the tool's 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, the description is minimal but lacks additional context such as what is returned, any constraints on usage, or how it compares to sibling tools. For a tool with no output schema and no annotations, more context would improve completeness.
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 single parameter is fully documented in the schema with an enum and description. The description adds no additional meaning beyond what the schema provides, but with 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('find') and the resource ('sports programs') with a specific filter ('by gender'). It distinguishes from sibling tools like 'get_athletics_all' and 'search_sports' by focusing on gender-specific filtering.
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 gender-specific sports queries but does not explicitly state when to use this tool over alternatives like 'search_sports' or 'get_athletics_all'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all student organizations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states 'Get information', implying a read operation, but provides no details on authentication, rate limits, pagination, or data size expectations.
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, which is concise, but it lacks substantive detail to fully inform an agent. It could be expanded 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?
Given no output schema and many sibling tools, the description fails to specify return format, field details, or expected data volume. An agent cannot determine what to expect from invoking this 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?
No parameters exist, so schema coverage is 100%. Per guidelines, baseline is 4. The description adds no parameter info, which is acceptable.
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 'Get' and resource 'student organizations' with scope 'all', distinguishing it from filtered sibling tools like 'search_student_orgs'. However, it could be more precise about what 'information' includes.
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 versus alternatives such as 'search_student_orgs', 'get_orgs_by_type', or 'get_orgs_by_career_level'. The agent is left to infer that 'all' implies unfiltered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the university directory information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as data freshness, authentication requirements, or whether the directory is static or dynamic. The description is purely functional with no 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 a single efficient sentence with no extraneous words. However, its brevity reduces clarity.
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 parameters and no output schema, the description is minimally adequate but lacks specificity about the directory contents. It does not compensate for the vagueness.
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 with 100% schema coverage, so no additional parameter description is needed. The baseline of 4 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 states the tool gets 'university directory information', but the resource is vague—it doesn't specify what fields are included (e.g., names, contact details). Among siblings, 'search_people' likely provides individual lookups, leaving ambiguity about this tool's scope.
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 like 'search_people' or other information tools. There are no usage contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get university holidays
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral information such as authentication needs, read-only nature, or data freshness. The agent has zero insight into the tool's 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?
While the description is concise (one short phrase), it is under-specified and fails to convey necessary details. Conciseness is not beneficial when it omits essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, but the description does not clarify what constitutes 'university holidays' (e.g., date range, scope). Sibling tools have more context, making this inadequate.
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?
There are no parameters, so the baseline is 4. However, the description adds no meaning beyond the tool name; it merely restates the function. A score of 3 is appropriate as it does not harm but provides no added 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 'Get university holidays' states the verb and resource but is too vague, lacking scope or differentiation from sibling tools like 'get_holidays_by_year' and 'get_academic_calendar'. The agent cannot determine what specific data is returned.
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 vs alternatives. Does not specify prerequisites or context, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming games and events across all sports
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Optional: filter by specific sport name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It only states basic action without disclosing behavior (e.g., date range, pagination, required permissions, or what 'upcoming' means).
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?
One sentence, no filler, front-loaded with verb and resource. 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?
For a tool with no output schema and one optional parameter, the description is too sparse. It lacks explanation of 'upcoming', scope, and how it differs from similar sports tools among many siblings.
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 covers 100% of parameters with descriptions. Tool description does not add any extra meaning beyond the schema, so 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?
Description uses specific verb 'get' and resource 'upcoming games and events', with scope 'across all sports'. Clearly distinguishes from siblings like search_sports and get_sport_by_gender.
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 versus alternatives like search_sports or get_athletics_all. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for buildings by name or building number
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for building name or building number |
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 states the tool searches, implying a read operation, but it does not confirm idempotency, safety, or disclose any behavioral traits such as partial matching, case sensitivity, pagination, or authentication needs.
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 with no extraneous information. It efficiently conveys the tool's purpose and criteria.
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 simplicity (1 parameter, no output schema, no annotations), the description adequately states the purpose but lacks any mention of what the tool returns, how results are formatted, or any behavioral constraints. It meets the minimum viable level but could be 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?
The schema description covers the parameter fully (100% coverage). The tool description adds no new information beyond what is already in the schema, as both state the same purpose ('Search term for building name or building number'). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the resource ('buildings'), specifying the search criteria ('by name or building number'). This effectively differentiates it from sibling tools like 'get_buildings' (likely lists all) and 'get_building_details' (details for a specific building).
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 when searching by name or number, but it does not explicitly provide guidance on when to use this tool versus alternatives like 'get_buildings' or 'get_building_details', nor does it mention any preconditions or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific events in the academic calendar
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for calendar events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description offers no behavioral details like authentication needs, rate limits, or what happens on no results. The simple verb 'search' implies retrieval but lacks depth.
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?
Single sentence is concise with no wasted words, but it is somewhat terse. Could benefit from slight elaboration without losing brevity.
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?
Description is minimal for a search tool with no output schema. It does not explain return format, result limits, or how this differs from sibling event tools. Missing context for agent to use 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 coverage is 100% for the single parameter 'query', which already describes it as 'Search term for calendar events'. The tool description adds no further meaning, so 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 'Search for specific events in the academic calendar,' specifying a verb and resource. It distinguishes from sibling tools like 'search_campus_events' by narrowing to the 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?
No guidance on when to use this tool versus alternatives such as 'get_academic_calendar' or 'search_campus_events'. Does not specify exclusions or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for campus events by title or description
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for event title or description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, authentication requirements, or pagination. The term 'search' implies read-only but is not explicitly stated.
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?
A single, front-loaded sentence that contains no wasted words. Every part of the description contributes to understanding the tool's 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?
For a simple search tool with one parameter, the description is adequate but lacks context about return format, pagination, or how to use it alongside sibling tools like get_campus_events or get_events_by_date_range. Given the absence of output schema, more completeness would be beneficial.
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 'query' parameter, and the description adds no additional meaning beyond what the schema provides ('Search term for event title or description'). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches campus events by title or description, distinguishing it from sibling tools like get_campus_events (lists all events) or get_events_by_tag (filtered by tag). Verb 'search' and resource 'campus events' are specific.
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 versus alternatives such as get_events_by_date_range or get_events_by_location. The description implies usage for text-based search but does not provide explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for OSU classes by keyword, subject, instructor, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| term | No | Term code (e.g. 1162 for Spring 2016, 1164 for Summer 2016, 1168 for Autumn 2016) | |
| query | Yes | Search query - can be course title, subject, instructor name, building, etc. | |
| campus | No | Campus code (e.g. COL for Columbus, LMA for Lima) | |
| subject | No | Subject code (e.g. CSE, MATH, ENGR) | |
| component | No | Class component type | |
| catalog_number | No | Catalog number range (e.g. 1xxx, 2xxx, 3xxx, 4xxx, 5xxx+) | |
| academic_career | No | Academic career level | |
| academic_program | No | Academic program code (e.g. ENG, ASC, AGR) | |
| instruction_mode | No | Instruction mode |
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 'Search for OSU classes', implying a read-only operation but fails to mention pagination, result format, default behavior (e.g., current term), or any rate limits. This is inadequate for a tool with 10 parameters.
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 very concise (one sentence) and front-loaded with the core purpose. However, it is structurally flat and lacks any separation of usage notes, which limits its utility for an agent.
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 high parameter count (10) and no output schema, the description should elaborate on search semantics (e.g., logical OR, wildcards), term code format, and result set size. It provides none of this, leaving the agent underinformed.
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 the baseline is 3. The description adds no additional meaning beyond the schema; 'by keyword, subject, instructor, etc.' is a high-level summary that doesn't explain parameter interplay or typical use patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Search for OSU classes' with a clear verb-resource pair. It mentions several search dimensions (keyword, subject, instructor), but the trailing 'etc.' is vague, reducing precision. Still, the core purpose is obvious.
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 provided on when to use this tool versus alternatives. There are no sibling tools for classes, so confusion is unlikely, but the description doesn't clarify scope (e.g., current vs. all terms) or state that it returns a list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for food trucks by name or cuisine type
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for food truck name or cuisine type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as auth requirements, rate limits, or how results are ordered. For a search tool, missing defaults like pagination limits or empty result 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 a single, efficient sentence with no redundant information. It is front-loaded with the action and resource.
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 provides essential information. However, it lacks context about how results are filtered or what fields are returned, and does not differentiate from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, and the description of the 'query' parameter is adequately described in the schema. The description adds no additional meaning beyond the schema, earning a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for food trucks, specifying the criteria (name or cuisine type). It is a specific verb-resource pair. However, it could be improved by noting what information is returned (e.g., locations, schedules).
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 given on when to use this tool versus related siblings like 'get_foodtrucks_by_location' or 'get_foodtruck_events'. The description does not mention any prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for library locations by name
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for library name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it returns partial matches, pagination, or limits. The agent has no information beyond the minimal purpose.
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, concise and front-loaded. However, it is too minimal, missing valuable information, so not a perfect 5.
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?
With no output schema and only one parameter, the description does not explain what the tool returns (e.g., names, details, or objects). It is incomplete for an agent to effectively use.
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 one parameter already described. The description adds no additional meaning beyond the schema, so 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 searches for library locations by name, using a specific verb ('Search') and resource ('library locations'), and it distinguishes from 'get_library_locations' which likely lists all.
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 versus alternatives like 'get_library_locations' or 'search_library_rooms'. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for library study rooms by name or location
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for room name or location |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not mention read-only nature, results format, pagination, or authorization needs. Bare minimum.
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?
Single sentence, no wasted words, verb-first. However, it could be slightly more informative without sacrificing 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 1-param tool with no output schema or annotations, the description fails to specify what is returned (e.g., list of rooms with details), limits, or overlapping tool boundaries.
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 already describes the 'query' parameter as 'Search term for room name or location' with 100% coverage. The tool description adds no new semantic value beyond confirming 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 action ('Search'), the resource ('library study rooms'), and the criteria ('by name or location'), distinguishing it from sibling tools like get_library_rooms and search_library_locations.
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 versus alternatives (e.g., get_library_rooms or search_library_locations). Implies use for name/location queries but no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for merchants by name or category
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for merchant name or category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks behavioral details such as read-only nature, number of results, pagination, or search algorithm (exact vs fuzzy). Minimal 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?
Single sentence, no fluff. Efficient but could be slightly more detailed without losing 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 search tool with no output schema or annotations, the description should explain behavior (e.g., result format, limits, search type). It is incomplete.
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 only parameter 'query' is described in the schema. The tool description adds no additional meaning beyond what is already in the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for merchants by name or category, with a specific verb and resource. It distinguishes from sibling tools like get_merchants_by_food_type and get_buckid_merchants.
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 versus alternatives. No mention of when not to use or context for preferring search_merchants over other merchant-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for people in the OSU directory by first and/or last name
| Name | Required | Description | Default |
|---|---|---|---|
| lastname | No | Last name to search for | |
| firstname | No | First name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only search but does not disclose behaviors like authentication, rate limits, or response format.
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?
Single sentence, 12 words, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search with two optional params; lacks details on output but no expected complexity.
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%; description restates parameter names without adding additional format or usage hints.
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 verb 'Search', resource 'people', scope 'OSU directory', and search fields. Distinct from 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?
Explicitly says when to use (searching people by name) but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for recreation sports facilities by name or abbreviation
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for facility name or abbreviation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the search action. It does not disclose behavior such as case sensitivity, partial matching, pagination, or result format, leaving the agent with minimal insight into what the tool actually does beyond the name.
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 that efficiently conveys the tool's purpose without waste.
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 one parameter and no output schema, the description covers the basic purpose but omits important context like what constitutes a match and how results are presented.
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 description adds no new meaning beyond the schema's description of the query parameter, achieving baseline but no 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 searches for recreation sports facilities by name or abbreviation, distinguishing it from sibling tools like get_recsports_facilities (which likely lists all facilities).
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 when you have a name or abbreviation, but does not explicitly compare to alternatives like get_recsports_facilities or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific sports or teams
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for sport name or team |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the tool searches, but does not disclose any behavioral traits like result format, pagination, or side effects.
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 short sentence, front-loaded with the purpose. It is concise with no unnecessary words, but it is so brief it may be considered under-specified.
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 tool with one parameter and no output schema, the description is minimally adequate. It does not explain return values or how results are structured, which would be helpful.
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 100% coverage for the single parameter, so baseline is 3. The description adds no extra meaning beyond the schema's description of 'Search term for sport name or team'.
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 searches for specific sports or teams, which is a specific verb-resource combination. However, it does not differentiate from sibling tools like get_athletics_all or get_sport_by_gender.
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. There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for student organizations by name or keywords
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for organization name or keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose search behavior (fuzzy matching, partial matches, case sensitivity), pagination, or any side effects. The description is minimal.
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, which is concise but lacks structure. It could be improved by front-loading key details, but it is not 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?
Given the tool's simplicity (one required parameter, no output schema), the description is insufficient. It does not explain search behavior, result limits, or any edge cases, leaving the agent with ambiguity.
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 'query' already has a description. The tool description adds no additional semantic value beyond what the schema provides.
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 searches for student organizations by name or keywords, which distinguishes it from sibling 'get' tools that list all or filter by type/career level. However, it could be more explicit about the difference.
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 vs alternatives like get_student_organizations or get_orgs_by_type. The description only states the action, without context for choosing it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are grouped into clear domains (dining, athletics, bus, buildings, etc.) with specific functions, but some overlap exists (e.g., get_dining_locations vs get_dining_locations_with_menus) and multiple search tools could be confusing.
Most tools follow a consistent verb_noun pattern with underscores, such as get_bus_routes and search_buildings. However, a few deviate (e.g., get_athletics_all, get_sport_by_gender), slightly reducing consistency.
With 49 tools covering diverse university domains, the count is heavy but justifiable for a comprehensive campus information server. The breadth ensures coverage but may overwhelm agents.
The tool set covers major OSU services (dining, athletics, transportation, buildings, events, library, etc.) thoroughly for a read-only informational server. Minor gaps exist, such as missing enrollment or financial aid tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
News, web search, mail, markets, weather, places, files, calendar, contacts. 67 tools, one endpoint.
One connector URL giving any MCP client live access to 21 services and 51 tools.
Access all your MCPBundles tools in one place. Unified hub for all enabled bundles.
Track expenses, budgets, balances, transfers, and multi-currency reports with OAuth-secured tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sichengchen/ohio-state-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
