IIITH Mess MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between cancellation-related tools (e.g., mess_cancel_registration, mess_get_cancellations_count, mess_get_cancellation_window) and registration tools (e.g., mess_create_registration, mess_get_registration, mess_get_registrations), which could cause minor confusion. However, descriptions are clear enough to differentiate them in most cases.
Naming Consistency5/5
All tools follow a consistent 'mess_verb_noun' naming pattern with snake_case throughout, such as mess_create_registration and mess_get_auth_keys. This uniformity makes the tool set predictable and easy to navigate.
Tool Count2/5
With 45 tools, the count is excessive for a mess management system, making it cumbersome for agents to navigate. A more focused set of 10-20 tools would better cover the domain without overwhelming complexity.
Completeness5/5
The tool set provides comprehensive coverage for mess operations, including registration, cancellation, billing, authentication, preferences, and feedback. It supports full CRUD and lifecycle management with no apparent gaps for the domain.
Average 3.9/5 across 45 of 45 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying the return type ('JSON integer count'), but doesn't mention error conditions, rate limits, or authentication requirements beyond what's in the schema. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a purpose statement followed by 'Args:' and 'Returns:' sections. However, the 'Args:' section is overly brief and could be more informative without losing conciseness. There's no wasted text, but it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter with nested properties), rich annotations, and presence of an output schema, the description is minimally adequate. It states the purpose and return type, but lacks details on parameter usage, error handling, and integration with sibling tools. The output schema likely covers return values, reducing the burden, but more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for parameter documentation. It lists parameters ('auth_key/session, meal (required), optional month, optional year') but provides no details on formats, constraints, or interactions. For example, it doesn't explain that 'auth_key' and 'session' are alternatives or that 'meal' is an enum. This is insufficient given the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get count of cancelled registrations for a meal in a month.' It specifies the verb ('Get count'), resource ('cancelled registrations'), and scope ('for a meal in a month'). However, it doesn't explicitly differentiate from sibling tools like 'mess_get_cancellation_window' or 'mess_get_registrations', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mess_get_registrations' (which might list registrations) or 'mess_get_cancellation_window' (which might provide cancellation rules). There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal context beyond this, such as the return type ('JSON integer'), but doesn't disclose additional traits like error conditions, rate limits, or authentication requirements. Since annotations cover the safety profile adequately, a score of 3 reflects some added value without rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first, followed by brief sections for Args and Returns. It avoids unnecessary elaboration, though the 'Args' section could be more structured (e.g., bullet points). Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, read-only, idempotent) and the presence of annotations and an output schema, the description is somewhat complete. It covers the basic purpose and parameters, but lacks usage guidelines and detailed parameter explanations. With annotations handling safety and an output schema implied, it's adequate but has clear gaps in guidance and semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning parameter details are undocumented in the schema. The description lists 'params: auth_key/session, meal (required)', which adds basic semantics by naming the parameters and indicating 'meal' is required. However, it doesn't explain the relationship between auth_key and session (e.g., that one is needed for authentication), the format of 'meal', or other nuances, failing to fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the maximum free cancellations allowed per month for a meal.' It specifies the verb ('Get'), resource ('maximum free cancellations'), and scope ('per month for a meal'). However, it doesn't explicitly differentiate from sibling tools like 'mess_get_cancellations_count' or 'mess_get_cancellation_window', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mess_get_cancellations_count' (which might get current cancellations) or 'mess_get_cancellation_window' (which might get time constraints), nor does it specify prerequisites or contextual usage scenarios. This lack of comparative guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying the return type ('JSON integer (seconds)'), but doesn't elaborate on what the skip window represents, potential errors, or rate limits. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by Args and Returns sections. However, the Args section is overly terse ('params: auth_key or session') and could be more informative without sacrificing conciseness. Overall, it's efficient but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and rich annotations, the description is minimally adequate. It specifies the return type, but with an output schema present, this isn't strictly necessary. It fails to explain the skip window's purpose or relation to other tools, leaving contextual gaps despite the structured data support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing full burden on the description to explain parameters. The description mentions 'params: auth_key or session' but lacks details on their semantics, optionality, or how they affect the operation. It doesn't clarify if both can be used together or if one is preferred, leaving significant gaps beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the skip window time in seconds.' It uses a specific verb ('Get') and identifies the resource ('skip window time'), but it doesn't differentiate from sibling tools like 'mess_get_cancellation_window' or 'mess_get_extras_window' that also retrieve window-related information, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mess_get_all_windows' or 'mess_get_registration_window' that might retrieve similar or overlapping data, nor does it specify prerequisites or contextual triggers for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, covering key behavioral traits. The description adds that it deletes by ID and returns a JSON array of remaining objects, which offers some context beyond annotations (e.g., output format and effect on data). However, it doesn't detail permissions, rate limits, or error conditions. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by Args and Returns sections in a structured format. It avoids unnecessary words, but the Args section could be more integrated (e.g., merging with the first sentence). Overall, it's efficient with minimal waste, though not perfectly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with 0% schema coverage and an output schema (implied by 'Returns'), the description is moderately complete. It covers the action, parameters at a high level, and return value, but lacks details on authentication nuances, error handling, or sibling differentiation. The output schema likely documents the JSON array structure, reducing the burden, but gaps remain for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists params as 'auth_key/session, id' and notes the ID is for the extra registration, adding basic semantics beyond the schema's property names. However, it doesn't explain the relationship between auth_key and session (e.g., alternatives), format of ID, or other nuances. With 0% coverage, this partial compensation justifies a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('an extra registration by its ID'), making the purpose unambiguous. It distinguishes from siblings like 'mess_cancel_registration' or 'mess_delete_monthly_registration' by specifying 'extra registration', though it doesn't explicitly contrast with them. The title is null, so the description carries the full burden, which it does adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'mess_cancel_registration' or 'mess_delete_monthly_registration'. It mentions the ID is passed as a query param, but this is a technical detail rather than usage context. There are no prerequisites, exclusions, or comparisons to sibling tools, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds value by disclosing error behavior ('Returns 401/403 if the key is expired') and clarifying the auth key source ('passed in Authorization header'), which isn't in annotations. However, it doesn't detail rate limits, permissions, or other behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The 'Args' and 'Returns' sections are structured but could be more integrated. It avoids unnecessary fluff, though the parameter section is brief and could be clearer. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), rich annotations (covering safety and idempotency), and the presence of an output schema (implied by 'Returns: JSON AuthKey details'), the description is mostly complete. It explains the purpose, parameter semantics, and error behavior, though it lacks usage guidelines and full parameter coverage. For this context, it's adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'params: auth_key (the key to inspect)', which adds meaning by specifying the parameter's purpose. However, it doesn't cover the full input schema (which includes 'session' as an optional property in AuthInput) or explain the structure of 'params', leaving gaps. The baseline is 3 due to partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get info about the auth key currently in use (passed in Authorization header).' It specifies the verb ('Get info') and resource ('auth key'), though it doesn't explicitly differentiate from sibling tools like 'mess_get_auth_keys' or 'mess_create_auth_key'. The description is clear but lacks sibling differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mess_get_auth_keys' (which likely lists multiple keys) or 'mess_create_auth_key', nor does it specify prerequisites or contexts for usage. The only implicit guidance is the parameter description, which is insufficient for explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the agent knows this is a safe, repeatable read operation. The description adds that it returns 'JSON integer (seconds)', which provides useful context about the return format, but doesn't mention authentication requirements, rate limits, or other behavioral details beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and uses only three sentences. It's appropriately sized for a simple getter tool, though the 'Args' and 'Returns' labels are slightly redundant given the structured schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, annotations covering safety, output schema likely defining the integer return), the description is reasonably complete. It explains what the tool does, the parameter's purpose, and the return format. For a straightforward read operation, this provides adequate context without over-explaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args' section documents that 'params' accepts 'auth_key or session'. This adds meaningful semantics beyond the schema, explaining the purpose of the single parameter. However, it doesn't fully detail the AuthInput structure or usage nuances, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the cancellation window time in seconds.' It uses a specific verb ('Get') and resource ('cancellation window time'), but doesn't explicitly differentiate from sibling tools like 'mess_get_cancellations_count' or 'mess_get_skip_window' which might retrieve related but different information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context, or relationship to sibling tools like 'mess_cancel_registration' or 'mess_get_all_windows'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds that it returns 'JSON integer (seconds)', which provides output format context not in annotations. However, it doesn't disclose rate limits, error conditions, or authentication behavior beyond what's implied by parameters. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three clear sections: purpose, arguments, and returns. Each sentence adds value without redundancy. However, the 'Args' and 'Returns' sections could be integrated more smoothly, and there's minor verbosity in repeating 'params'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and rich annotations, the description is reasonably complete. It explains the purpose, parameters, and return value. The output schema exists, so the description doesn't need to detail return values further. However, it lacks context on authentication flow or error handling, which could be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states 'Args: params: auth_key or session', which clarifies that 'params' accepts authentication credentials. This adds meaning beyond the schema's property names. However, it doesn't explain the relationship between auth_key and session (e.g., if one is required, or if they're alternatives), leaving some ambiguity. With 0% coverage, this partial compensation warrants a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the feedback window time in seconds (time after a meal to submit feedback).' It specifies the verb 'Get' and the resource 'feedback window time', making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'mess_get_cancellation_window' or 'mess_get_skip_window', which have similar naming patterns but different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication requirements), timing considerations (e.g., when the feedback window applies), or related tools like 'mess_provide_feedback'. The only contextual clue is the parameter description, but this isn't explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), indicating a safe, non-destructive, repeatable operation. The description adds minimal context by specifying it returns a 'JSON User object' with listed fields, but doesn't disclose additional traits like error conditions, rate limits, or authentication requirements beyond what's implied by the params. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by Args and Returns sections. It's concise with no wasted words, though the Returns section could be slightly more efficient by integrating with the output schema. Overall, it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), rich annotations covering safety and idempotency, and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the purpose, parameters, and return structure, though it lacks usage guidelines and deeper behavioral context, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section that explains 'params: auth_key or session', adding meaning beyond the bare schema. However, it doesn't detail the semantics of these options (e.g., when to use auth_key vs. session, or that they're mutually exclusive), and the schema's definitions provide more detail (e.g., env var usage). This partial compensation justifies a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the currently logged-in user's profile.' It specifies the verb ('Get') and resource ('currently logged-in user's profile'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'mess_get_info' or 'mess_get_auth_key_info', which might also retrieve user-related information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication state), exclusions, or compare it to siblings like 'mess_get_info'. This lack of context leaves the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a safe, read-only, idempotent, and open-world operation (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true). The description adds minimal behavioral context by specifying it returns 'JSON array of ExtraRegistration objects', but does not detail aspects like error handling, rate limits, or authentication needs beyond the schema. With annotations covering core traits, the description adds some value but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose statement followed by 'Args:' and 'Returns:' sections, making it easy to parse. It is concise with no wasted sentences, though the parameter listing could be more integrated into the main text. The front-loaded purpose statement earns its place, but minor improvements in flow could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only query with authentication), annotations provide safety and idempotency info, and an output schema exists (implied by 'Returns: JSON array of ExtraRegistration objects'), the description is reasonably complete. It covers purpose, parameters, and return format, though it lacks usage guidelines and detailed behavioral context. The presence of annotations and output schema reduces the burden on the description, making it adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description compensates by listing parameters ('auth_key/session, meal (required), optional date (YYYY-MM-DD)') and clarifying that 'date' defaults to today. However, it does not fully explain parameter semantics, such as the relationship between 'auth_key' and 'session' or the format of 'meal' values. This partial compensation results in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get extra item registrations for the current user for a meal on a date.' It specifies the verb ('Get'), resource ('extra item registrations'), and scope ('current user', 'meal', 'date'), but does not explicitly differentiate it from sibling tools like 'mess_get_extras_in_range' or 'mess_list_extras', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'mess_get_extras_in_range' or 'mess_list_extras', nor does it specify prerequisites such as authentication requirements beyond what's implied in the parameters. This lack of contextual guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond what annotations provide. Annotations already declare this as read-only, non-destructive, idempotent, and open-world. The description only specifies the return format ('JSON date string (YYYY-MM-DD)'), which is useful but doesn't cover aspects like authentication requirements (implied by params), rate limits, or error conditions. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three clear sections: purpose, arguments, and returns. Each sentence serves a purpose, and there's no redundant information. It could be slightly improved by integrating the argument details more seamlessly, but overall it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of annotations and an output schema, the description is reasonably complete. It covers the core purpose, parameter intent, and return format. However, it lacks context on how this date interacts with other registration tools, which could aid the agent in workflow decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the 'params' argument as 'auth_key or session' and noting the return format. However, it doesn't detail the structure of 'params' (an object with 'auth_key' and 'session' properties) or clarify that only one is needed, leaving gaps compared to the schema's richer definitions. This meets the baseline for partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the maximum future date allowed for meal registration.' It uses a specific verb ('Get') and resource ('maximum future date'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'mess_get_registration_window' or 'mess_get_cancellation_window' that might also return date-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While it's clear this tool retrieves a date limit, there's no mention of related tools like 'mess_get_registration_window' or 'mess_get_cancellations_count' that might be used in similar contexts. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying the return type ('JSON integer (seconds)'), which is useful but doesn't elaborate on rate limits, authentication requirements beyond the schema, or error conditions. It doesn't contradict annotations, so it adds some value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with three clear sections: purpose, args, and returns. Each sentence earns its place by providing essential information without redundancy. It could be slightly improved by integrating the sections more fluidly, but it's efficiently front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, simple return), annotations covering safety, and an output schema (implied by 'Returns: JSON integer (seconds)'), the description is reasonably complete. It specifies the purpose, parameter semantics, and return type, though it lacks usage guidelines and deeper parameter explanations. For this simple read-only tool, it's adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section stating 'params: auth_key or session', which adds basic semantic information about the single parameter. However, it doesn't explain the relationship between auth_key and session (e.g., that one is required, or they are alternatives), and it lacks details on format or usage beyond what's implied. With 0% schema coverage, this partially compensates but remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the registration window time in seconds.' This is a specific verb ('Get') and resource ('registration window time'), though it doesn't explicitly distinguish it from sibling tools like 'mess_get_cancellation_window' or 'mess_get_skip_window' which likely retrieve different window types. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare it to sibling tools such as 'mess_get_cancellation_window' or 'mess_get_all_windows'. Without usage guidelines, the agent must infer when this specific window retrieval is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds that it resets the token (implying mutation) and returns a new token, which aligns with annotations. However, it doesn't disclose behavioral traits like rate limits, authentication requirements beyond the params, or whether this invalidates previous tokens. With annotations covering basic hints, the description adds some context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by structured 'Args' and 'Returns' sections. It's appropriately sized with no wasted sentences, though the 'Args' section could be more integrated into the flow. The structure aids readability but isn't perfectly seamless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (authentication mutation), annotations provide basic hints, and an output schema exists (implied by the Returns section). The description covers purpose, parameters, and return values adequately. However, it lacks context on error cases or side effects, which could be useful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section explaining that 'params' requires 'auth_key or session', which adds meaning beyond the schema's technical definitions. However, it doesn't detail the semantics of these parameters (e.g., when to use one over the other) or other nuances. With 1 parameter and partial compensation, this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reset') and the resource ('user's QR code token'), with additional context about where it's shown ('at the mess counter'). It distinguishes this tool from siblings like mess_get_info or mess_get_me by focusing on token resetting rather than retrieval. However, it doesn't explicitly differentiate from all siblings (e.g., mess_create_auth_key also deals with authentication).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing authentication first), when resetting is appropriate (e.g., token compromise), or what happens to the old token. The sibling list includes many authentication-related tools (e.g., mess_create_auth_key, mess_login_msit), but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by specifying the return structure (JSON UserPreferences with specific fields) and authentication requirements (auth_key or session). It doesn't mention rate limits, error conditions, or data freshness, but provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but has structural issues. The first sentence is clear, but the Args/Returns formatting is inconsistent with typical MCP descriptions. The return field listing is helpful but could be more efficiently integrated. Some redundancy exists between 'Get all user preferences' and the return description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has comprehensive annotations (readOnly, non-destructive, idempotent, openWorld) and an output schema (implied by Returns section), the description provides adequate context. It covers authentication needs and return structure. For a simple read operation with good annotations, this is reasonably complete, though could benefit from error handling or usage scenario details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description mentions 'params: auth_key or session' which maps to the single parameter's structure. However, it doesn't explain the relationship between auth_key and session (mutually exclusive? both required?), nor does it clarify what happens if neither is provided. The schema's AuthInput definition provides more detail than the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'all user preferences', making the purpose explicit. It distinguishes from sibling 'mess_update_preferences' by being a read operation. However, it doesn't specify whose preferences (current user vs others) or differentiate from other get_* tools that might return user data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (authentication state), compare with 'mess_get_me' or 'mess_get_info' which might include preference data, or indicate when this specific tool is needed versus general user info tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior, so the description adds minimal value. It mentions authentication via 'auth_key or session', which is useful context but covered in the schema. No additional behavioral traits like rate limits or error handling are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by Args and Returns sections. It avoids unnecessary details, but the Args section could be more integrated. Overall, it is efficient with minimal waste, though slightly fragmented in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, rich annotations (read-only, etc.), and the presence of an output schema detailing the JSON structure, the description is reasonably complete. It covers authentication needs and return format, though it lacks usage guidelines and deeper parameter insights.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds that 'params' accepts 'auth_key or session', clarifying the authentication requirement. However, it does not explain the structure or usage of these parameters beyond what the schema's AuthInput defines, providing only basic compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'all window times in seconds', listing specific windows (cancellation, registration, feedback, extras, skip). It distinguishes from siblings like mess_get_cancellation_window which retrieves individual windows, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While siblings like mess_get_cancellation_window exist for individual windows, the description does not mention them or specify scenarios for bulk retrieval versus single-window queries, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context (e.g., grouping by category and return format), but does not detail authentication requirements, rate limits, or error handling, which are relevant given the auth_key and session parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured Args and Returns sections. It is efficient with minimal waste, though the Args section could be more integrated into the main text for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and presence of an output schema, the description is mostly complete. It covers the purpose and return format, but lacks details on authentication, error cases, or sibling tool differentiation, which would enhance contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'meal (required)' and 'on (YYYY-MM-DD, optional)', adding basic semantics, but omits details on auth_key and session parameters, their purposes, or default behaviors. The schema provides rich descriptions for all parameters, but the description does not fully bridge the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get mess capacities'), resource ('for a meal on a date'), and scope ('grouped by category'), distinguishing it from sibling tools like mess_get_menus or mess_get_registrations. It precisely communicates the tool's function without redundancy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mess_get_registrations or mess_get_extras_in_range. The description lacks context about prerequisites (e.g., authentication needs) or exclusions, leaving usage unclear beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal context by specifying the return format (JSON with mess_id and meal timings) and the default date behavior, but doesn't disclose additional traits like rate limits, authentication needs, or error handling. With annotations covering core safety and idempotency, a baseline score of 3 is appropriate as the description offers some supplementary value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured into three clear sections: a purpose statement, args explanation, and returns specification. Each sentence earns its place by providing essential information without redundancy. It's front-loaded with the core functionality and uses minimal words to convey necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, read-only operation) and rich annotations (covering safety and idempotency), the description is reasonably complete. It explains the parameter semantics and return format, and with an output schema present, it doesn't need to detail return values further. However, it lacks usage guidelines, which slightly reduces completeness for an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining the single parameter: 'params: optional on (YYYY-MM-DD), defaults to today.' This clarifies the parameter's purpose, format, and default behavior, adding meaningful semantics beyond the schema. Since there's only one parameter and the description fully documents it, a score of 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get meal timings (start/end times) for each mess on a date.' It specifies the verb ('Get'), resource ('meal timings'), and scope ('for each mess on a date'). However, it doesn't explicitly differentiate from sibling tools like 'mess_get_menus' or 'mess_get_info', which might also retrieve mess-related data, so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'mess_get_menus' or 'mess_get_capacities'. The only contextual hint is the default behavior for the date parameter, which is insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds context about authentication (auth_key/session) and default behavior for month/year, which is useful beyond annotations. However, it doesn't detail rate limits, error conditions, or data freshness, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, followed by Args and Returns sections. It's front-loaded with the main functionality. At four sentences, it's efficient, though the Args line could be slightly more polished (e.g., clarifying 'auth_key/session' as alternatives).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations cover safety and idempotency, an output schema exists (implied by Returns statement), and the description adds parameter and return context, it's mostly complete. However, it lacks details on error handling or example outputs, which could help an agent use it correctly in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section that lists parameters: 'auth_key/session, optional month (1-12), optional year'. This adds basic semantics, clarifying authentication options and numeric ranges. However, it doesn't explain the 'params' wrapper object structure or provide examples, leaving gaps compared to the detailed schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the monthly mess registration for the current user. Also returns snack availments for the month.' This specifies the verb ('Get'), resource ('monthly mess registration'), and scope ('current user'), plus an additional return value. It distinguishes from siblings like 'mess_get_registration' or 'mess_get_registrations' by focusing on monthly data for the current user, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description focusing on the current user's monthly registration and snack data, suggesting it's for personal monthly summaries. However, there's no explicit guidance on when to use this versus alternatives like 'mess_get_registration' (which might be for specific dates) or 'mess_get_registrations' (which could be for multiple users). The context of sibling tools hints at alternatives but isn't directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond this: it specifies the output format (JSON array with specific fields), clarifies that bills are in paise with conversion instructions, and notes it only includes non-zero bills. This enhances understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by unit conversion instructions, parameter details, and return format. Every sentence adds value, such as clarifying paise-to-rupees conversion and specifying output fields. It could be slightly more concise by integrating the Args and Returns into a single section, but overall it's efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving historical billing data), the description is fairly complete. It explains the purpose, output format, and unit conversion, and the presence of an output schema means return values don't need elaboration. However, it lacks details on error handling, pagination, or date ranges, which could be relevant for a tool fetching 'all months.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining the 'params' argument as 'auth_key or session' and providing usage context in the Returns section. However, it doesn't detail parameter semantics beyond what's implied by authentication needs. With one parameter and partial compensation, this meets the baseline for adequate but not comprehensive coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get bill breakdown for all months with a non-zero bill.' It specifies the verb ('Get') and resource ('bill breakdown'), and distinguishes it from sibling 'mess_get_bill' by indicating it retrieves all months. However, it doesn't explicitly contrast with other billing-related tools like 'mess_get_extras_in_range' or 'mess_get_registrations' that might involve financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying it retrieves 'all months with a non-zero bill,' suggesting it should be used when comprehensive billing history is needed. However, it doesn't explicitly state when to use this tool versus alternatives like 'mess_get_bill' (which likely retrieves a single bill) or other financial tools. No exclusions or prerequisites are mentioned beyond the authentication requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, open-world), so the description adds minimal value. It specifies the return type ('JSON integer (seconds)'), which is useful but not detailed beyond what the output schema likely provides. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with the purpose stated in the first sentence and parameter/return details in brief bullet points. Every sentence earns its place, avoiding redundancy and maintaining clarity without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, read-only operation) and the presence of annotations and an output schema, the description is mostly complete. It covers the purpose, parameter basics, and return type, though it could benefit from more usage context or sibling differentiation to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining that 'params' accepts 'auth_key or session', clarifying the authentication options. However, it doesn't detail the structure or usage of these parameters beyond the schema's definitions, leaving some gaps in full semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('extra registration window time in seconds'), distinguishing it from siblings like mess_get_registration_window or mess_get_all_windows. It precisely defines what the tool retrieves, avoiding vagueness or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 how it differs from mess_get_registration_window or mess_get_all_windows. The description lacks context, prerequisites, or exclusions, offering only basic functional information without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful behavioral context: it explains that extras with the same ID may appear across multiple meals (a data characteristic not captured in annotations). It doesn't mention authentication requirements, rate limits, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose statement, behavioral note, Args, and Returns sections. It's appropriately sized but could be slightly more concise by integrating the behavioral note into the main purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has comprehensive annotations (read-only, non-destructive, idempotent, open-world) and an output schema (Returns section describes JSON array structure), the description provides adequate context. It covers parameters and basic behavior, though could better explain authentication requirements given the auth_key/session parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section documents all 3 parameters (meal, date, mess ID) with basic semantics. However, it doesn't explain the relationship between auth_key/session parameters (nested in params object) and the tool's authentication behavior, leaving gaps despite the schema having no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List available extra items'), target resource ('for a meal on a date'), and scope ('Some extras may be available across multiple meals'). It distinguishes from siblings like mess_get_extras_in_range (range-based) and mess_get_registered_extras (user-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing extras for a specific meal/date, but doesn't explicitly state when to use this versus alternatives like mess_get_extras_in_range (date range) or mess_get_registered_extras (user's registered extras). No explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, destructive, or idempotent, and it's open-world. The description adds valuable behavioral context beyond annotations: it specifies that feedback is anonymous, mentions authentication requirements ('auth_key/session'), and details error conditions (409 for duplicate feedback, 424 for unavailed meal). This provides practical insights into how the tool behaves in edge cases, though it doesn't cover rate limits or response formats beyond status codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with key information front-loaded: purpose, prerequisites, error cases, parameters, and return value. Each sentence serves a clear purpose, such as stating requirements or outlining inputs. There's minimal redundancy, though it could be slightly more streamlined by integrating parameter details more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with authentication and error handling), the description is fairly complete. It covers purpose, usage conditions, parameters, and return status, and annotations provide safety hints. The output schema exists (implied by 'Returns: JSON status 204'), so return values don't need explanation. However, it lacks details on authentication precedence (auth_key vs. session) or broader system context, leaving minor gaps for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters ('auth_key/session, meal_date, meal_type, rating (1-5), optional remarks') and adds semantic details like rating range and optionality. However, it doesn't fully explain parameter interactions (e.g., auth_key vs. session) or formats (e.g., date format YYYY-MM-DD is only in schema). The description adds some value but leaves gaps compared to the schema's detailed property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Submit anonymous feedback for a meal.' It specifies the verb ('submit'), resource ('feedback'), and context ('for a meal'), which is clear and actionable. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'mess_get_meal_rating' or 'mess_get_feedback_window', which might be related to feedback retrieval rather than submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'User must have availed the meal.' This sets a prerequisite condition. It also mentions error cases (409 and 424), which indirectly guides when not to use it. However, it doesn't explicitly name alternatives or compare with sibling tools, such as when to use this versus other feedback-related tools in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context: it specifies that expired keys are included (behavioral detail) and mentions authentication alternatives (auth_key from mess_create_auth_key or session from mess_login_msit), which helps the agent understand prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and uses bullet-like formatting. It's appropriately sized, but the Args section could be more concise by integrating with the purpose statement rather than being separate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only operation), rich annotations, and the presence of an output schema (implied by Returns section), the description is complete. It covers purpose, parameters, return values, and includes behavioral context like including expired keys, which is sufficient for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section documents the single 'params' parameter with its two possible fields (auth_key, session). However, it doesn't add meaning beyond what the schema already provides in its property descriptions (e.g., auth_key from mess_create_auth_key, session from mess_login_msit). The description compensates partially but not fully for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('all auth keys for the current user'), specifying scope ('including expired ones'). It distinguishes from sibling tools like mess_get_auth_key_info (which gets info for a specific key) and mess_create_auth_key/mess_delete_auth_key (which modify keys).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving authentication keys, but provides no explicit guidance on when to use this tool versus alternatives like mess_get_auth_key_info or mess_get_me. It mentions the parameter options but doesn't explain when to choose auth_key versus session authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: 'No authentication required' clarifies access requirements, and the return format details ('JSON { meal, mess, date, total: int, recent: int (last 10 min) }') provide behavioral insight not in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, authentication note, parameter list, and return format. It's front-loaded and efficient, though the 'Args:' and 'Returns:' sections could be integrated more seamlessly. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter object), rich annotations covering safety and idempotency, and the presence of an output schema (implied by 'Returns:' details), the description is complete. It provides purpose, authentication context, parameter guidance, and return format, leaving no significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing parameters (meal, mess, optional date) and providing format details ('YYYY-MM-DD'). However, it doesn't fully explain semantics like 'mess ID' examples beyond 'yuktahar' or meal enum values. With 0% schema coverage, the description adds meaningful but incomplete parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get meal availment (scan) count'), resource ('for a mess on a date'), and scope ('No authentication required'). It distinguishes itself from sibling tools like 'mess_get_cancellations_count' or 'mess_get_capacities' by focusing on scan counts rather than cancellations, capacities, or other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'No authentication required' and the parameter details, but doesn't explicitly state when to use this tool versus alternatives like 'mess_get_cancellations_count' or 'mess_get_registrations'. It provides basic parameter guidance but lacks explicit comparisons or exclusions for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the financial implication ('still charged') and the prerequisite condition ('out of free cancellations'). While annotations cover idempotency and non-destructive nature, the description provides practical usage context that helps the agent understand when and why to use this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with purpose first, usage guidance second, and technical details last. Each sentence earns its place, though the parameter listing could be more concise since it duplicates schema information without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (state-changing operation with financial implications), the description provides good context about when to use it and what it does. With annotations covering safety aspects and an output schema existing, the description focuses appropriately on usage guidance rather than repeating structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a parameter list but adds no meaningful semantics beyond what's already in the schema. With 0% schema description coverage, the description should compensate by explaining parameter relationships or usage patterns, but it merely lists names without context. The schema already documents each parameter thoroughly with descriptions and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Mark a registration as skipped or unskipped') and resource ('MealRegistration'), distinguishing it from siblings like mess_cancel_registration by explaining skipping vs cancellation (user still charged). It provides a precise verb+resource+scope combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use when out of free cancellations') and distinguishes it from cancellation by explaining 'Skipping = user likely won't attend but is still charged.' This provides clear context for choosing between skip and cancel operations among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies the 424 error condition when the registration wasn't cancelled, and mentions the 204 success status. Annotations already cover idempotency (idempotentHint: true) and non-destructive nature, but the description provides concrete error/success details that enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: purpose statement first, error condition second, parameter list third, return value fourth. Every sentence earns its place with zero wasted words, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature (readOnlyHint: false), the description covers the core purpose, error condition, and success response adequately. However, with 0% schema description coverage and no explanation of parameter semantics, there are significant gaps in understanding how to properly invoke this tool despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries full burden for parameter documentation. It only lists parameter names ('auth_key/session, meal_date, meal_type') without explaining their semantics, formats, or relationships. This minimal information doesn't adequately compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Restore a previously cancelled meal registration') with the resource ('meal registration') and distinguishes it from its sibling 'mess_cancel_registration' by being the inverse operation. It's specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to restore a cancelled registration) and implicitly contrasts with 'mess_cancel_registration' as the opposite action. However, it doesn't explicitly mention when NOT to use it or provide alternative tools for similar scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds valuable context beyond annotations: it specifies that the key value is returned only once ('save this, it won't be shown again'), mentions a 409 conflict error for duplicate names, and notes the uniqueness requirement. This enhances transparency about side effects and error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses bullet-like formatting. It avoids redundancy, but could be slightly more concise by integrating the uniqueness note into the args section rather than as a separate preamble sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation with side effects), lack of schema descriptions, and presence of an output schema (implied by 'Returns'), the description is reasonably complete. It covers purpose, parameters, return behavior, and error cases, though it could improve by mentioning authentication needs or rate limits to fully prepare the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by listing parameters (auth_key/session, name, expiry) and adding semantic details: name must be unique, expiry format is YYYY-MM-DD, and auth_key/session are alternatives. This provides meaningful context beyond the bare schema, though it doesn't fully explain all parameter nuances like defaults or env var usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new API auth key') and resource ('auth key'), with explicit differentiation from sibling tools like mess_get_auth_keys (read) and mess_delete_auth_key (delete). The mention of unique naming further distinguishes its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new auth key is needed, with a constraint that 'Key names must be unique' and a 409 error if duplicated. However, it lacks explicit guidance on when to use this versus alternatives like mess_get_auth_keys or mess_delete_auth_key, or prerequisites such as authentication requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide hints (destructive=true, idempotent=true, openWorld=true, readOnly=false), and the description adds valuable context: it specifies deletion is by name, returns JSON status 204 on success, and mentions auth via 'auth_key/session.' This clarifies the destructive nature and success behavior beyond annotations, though it doesn't detail error cases or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by structured Args and Returns sections. It's efficient with minimal waste, though the Args section could be slightly more concise by integrating details into the main text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with auth), annotations cover safety hints, and the description adds key behavioral details (deletion by name, success response). With an output schema likely handling return values, it's mostly complete, but could improve by mentioning idempotency or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates partially: it explains 'params: auth_key/session for auth, name = the friendly name of the key to delete,' covering the three parameters. However, it doesn't add deep semantics like format constraints or examples beyond what's implied, and the schema already defines properties well, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete an auth key by its name') and resource ('auth key'), distinguishing it from sibling tools like 'mess_get_auth_keys' (read) and 'mess_create_auth_key' (create). It explicitly notes deletion is 'by its name (not its value)' and 'Identified by name in the URL path,' providing precise operational context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to delete an auth key by name, with context from sibling tools suggesting alternatives: use 'mess_get_auth_keys' to list keys first or 'mess_create_auth_key' to create one. However, it lacks explicit when-not-to-use guidance or prerequisites beyond the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent, open-world operation. The description adds valuable context: it specifies the return format (JSON with category arrays containing mess, day, rate), clarifies that rates are in paise, and mentions grouping by category. This goes beyond annotations by detailing output structure and units, though it doesn't cover authentication requirements (handled in schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, category listing, parameter documentation, and return format—all in four concise lines. Every sentence adds value: the first states what the tool does, the second lists categories, the third documents parameters, and the fourth specifies the return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving structured data), rich annotations (covering safety and behavior), and presence of an output schema (implied by 'Returns' statement), the description is mostly complete. It explains the purpose, parameters, and output format. The main gap is missing documentation for auth_key and session parameters, which are in the schema but not mentioned in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It documents two parameters: 'meal (required)' and 'on (YYYY-MM-DD, optional)', adding format details for the date. However, it omits the 'auth_key' and 'session' parameters from the schema, leaving them undocumented. The description compensates partially but not completely for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get mess rates (in paise) for a meal on a date, grouped by category.' It specifies the verb ('Get'), resource ('mess rates'), units ('in paise'), grouping ('by category'), and lists the four categories. This distinguishes it from sibling tools like mess_get_menus or mess_get_capacities that retrieve different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying what data is retrieved (rates for a meal/date) and the categories, but doesn't explicitly state when to use this tool versus alternatives. For example, it doesn't contrast with mess_get_bill or mess_get_all_bills which might provide billing information. The guidance is functional but lacks explicit comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint. The description adds valuable behavioral context beyond annotations: it discloses that successful login returns a session cookie value in 'session_hint' that must be passed in subsequent calls, which is critical usage information not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, Args, and Returns. It's appropriately sized with no wasted sentences, though the Returns section could be slightly more concise by integrating the session hint explanation into the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is an authentication tool with 1 complex parameter object, no output schema provided in context signals, and annotations covering basic behavioral hints, the description is complete: it explains the purpose, parameters, return format, and critical session management requirement for subsequent calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description's Args section documents both parameters (user as 'email address' and password as 'plaintext'), providing basic semantics. However, it doesn't add format details beyond what's already in the schema's property descriptions (e.g., email format example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Login as an MSIT student or intern') using specific credentials ('email + password'). It distinguishes this authentication tool from sibling tools like 'mess_cas_login_info' or 'mess_get_me' by focusing on credential-based login rather than info retrieval or other authentication methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Login as an MSIT student or intern'), but doesn't explicitly state when not to use it or mention alternatives like 'mess_cas_login_info'. It implies this is the primary credential-based login method for MSIT users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint. The description adds valuable behavioral context beyond annotations: it specifies error conditions (409 if already registered, 403 if window closed or mess full) and mentions the return type (JSON MonthlyRegistration object). This provides practical usage insights not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three focused sentences: purpose, error conditions, and parameters/returns. Each sentence adds essential information without redundancy, and it is front-loaded with the core functionality. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with multiple parameters and error conditions), the description is complete: it states the purpose, error behaviors, parameters, and return type. With annotations covering safety hints and an output schema implied by the return statement, no critical gaps remain for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description's 'Args' section lists and briefly explains all parameters (auth_key/session, month, year, mess), adding meaning beyond the bare schema. However, it does not fully compensate for the lack of schema descriptions (e.g., no details on auth_key vs. session usage or mess ID format), keeping it at baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Register at a mess for an entire month') with the resource ('mess') and scope ('entire month'), distinguishing it from sibling tools like 'mess_create_registration' (likely for single meals) and 'mess_create_extra_registration' (for extras). It uses precise verbs and defines the exact temporal scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for monthly registration) and implicitly distinguishes it from other registration tools by specifying the 'entire month' scope. However, it does not explicitly name alternatives or state when not to use it (e.g., for single-day registrations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations already indicate this is destructive (destructiveHint: true) and idempotent (idempotentHint: true), the description adds specific information about the 403 error condition for closed windows and clarifies that individual meal registrations are preserved. This provides practical usage guidance that annotations alone don't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely efficient and well-structured. It opens with the core purpose, adds important behavioral context in parentheses, states a critical error condition, then lists parameters and return values in a clean format. Every sentence serves a clear purpose with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (annotations show destructiveHint: true), the description provides excellent completeness. It explains what gets deleted versus preserved, mentions a key error condition, and documents both parameters and return values. With an output schema present, it doesn't need to explain return values in detail, making this description appropriately complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of parameter documentation. It mentions the parameters (auth_key/session, month, year) but provides minimal semantic context. The schema already documents these parameters thoroughly with descriptions, ranges, and requirements, so the description adds only basic parameter awareness without significant additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete a monthly mess registration') and distinguishes it from sibling tools by specifying that individual meal registrations are kept. This differentiates it from tools like 'mess_cancel_registration' or 'mess_delete_extra_registration' which handle different types of deletions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for deleting monthly registrations while keeping individual meals) and mentions a specific error condition (403 if window closed). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for different deletion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the currency conversion (paise to rupees), mentions that bills may include projected future meals, and specifies the 404 error condition. While annotations cover read-only/non-destructive/idempotent/open-world properties, the description provides practical implementation details that help the agent use the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by important implementation details (currency conversion, projected meals, error conditions), then parameter and return value information. Every sentence adds value with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and the presence of an output schema, the description is complete. It covers purpose, usage context, behavioral details, parameter overview, and return format explanation. The output schema handles the detailed return structure, so the description appropriately focuses on semantic interpretation (paise to rupees conversion).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal parameter information. It mentions 'auth_key/session, optional month, optional year' but doesn't explain the relationship between auth_key and session, or provide format details. The schema itself has good descriptions for each parameter, so the baseline of 3 is appropriate as the description adds some but not comprehensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the user's mess bill for a month' with specific examples of when to use it ('how much do I owe?', 'what's my bill?'). It distinguishes from sibling tools like 'mess_get_all_bills' by specifying it's for a single user's bill for a specific month.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (answering billing questions) and mentions a specific error condition (404 if registrations haven't opened). However, it doesn't explicitly state when NOT to use it or name alternatives like 'mess_get_all_bills' for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: the 'max 2 months' constraint on date range and the inclusive nature of dates. It also hints at authentication options (auth_key/session) though this is covered in schema. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose statement, parameter list, and return format. Each sentence earns its place by providing essential information without redundancy. The front-loaded purpose statement is clear, and the bullet-style parameter listing enhances readability while maintaining brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only list operation with date filtering), rich annotations (covering safety and idempotency), and the presence of an output schema (implied by 'Returns: JSON array of ExtraRegistration objects'), the description is complete. It covers purpose, constraints, parameters, and return type, leaving no significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing parameters (auth_key/session, from, to) and specifying date formats (YYYY-MM-DD). However, it does not fully explain parameter semantics beyond what's implied (e.g., auth_key vs session choice, date constraints). With 0% schema coverage, the description adds some value but leaves gaps, meeting the baseline for partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all extra registrations') with precise resource scope ('in a date range') and distinguishes from siblings like 'mess_get_registered_extras' or 'mess_list_extras' by specifying the date-range filtering. The verb 'Get' combined with the resource 'extra registrations' and constraint 'in a date range' provides unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('in a date range') and includes an important constraint ('max 2 months, both inclusive'), but does not explicitly state when not to use it or name alternative tools for different scenarios (e.g., 'mess_get_registered_extras' for current registrations). The constraint helps guide usage but lacks explicit comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a safe, read-only operation (readOnlyHint: true, destructiveHint: false), but the description adds valuable behavioral context: the 2-month range limit, inclusive date handling, and that it returns a JSON array of specific MealRegistration objects. This goes beyond what annotations provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose first, usage examples, constraints, then parameter and return details. Every sentence adds value with zero redundancy, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (covering safety and idempotency), and the presence of an output schema (detailed in the Returns section), the description provides complete context. It explains what the tool does, when to use it, constraints, parameters, and return format without needing to duplicate structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the schema provides no parameter documentation. The description compensates by listing the three parameters (auth_key/session, from, to) and clarifying date format (YYYY-MM-DD) and inclusivity, but doesn't explain the auth_key/session relationship or provide examples. This is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('look up') and resource ('meals the user is registered for'), and distinguishes it from siblings by focusing on retrieving existing registrations rather than creating, updating, or canceling them. The example questions further clarify the use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to answer questions about what meals are booked) and includes a practical constraint ('Max range: 2 months'), but does not explicitly mention when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies error conditions (403 if cancellation window is closed, 424 if no registration exists) and the success response (JSON status 204). Annotations already indicate destructive (true), idempotent (true), and openWorld (true), but the description provides concrete failure modes and success semantics, enhancing transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by usage guidelines, error conditions, and parameter/return details in a structured format. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with error conditions), the description is mostly complete: it covers purpose, usage, errors, parameters, and returns. Annotations provide safety hints, and there is an output schema (implied by 'Returns'), so the description doesn't need to detail return values. It could improve by explaining idempotency or openWorld implications, but it's largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameters (auth_key/session, meal_date, meal_type) but does not add meaning beyond the input schema, which has 0% description coverage. Since schema coverage is low, the description partially compensates by naming parameters, but lacks details on formats or constraints. With 0% coverage, baseline is lower, but the description provides some param info, warranting a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('cancel') and resource ('meal registration'), and distinguishes it from siblings by focusing on cancellation rather than creation, deletion of other resources, or other operations. It directly explains what the tool does: 'Cancel a meal registration so the user is not charged for it.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use when the user wants to cancel/drop a booked meal.' It distinguishes from alternatives by implying this is for cancellations, unlike sibling tools like mess_create_registration or mess_skip_meal, and mentions specific error conditions (403, 424) that help determine appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, openWorld operation. The description adds valuable context: it specifies a prerequisite (existing regular registration) and immutability constraint ('Cannot be modified'), which are not covered by annotations. However, it doesn't mention potential side effects like rate limits or authentication requirements beyond what's in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by prerequisites, behavioral notes, and structured parameter/return sections. Every sentence earns its place: the first states the action, the second gives a critical constraint, the third explains immutability, and the last two provide essential I/O details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with prerequisites), annotations cover safety aspects, and an output schema exists (so return values needn't be described). The description adds key context like the regular registration prerequisite and immutability. However, it lacks details on error conditions or response structure beyond 'JSON array of ExtraRegistrationInserted objects', leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args' section lists all parameters (auth_key/session, extra, meal_date, meal_type, meal_mess) with brief explanations. This compensates somewhat, but the explanations are minimal (e.g., 'item ID', 'Date YYYY-MM-DD') and don't add deep semantic context beyond what's inferable from names. The baseline is 3 due to the parameter list presence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Register for an extra item on a meal') and resource ('extra item'), distinguishing it from siblings like mess_create_registration (regular registration) and mess_delete_extra_registration (deletion). It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'User must have a regular registration at that mess for that meal' (prerequisite) and 'Cannot be modified — delete and recreate if needed' (alternative action). This clearly indicates when to use this tool versus mess_delete_extra_registration for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond this: it specifies that it 'only returns active (non-cancelled) registrations,' describes default behaviors (date defaults to today, omitted meal returns all meals), and hints at authentication needs via the Args section. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It starts with the core purpose, provides usage examples, adds behavioral notes, and includes Args and Returns sections. Every sentence earns its place, with no wasted words. The front-loaded purpose and examples make it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single-date lookup), rich annotations (covering safety and idempotency), and the presence of an output schema (implied by 'Returns' section), the description is largely complete. It explains the tool's behavior, usage, and parameters adequately. However, it could be slightly more detailed on parameter constraints (e.g., meal options) to compensate for low schema coverage, but overall it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides an Args section listing parameters (auth_key/session, optional meal, optional date) and explains their semantics: meal omission returns all meals, date omission defaults to today, and auth details are noted. However, it doesn't fully document all parameter details (e.g., meal enum values, date format beyond YYYY-MM-DD), leaving some gaps. Baseline 3 is appropriate as it adds meaningful but incomplete context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up the user's registration for a single date (defaults to today).' It specifies the verb ('look up'), resource ('user's registration'), and scope ('single date'), and distinguishes it from siblings like mess_get_registrations (plural) by focusing on a single date. The example questions further clarify the use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: to answer specific questions like 'am I registered for lunch today?' or 'what mess am I going to tonight?'. It also distinguishes it from alternatives by noting it 'only returns active (non-cancelled) registrations,' implying that other tools (e.g., mess_get_registrations) might include cancelled ones. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds value by specifying the return format ('JSON status 204 on success'), which is not covered by annotations. It does not contradict annotations, as 'complete password reset' aligns with the non-read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured sections for arguments and returns. Every sentence adds essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (authentication-related mutation), the description provides complete parameter details, return information, and context. With annotations covering safety aspects and an output schema implied by the return statement, no critical gaps remain for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It effectively lists and explains all three parameters (email, otp, password) with examples and context, such as '6-digit string e.g. '123456'' for OTP and 'new password' for password, compensating well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Complete password reset') and identifies the required resources (OTP + new password). It distinguishes itself from sibling tools like 'mess_generate_reset_password_otp' by focusing on the final step of the reset process rather than initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'OTP received by email,' suggesting this tool should be used after generating an OTP. However, it does not explicitly state when to use it versus alternatives or provide exclusions, such as not using it for initial password creation or without a valid OTP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context by explicitly stating 'No auth required', which isn't covered by annotations. It also specifies the return format ('JSON array of MessInfo objects'), providing behavioral clarity beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose and key details (fields returned, no auth), and the second sentence specifies the return format. Every sentence earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, rich annotations, output schema exists), the description is complete. It covers purpose, authentication context, return format, and distinguishes the tool adequately. With output schema handling return values, no additional explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, and it appropriately focuses on the tool's purpose and output instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'info about all messes', specifying the exact fields returned (name, short_name, color, tags, rating, billing_id). It distinguishes itself from siblings like mess_get_me or mess_get_registration by focusing on comprehensive mess metadata rather than user-specific or registration data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'No auth required', providing clear context about when authentication is unnecessary. However, it doesn't specify when to use this tool versus alternatives like mess_get_menus or mess_get_meal_timings for related information, leaving some sibling differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: the feedback window restriction (403 error), the conditional return format (single object vs. keyed by mess ID), and the default behavior when mess is omitted. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by critical behavioral notes and a structured breakdown of args and returns. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read-only with conditional returns and authentication), the description is complete: it covers purpose, usage constraints, parameter roles, return formats, and error conditions. With annotations handling safety and an output schema presumably detailing the JSON structure, no significant gaps remain for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden for parameter meaning. It effectively explains the semantics: 'auth_key/session' for authentication, 'meal (required)', 'optional mess' with behavior when omitted, and 'optional date' with default to today. This adds significant value beyond the bare schema, though it could detail format constraints like date format more explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the average rating'), target resource ('for a meal at a mess on a date'), and distinguishes from siblings by focusing on rating retrieval rather than registration, feedback, or other operations. It precisely communicates the tool's function without tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to get meal ratings) and includes an important exclusion ('Ratings are only visible after the feedback window closes (403 otherwise)'). However, it doesn't explicitly name alternatives among sibling tools or specify when not to use it beyond the feedback window constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond annotations: it specifies the tool returns 'step-by-step instructions for obtaining a session cookie' and clarifies the browser-only limitation. This provides useful behavioral information about the output format and operational constraints that annotations don't cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured: two brief sentences that each serve distinct purposes. The first sentence states the purpose and key constraints, the second describes the return value. There's zero wasted language, and the most important information (what the tool does) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, comprehensive annotations, and an output schema exists (though not shown), the description provides complete context. It explains what the tool does, its constraints, and what it returns. For a simple informational tool with no inputs, this description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It earns a 4 (not 5) because while it correctly omits parameter discussion, it could theoretically mention that no parameters are needed, though this isn't required for full credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get instructions for IIIT student CAS login' with the specific resource (CAS login instructions) and verb (get). It distinguishes itself from sibling tools like 'mess_login_msit' by specifying it's for obtaining instructions rather than performing login directly, and clarifies it's browser-only and cannot be called via API/AJAX.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it's for obtaining login instructions, specifies it's 'browser-only, cannot be called via API/AJAX' which tells the agent when NOT to use this tool (for automated login), and implies alternatives like 'mess_login_msit' for actual login operations. This gives clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies failure conditions (403 error for closed windows or full mess), mentions optional guests parameter, and describes return values (JSON MealRegistration or 204 if already registered). While annotations cover basic hints (non-readOnly, non-destructive, non-idempotent, openWorld), the description provides practical operational details that help the agent understand when and how the tool might fail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three distinct sections: purpose statement, usage guidelines, parameter summary, and return values. Each sentence adds value without redundancy. The information is front-loaded with the core purpose, followed by practical details, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with authentication, date constraints, and capacity limits), the description provides excellent contextual completeness. It covers purpose, usage conditions, failure modes, parameters, and return values. With annotations covering safety hints and an output schema presumably detailing MealRegistration, the description fills all necessary gaps without over-explaining structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of parameter documentation. It lists all parameters (auth_key/session, meal_date, meal_type, meal_mess, optional guests) and provides some semantic context (e.g., 'optional guests (int)'). However, it doesn't fully explain parameter formats or constraints beyond what's implied, leaving some gaps compared to the detailed schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('register the user for a meal') and resource ('at a specific mess on a date'), distinguishing it from siblings like mess_cancel_registration or mess_get_registration. It explicitly mentions booking/registering for specific meal types (breakfast, lunch, or dinner), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when the user wants to book/register for breakfast, lunch, or dinner') and includes critical exclusion criteria ('Fails with 403 if the registration window is closed or the mess is full'). It also distinguishes from alternatives by not overlapping with other registration tools like mess_create_extra_registration or mess_create_monthly_registration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it discloses rate limiting ('Rate limited to once per minute'), response behavior ('Returns 204 even if email is invalid'), and success condition ('JSON status 204 on success'). Annotations provide basic hints (readOnly=false, destructive=false, etc.), but the description enriches this with practical implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections (purpose, constraints, Args, Returns) in just four sentences. Every sentence adds value: scope restriction, rate limiting, response behavior, parameter explanation, and return format. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema (implied by 'Returns: JSON status 204'), the description provides complete context: purpose, constraints, parameter explanation, and behavioral details. The combination of annotations, schema, and description gives the agent everything needed to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by clearly explaining the single parameter ('email address') in the Args section. However, it doesn't elaborate on format requirements beyond what's implied by 'MSIT/intern accounts' - the schema adds 'Registered MSIT/intern email address' which provides slightly more specificity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Send a password reset OTP') and target resource ('to the given email'), with explicit scope restriction ('Only for MSIT/intern accounts'). It distinguishes itself from sibling tools like 'mess_complete_password_reset' by focusing on OTP generation rather than password reset completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Only for MSIT/intern accounts'), but doesn't explicitly mention when not to use it or name alternatives. It doesn't compare with sibling tools like 'mess_login_msit' or 'mess_reset_qr_token' that might handle authentication differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations already indicate this is read-only, non-destructive, idempotent, and open-world, the description adds that 'Menus are stored week-wise (Sunday-anchored)' and 'effective_from always falls on a Sunday', which helps the agent understand the temporal structure of the data. It doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections: purpose statement, usage examples, data format explanation, and parameter/return documentation. Every sentence adds value without redundancy. The front-loaded purpose statement immediately tells the agent what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter, comprehensive annotations, and the presence of an output schema (implied by 'Returns' documentation), the description provides complete context. It covers purpose, usage, authentication requirements, data structure, parameter semantics, and return format - everything an agent needs to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the schema has no description for the 'params' property itself), the description compensates well by explaining the 'on' parameter's purpose, format ('YYYY-MM-DD'), optionality, default behavior ('defaults to today'), and the weekly storage logic. However, it doesn't fully explain the nested 'params' object structure beyond the 'on' field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the food menu'), resource ('for all messes'), and scope ('on a date'). It distinguishes this tool from sibling tools like mess_get_meal_timings or mess_get_rates by focusing specifically on menu content rather than other dining-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool with three concrete example questions ('what's for lunch today?', 'what's on the menu this week?', 'what is [mess] serving for dinner?'). It also states 'No auth required' which helps the agent understand when authentication isn't needed versus other tools that likely require it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide: it specifies this is a 'full replacement' operation (not incremental), requires all 5 boolean fields, mentions authentication requirements ('auth_key/session'), and documents the return value ('JSON status 204 on success'). Annotations cover idempotency and non-destructive nature, but the description adds crucial operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and economical: a clear purpose statement upfront, followed by organized sections for Args and Returns. Every sentence adds essential information with zero redundancy. The bullet-point formatting enhances readability without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with rich annotations but 0% schema description coverage, the description provides everything needed: clear purpose, complete parameter semantics, behavioral constraints (full replacement), authentication context, and return value documentation. It compensates fully for the schema's lack of descriptions and works effectively with the existing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of parameter documentation and excels at it. It clearly explains the authentication options ('auth_key/session'), lists all 6 boolean parameters with concise explanations of what each controls, and specifies that all are required. This provides complete semantic understanding beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Update all user preferences') and resource ('user preferences'), with explicit mention of 'full replacement' and 'all 5 fields required' that distinguishes it from potential partial-update alternatives. It precisely communicates what the tool does beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('full replacement — all 5 fields required'), implying it should be used for complete preference updates rather than partial modifications. However, it doesn't explicitly name alternative tools or state when not to use it, though the sibling list includes 'mess_get_preferences' which is clearly complementary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![IIITH-Mess-MCP MCP server](https://glama.ai/mcp/servers/Kallind/IIITH-Mess-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Kallind/IIITH-Mess-MCP)

Score Badge

Copy to your README.md:

[![IIITH-Mess-MCP MCP server](https://glama.ai/mcp/servers/Kallind/IIITH-Mess-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Kallind/IIITH-Mess-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kallind/IIITH-Mess-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server