OSRS MCP Server

Official

by WaterSippin

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes: file operations, wiki interactions, and specific data file searches. However, the 12 'search_*' tools for different file types (e.g., search_npctypes, search_objtypes) could be confused as they share similar search patterns across different game data categories, though descriptions clarify the target file.
Naming Consistency3/5
Naming is mixed: 'get_file_details' and 'list_data_files' use verb_noun, while 'osrs_wiki_*' tools prefix with 'osrs_wiki_' and use verb_noun, and 'search_*' tools use a consistent 'search_<type>' pattern. This creates readable but inconsistent conventions across the set.
Tool Count3/5
With 19 tools, the count is borderline high for a server focused on OSRS data and wiki access. It includes many specialized search tools, which might feel heavy but are justified by the domain's complexity, though some consolidation could improve coherence.
Completeness5/5
The tool set comprehensively covers the domain: file management, wiki access, and detailed searches across all major game data types (NPCs, objects, animations, etc.). No obvious gaps exist for retrieving and searching OSRS-related information.
Average 2.9/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves details but doesn't specify what details are returned (e.g., metadata, size, permissions), whether it's read-only (implied but not explicit), or any error conditions (e.g., file not found). This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core purpose efficiently, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include, potential errors, or behavioral traits, leaving significant gaps for a tool that likely returns structured data. More context is needed to fully inform the 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?
The schema description coverage is 100%, with the 'filename' parameter fully documented in the schema. The description adds no additional meaning beyond implying the file must exist in the 'data directory', which is already covered by the schema's description. This meets the baseline for high schema 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 action ('Get details') and resource ('about a file in the data directory'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_data_files' (which likely lists files) or 'search_data_file' (which likely searches file contents), missing the opportunity to clarify its specific scope.
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 an existing filename), exclusions, or comparisons to siblings like 'search_data_file' for finding files by content. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'gets information' but doesn't clarify what type of information (e.g., metadata, content, summaries), how it handles errors, rate limits, or authentication needs. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned, how results are formatted, or any behavioral traits like error handling. For a tool with no structured metadata, this leaves too many open questions 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 input schema has 100% description coverage, with the 'titles' parameter well-documented as a comma-separated list of page titles. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema 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 action ('Get information') and resource ('specific pages on the OSRS Wiki'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'osrs_wiki_parse_page' or 'osrs_wiki_search', which likely have overlapping domains but different functionalities.
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 when to prefer this over 'osrs_wiki_parse_page' or 'osrs_wiki_search', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'parsed HTML content' but doesn't explain what parsing entails (e.g., cleaned markup, extracted data), potential rate limits, authentication needs, or error handling. This leaves significant gaps for a tool that interacts with an external wiki.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Get', 'parsed HTML content', 'specific OSRS Wiki page') contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'parsed HTML content' means in practice, what format or structure is returned, or any behavioral traits like network dependencies or failure modes. For a tool fetching external data, this leaves critical context gaps.
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 100%, with the single parameter 'page' well-documented in the schema (including case-sensitivity and examples). The description adds no additional parameter semantics beyond what's already in the schema, meeting the baseline for high 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 verb ('Get') and resource ('parsed HTML content of a specific OSRS Wiki page'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'osrs_wiki_get_page_info' or 'osrs_wiki_search', which likely serve related but distinct functions.
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. With siblings like 'osrs_wiki_get_page_info' and 'osrs_wiki_search' available, there's no indication of what distinguishes this parsing tool from those, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions searching for 'pages matching a search term,' it doesn't describe what the search returns (e.g., page titles, snippets, URLs), whether there are rate limits, authentication requirements, or error conditions. This leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, and there's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a search tool with 3 parameters. It doesn't explain what the search returns (e.g., list of page objects, metadata), how results are ordered, or any limitations (e.g., search scope, timeouts). For a tool that likely returns structured data, more context is needed to use it effectively.
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 adds no parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions for 'search', 'limit', and 'offset'. The baseline score of 3 reflects that the schema adequately documents parameters, so the description doesn't need to compensate, but it also doesn't provide additional context like search syntax examples or result ordering.
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 ('Search') and target resource ('the OSRS Wiki for pages'), making the purpose immediately understandable. It distinguishes from siblings like 'osrs_wiki_get_page_info' and 'osrs_wiki_parse_page' by focusing on search functionality rather than retrieving or parsing specific pages. However, it doesn't explicitly contrast with other search tools in the sibling list, 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. With many sibling search tools available (e.g., search_data_file, search_iftypes, etc.), there's no indication of what makes this tool unique for OSRS Wiki searches versus other data types. No context about prerequisites, exclusions, or typical use cases is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching 'any file' but does not disclose behavioral traits such as pagination behavior (implied by parameters), error handling, performance characteristics, or what constitutes 'matching entries'. This leaves significant gaps for a search operation.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain what 'matching entries' means, the format of results, or error conditions. For a search tool with multiple parameters and sibling tools, more context is needed to guide 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying a search across files, which is already clear from the tool name and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('search') and target ('any file in the data directory for matching entries'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'search_iftypes', 'search_invtypes', etc., which appear to be specialized searches, so it misses full 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 does not mention sibling tools like 'list_data_files' for browsing or specialized search tools (e.g., 'search_iftypes'), nor does it specify prerequisites or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions searching a specific file but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, error conditions, or what the output looks like (e.g., format, pagination details beyond schema). This is a significant gap for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'interface definitions' entail, the return format, or any behavioral context. For a search tool with multiple parameters, this leaves too many unknowns for effective agent 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?
Schema description coverage is 100%, so the schema fully documents parameters (query, page, pageSize). The description adds no additional meaning beyond implying the query term applies to 'interface definitions,' which is minimal value. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Search') and target resource ('the iftypes.txt file for interface definitions'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_invtypes' or 'search_data_file' beyond mentioning the specific file name, which is somewhat helpful but not fully distinguishing.
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. With many sibling search tools (e.g., search_invtypes, search_data_file), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on file names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching a file but doesn't describe the return format, whether results are paginated (implied by parameters but not stated), error conditions, or performance characteristics. For a search tool with no annotation coverage, this is a significant gap in 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., structured data, raw text), how results are formatted, or any limitations. For a search tool with three parameters and no structured output, more context is needed to guide 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?
Schema description coverage is 100%, so the schema already documents all parameters (page, pageSize, query) with descriptions and constraints. The description adds no additional parameter semantics beyond implying a search term is needed. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('Search') and resource ('invtypes.txt file for inventory type definitions'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its many sibling search tools (e.g., search_iftypes, search_loctypes) beyond mentioning 'inventory type definitions,' which provides some distinction but could be more specific about what makes inventory types unique compared to other data types.
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. With multiple sibling tools like search_data_file, list_data_files, and other type-specific searches, there's no indication of prerequisites, use cases, or exclusions. This leaves the agent without context for tool selection in a crowded namespace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching a specific file ('loctypes.txt') but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the search returns (e.g., format, pagination details). This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of definitions, structured data), how results are formatted, or behavioral traits like pagination handling, leaving the agent with insufficient 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?
Schema description coverage is 100%, so the schema fully documents the three parameters (query, page, pageSize). The description adds minimal value by implying the 'query' parameter searches within the file, but doesn't provide additional semantics beyond what the schema already states (e.g., search scope, result types).
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 ('Search') and the target resource ('loctypes.txt file for location/object type definitions in the game world'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_data_file' or other search_* tools, which would require a 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 like 'search_data_file' or other search_* tools (e.g., 'search_iftypes', 'search_npctypes'). It lacks any mention of prerequisites, exclusions, or specific contexts for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching but doesn't disclose behavioral traits like whether this is read-only (likely, but not stated), what format results return, if there are rate limits, authentication needs, or how the search operates (exact match, substring, case sensitivity). The description is minimal and lacks essential operational context.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple search tool and front-loads the core purpose immediately, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a search tool with 3 parameters. It doesn't explain what the search returns, how results are structured, or any behavioral aspects like pagination details or error handling. For a tool that likely returns complex NPC definition data, this leaves significant gaps in 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 100%, with all parameters well-documented in the schema itself (query, page, pageSize). The description adds no additional parameter semantics beyond implying a search term is needed, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from 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 action ('Search') and target resource ('npctypes.txt file for NPC definitions'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'search_data_file' or other search_* tools, which all search different file types but share similar functionality patterns.
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. With many sibling search tools (search_data_file, search_iftypes, search_invtypes, etc.), the description doesn't explain that this specifically searches NPC type definitions rather than other data types, nor does it mention any prerequisites or constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches a file but doesn't describe what the search returns (e.g., matches, full definitions, snippets), how results are ordered, whether it's case-sensitive, or any error conditions. For a search tool with zero annotation coverage, this is a significant gap in transparency about its behavior.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, target, and context concisely, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of matches, structured data), how to interpret results, or any limitations (e.g., file size constraints, search performance). For a tool with 3 parameters and behavioral uncertainty, this leaves too much unspecified for reliable agent 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?
Schema description coverage is 100%, with clear documentation for all three parameters (query, page, pageSize). The description adds minimal value beyond the schema, only implying that the 'query' parameter searches within the file content. It doesn't explain search semantics (e.g., partial matches, wildcards) or how pagination interacts with results, so it meets the baseline for high schema coverage without compensating further.
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 ('search') and target resource ('objtypes.txt file for object/item definitions in the game'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its many sibling search tools (e.g., search_iftypes, search_invtypes) beyond mentioning the specific file name, which is helpful but could be more explicit about what makes 'objtypes' unique compared to other data types.
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. With multiple sibling tools like search_data_file, search_iftypes, etc., there's no indication of which tool is appropriate for searching object/item definitions specifically, nor any mention of prerequisites or contextual constraints. This leaves the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching a file but doesn't describe what 'search' entails (e.g., exact match, substring, case sensitivity), the format of results, or any constraints like rate limits or permissions. This leaves significant gaps for a tool with parameters and no output schema.
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 a single, efficient sentence that front-loads the core action ('search') and resource. It avoids redundancy and wastes no words, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of row definitions, metadata), how results are structured, or behavioral aspects like error handling. For a search tool with no structured output, more context is needed to guide 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?
Schema description coverage is 100%, so the schema fully documents the three parameters (query, page, pageSize). The description adds no additional meaning beyond implying 'query' searches within the file, which is already clear from the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 ('search') and resource ('rowtypes.txt file'), specifying it's for 'row definitions used in various interfaces.' This distinguishes it from generic file operations but doesn't explicitly differentiate it from similar sibling tools like search_iftypes or search_invtypes, which likely search different definition files.
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 when to choose it over other search tools (e.g., search_data_file or search_iftypes) or when it's appropriate for row definitions versus other data types. Usage is implied by the resource name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, what happens on no matches, or the format of returned results. For a search tool with zero annotation coverage, this is insufficient.
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 a single, efficient sentence with zero waste. It's appropriately sized for a search tool and front-loads the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a search tool with pagination parameters. It doesn't explain what 'animation sequence definitions' are, the return format, error conditions, or how results are structured. The agent lacks sufficient context to use this tool effectively.
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 100%, so the schema fully documents all three parameters (query, page, pageSize). The description adds no additional parameter semantics beyond what's in the schema, such as search syntax examples or pagination behavior. Baseline 3 is appropriate when schema does all the work.
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 ('Search') and target resource ('seqtypes.txt file for animation sequence definitions'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'search_iftypes' or 'search_invtypes' which likely search similar file types, missing explicit sibling distinction.
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. The description doesn't mention when to choose this over other search tools like 'search_data_file' or 'search_iftypes', nor does it specify any prerequisites or contextual triggers for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching a file but doesn't describe what the search returns (e.g., matches, metadata), whether it's case-sensitive, if it supports wildcards, or any limitations like file size constraints. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently states the tool's purpose. It's front-loaded with the main action and resource, with no wasted words. However, it could be slightly more structured by explicitly mentioning the search scope or output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the search returns (e.g., lines, definitions, metadata), how results are formatted, or any behavioral nuances. For a tool with 3 parameters and no structured output information, more context is needed.
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 100%, so the schema fully documents all three parameters (query, page, pageSize). The description adds no additional parameter semantics beyond implying the query searches within the file, which is already clear from the schema. This meets the baseline for high schema 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 verb 'search' and the resource 'soundtypes.txt file for sound effect definitions', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_data_file' or other search_* tools, which would require more specific context about what makes soundtypes unique.
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 'search_data_file' or other search_* tools. It mentions searching a specific file, but doesn't explain why one would choose this over a more general search tool or when sound effect definitions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions searching a file but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, how results are returned (e.g., format, pagination details beyond schema), or any rate limits. The description is minimal and lacks critical operational context for a search 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('search') and resource. However, it could be slightly more structured by explicitly mentioning the tool's role among siblings, but it avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of definitions, snippets), how results are ordered, or error conditions. For a tool with no structured output information, more descriptive context is needed to guide 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?
Schema description coverage is 100%, so the schema fully documents parameters (query, page, pageSize). The description adds no additional meaning beyond implying the query term is applied to the file content. With high schema coverage, the baseline is 3, as the description doesn't compensate with extra details like search syntax or result formatting.
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 ('search') and resource ('spottypes.txt file'), specifying it's for 'spot animation (graphical effect) definitions'. It distinguishes from general file operations like 'get_file_details' or 'list_data_files' by focusing on searching within a specific file type. However, it doesn't explicitly differentiate from similar sibling tools like 'search_iftypes' or 'search_npctypes' beyond the file name.
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 when to choose this over other search tools (e.g., 'search_data_file' for general searches or other type-specific searches like 'search_invtypes'), nor does it specify prerequisites or exclusions. Usage is implied by the file name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching a file but does not cover critical aspects such as whether this is a read-only operation, potential rate limits, authentication needs, error handling, or the format of results. For a search tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, result format, error conditions, and differentiation from siblings, making it incomplete for effective agent use despite the clear schema coverage.
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 100% description coverage, clearly documenting all three parameters (query, page, pageSize) with details like defaults and constraints. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 without compensating for any 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 action ('Search') and the target resource ('spritetypes.txt file for sprite image definitions used in the interface'), making the purpose evident. However, it does not explicitly differentiate this tool from its many sibling search tools (e.g., search_iftypes, search_invtypes), which all seem to search different file types, leaving some ambiguity about when to choose this specific one over others.
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. With multiple sibling tools like search_data_file, search_iftypes, etc., it fails to specify contexts, prerequisites, or exclusions, leaving the agent to infer usage based on the file name alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Search' implies a read operation, it doesn't disclose important behavioral aspects like whether this is a full-text search, regex support, case sensitivity, performance characteristics, or what happens when no results are found. The description is minimal and lacks operational context.
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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a search tool and front-loads the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the search returns (formats, structure, or content), how results are ordered, or what 'interface tab definitions' actually means in practice. The agent would need to guess about the tool's behavior and output.
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 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description mentions 'search' which aligns with the 'query' parameter, but adds no additional semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 ('Search') and target resource ('tabletypes.txt file for interface tab definitions'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like search_iftypes or search_invtypes, but the specific file reference provides some implicit 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. With many similar 'search_' sibling tools available, there's no indication of what makes this specific file search unique or when it should be preferred over other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching a file but doesn't disclose behavioral traits like whether this is a read-only operation, what format results are returned in, whether there are rate limits, or what happens with invalid queries. The description is minimal and lacks operational context.
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 a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a search tool, though it could potentially benefit from slightly more context given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what results look like, how they're structured, or what happens with pagination. Given the context of multiple similar search tools and the technical nature of varbits, more guidance would be helpful.
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 100%, so the schema fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate schema 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 searches a specific file (varbittypes.txt) for variable bits (varbits) that store individual bits from varps. It specifies the verb 'search' and resource 'varbittypes.txt file', but doesn't explicitly differentiate from sibling tools like search_varptypes or search_data_file, which appear related.
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. With multiple sibling search tools (search_varptypes, search_data_file, etc.), there's no indication of what makes this tool distinct or when it should be preferred over other search options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching a specific file ('varptypes.txt') but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what the search returns (e.g., format, pagination details). The description is minimal and lacks critical operational context.
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 a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more informative given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (search operation with pagination), no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of varps with details), how results are structured, or any error conditions. This leaves significant gaps for an AI agent to understand the tool's behavior.
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 100%, so the schema fully documents the three parameters (query, page, pageSize). The description adds no additional parameter semantics beyond implying the 'query' searches within the file content. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
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 ('Search') and target resource ('varptypes.txt file for player variables'), specifying that these variables store player state and progress. It distinguishes from some siblings (e.g., 'search_iftypes') by mentioning 'player variables', but doesn't explicitly differentiate from similar tools like 'search_varbittypes' or 'search_data_file'.
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, constraints, or compare it to sibling tools like 'search_data_file' (which might search other files) or 'search_varbittypes' (which searches related variable types).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation but doesn't describe what 'available' means (e.g., permission-based, all files), whether it's paginated, what format the output takes, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple list tool and front-loads the core purpose immediately.
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 optional parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It covers the basic purpose but doesn't address behavioral aspects like output format or usage context relative to siblings, leaving room for improvement despite the simple structure.
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 100%, so the schema already documents the single optional 'fileType' parameter with its purpose. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score of 3 for adequate but no extra value.
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 ('List') and resource ('available data files in the data directory'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_data_file', which appears to be a related search function.
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 'search_data_file' or 'get_file_details'. It mentions a data directory context but offers no explicit when/when-not instructions or prerequisites for usage.
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:

[![mcp-osrs MCP server](https://glama.ai/mcp/servers/WaterSippin/mcp-osrs/badges/card.svg)](https://glama.ai/mcp/servers/WaterSippin/mcp-osrs)

Score Badge

Copy to your README.md:

[![mcp-osrs MCP server](https://glama.ai/mcp/servers/WaterSippin/mcp-osrs/badges/score.svg)](https://glama.ai/mcp/servers/WaterSippin/mcp-osrs)

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/WaterSippin/mcp-osrs'

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