KotorMCP

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools have distinct purposes, targeting specific resource types or actions. Some overlap exists between describe and list tools (e.g., kotor_describe_resource_refs vs kotor_list_references) but descriptions help differentiate. Overall clear boundaries.
Naming Consistency3/5
Majority use 'kotor_' prefix with snake_case verb_noun pattern, but several tools (detectInstallations, listResources, etc.) lack the prefix, breaking consistency. The pattern is still readable but uneven.
Tool Count3/5
28 tools is on the high side for a single server, but justified by the complexity of KotOR modding/analysis. Some tools could be merged (e.g., read vs describe), but still within reasonable bounds.
Completeness4/5
The tool surface covers installation management, resource reading/searching, module analysis, and reference tracing comprehensively. Missing are write/modify tools (except extract), but the server appears read-only focused. Minor gaps like batch operations.
Average 3.9/5 across 28 of 28 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under LGPL 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states 'Read-only' but does not describe other behaviors like what happens if the resource is not found, whether permissions are needed, or any rate limiting. The output format is not mentioned.
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, front-loaded sentence that immediately conveys purpose and usage. Every word serves a purpose, making it highly efficient.
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 four parameters, no output schema, and no annotations, the description is sparse. It does not explain what the tool returns (e.g., a list of reference objects), how to interpret results, or handle edge cases like missing resources or partial paths. This is insufficient for a tool of this complexity.
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?
Input schema descriptions cover all four parameters (100% coverage), so the baseline is 3. The description adds the phrase 'by field path' which could ambiguously refer to the 'path' parameter or something else, but overall it does not add significant semantic value 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: listing outbound references from a resource, specifying fields like scripts, conversations, tags, and template resrefs. However, it does not explicitly distinguish itself from sibling tools like 'kotor_find_referrers' or 'kotor_describe_resource_refs', which could have overlapping functions.
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 provides usage context with 'Use when tracing what a resource references' and notes it is read-only. However, it does not offer guidance on when not to use this tool or mention alternatives among the sibling tools, such as when to use 'kotor_find_referrers' instead.
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 responsibility for behavioral transparency. It mentions 'Read-only', which indicates no side effects, but lacks details on performance, error handling, authorization, or behavior with invalid parameters. Minimal disclosure.
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—one sentence that covers the essential purpose and filters. No unnecessary words, and the key verb and resource are front-loaded. Every word earns its place.
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 5 parameters (2 required), no output schema, and no annotations, the description is insufficient. It does not explain the JSON return format, error scenarios, or the meaning of row ranges in the context of 2DA tables. More context is needed 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters like game, resref, row_start, row_end, and columns.
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 'read', the resource '2DA table', and the format 'JSON' with optional filters. However, it does not explicitly differentiate from sibling tools like kotor_lookup_2da, which may offer similar functionality.
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 phrase 'Use when you need a 2DA table as JSON' implies when to use, but there is no guidance on when not to use, prerequisites, or alternatives. The context is implied but not explicit.
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, the description carries full burden. It only states 'Read-only' and 'using resolution order' but does not explain the default order, what happens if the resource is not found, or how the summary is returned (e.g., format). This leaves significant behavioral ambiguity.
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 sentence, concise and front-loaded with usage. However, a structured format (e.g., listing key behaviors) could improve clarity without adding verbosity.
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 4 parameters, no output schema, and no annotations, the description is too brief. It fails to specify output format, default resolution order, error handling, or what constitutes a 'short summary', leaving critical gaps for correct invocation.
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 only 25% (only 'order' has a description). The description does not explain the required parameters (game, resref, restype) beyond the context of the tool purpose. For example, valid values for restype or resref format are not clarified.
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 verb ('short summary'), the resource types (GFF, TLK, 2DA), and the method (resolution order). It distinguishes itself from siblings that provide raw data (e.g., kotor_read_2da) by focusing on summarization.
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 says 'Use when you need a short summary', giving clear context for use. It also marks the tool as read-only, implying no side effects. However, it does not explicitly state when not to use or name alternatives, though the sibling list provides context.
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 explicitly states 'Read-only,' which is a key behavioral trait in the absence of annotations. However, it does not disclose other potential behaviors such as return format, performance characteristics, or error handling, leaving some gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence that is front-loaded with the usage context. Every word contributes value, with no superfluous information.
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 no output schema and moderate complexity (3 parameters including a required override path), the description is too minimal. It does not explain what a 'JRL summary' contains, how to interpret the output, or handle edge cases, making it incomplete for an agent to use reliably.
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 coverage is 100%, so the input schema already describes all parameters ('game', 'resref', 'path'). The description adds no additional meaning or context for these parameters, providing no value beyond the schema. Baseline score of 3 is appropriate.
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 that this tool provides a JRL (journal) summary of categories and entries, specifying the resource type and the nature of the output. However, it does not differentiate from the sibling tool 'journalOverview', which likely serves a similar 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 tells when to use the tool ('when you need a JRL summary') and notes it is read-only, implying no side effects. However, it provides no guidance on when not to use it or any 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior and pagination, which adds value beyond the schema. However, with no annotations and no output schema, it does not describe what list entries look like or other behavioral traits (e.g., does it return paths, sizes?).
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?
Extremely concise: two sentences, 20 words. Front-loaded with usage guidance. Every word serves a purpose.
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?
With no output schema, the description should clarify what list entries look like (e.g., file names, sizes). It does not, leaving the agent uncertain about return format. Incomplete for a tool with 4 parameters and no annotations.
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 coverage is 100%, so description adds no new parameter information beyond mentioning pagination in the top-level description. Meets baseline but does not enhance meaning.
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?
Clearly states the verb 'list contents' and specifies the resource types (KEY/BIF/RIM/ERF/MOD) with pagination. However, it does not explicitly differentiate from sibling listing tools like listResources or kotor_list_modules, though the archive file types provide some distinction.
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?
Includes 'Use when you need to list contents...' which is a usage hint, and mentions 'Read-only.' But lacks explicit guidance on when not to use or alternatives among siblings.
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 states 'Read-only,' which is a key behavioral trait. With no annotations provided, the description carries full burden and could be improved by disclosing more details like side effects or constraints, but the read-only declaration is adequate.
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 conveys all necessary information without waste. Every word serves a purpose.
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?
The description explains what the tool does but does not specify output format or return structure. Given no output schema, more detail would be helpful, though it provides a reasonable overview of the tool's function.
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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. No parameter semantics are enhanced.
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: retrieving DLG structure with entry/reply counts and script/condition references. It specifies the resource type and read-only nature, but does not explicitly differentiate from sibling tools like kotor_describe_jrl.
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 phrase 'Use when you need DLG structure' provides a clear usage context. However, it lacks information on when not to use it or mention of alternatives among siblings.
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 labels the tool as 'Read-only', which conveys safety and idempotency. However, it does not disclose how multiple query parameters interact (e.g., both range and text_search), pagination behavior beyond the limit parameter, or any other behavioral traits.
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 exceptionally concise, consisting of two short sentences that are front-loaded with the primary purpose. Every word adds value without unnecessary elaboration.
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?
For a tool with 5 parameters and no output schema, the description is adequate but lacks details on parameter interaction, error handling, or return format. It covers the basics but leaves room for ambiguity in complex queries.
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?
Given that schema coverage is 100%, the description adds minimal extra meaning beyond the parameter descriptions. It reinforces the two query modes but does not elaborate on usage details like exclusive or combined use of strref range and text search.
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 reads TLK entries and specifies two query modes (strref range and text search), making the purpose distinct. However, it does not explicitly differentiate from the sibling tool kotor_lookup_tlk.
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 indicates when to use the tool ('when you need TLK entries by strref range or text search'), which is helpful, but it does not mention when not to use it or suggest alternatives like kotor_lookup_tlk for single strref lookups.
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?
With no annotations provided, the description carries the full burden. It discloses 'Read-only', which is a key behavioral trait. However, it does not mention other behaviors like error handling, return format, or performance implications.
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 sentence that is front-loaded with the usage context. Every word is necessary, and there is no waste, making it highly concise.
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 (2 parameters, no output schema), the description adequately covers purpose and read-only nature. It is mostly complete but could benefit from mentioning what is returned or how to handle invalid strrefs.
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 coverage is 100%, meaning all parameters are already described in the schema. The description does not add any extra semantics beyond what the schema provides, meeting the baseline for this dimension.
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 specifies the tool's purpose: 'resolve a strref to display text from dialog.tlk'. It includes the verb 'resolve' and resource 'strref to text', and is distinguishable from sibling tools like kotor_read_tlk. However, it does not explicitly differentiate from siblings.
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 states 'Use when you need to resolve a strref', providing explicit usage context. However, it lacks guidance on when not to use the tool or mention of alternative tools for similar tasks, such as kotor_find_strref_referrers.
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?
With no annotations provided, the description states that the tool is 'Read-only; does not modify disk,' which discloses its non-destructive nature. However, it lacks details on potential failure modes, required permissions, or other behavioral traits beyond what is stated. This is minimal but adequate for a read-only 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, well-structured sentence that immediately states the purpose and key behavioral trait (read-only). Every word earns its place; there is no wasted 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?
For a simple tool with two parameters and no output schema, the description covers the core functionality and safety aspect. It is slightly lacking in details about error conditions or the exact meaning of 'activation,' but overall it is complete enough for an agent to use 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?
The schema covers 100% of parameters (game and path) with descriptions. The tool's description adds no additional meaning beyond the schema, so it does not improve parameter understanding. Baseline score of 3 is appropriate.
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 that the tool activates an installation in memory for subsequent tools, which is a specific verb+resource. It distinguishes itself from siblings by implying it's a prerequisite for many tools, but does not explicitly differentiate from openInstallation. The purpose is clear but could be more distinct.
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 provides an explicit 'Use when' condition for activating an installation. However, it does not mention when not to use this tool or compare it to alternative tools like openInstallation. The usage guidance is present but limited.
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?
No annotations are provided, so the description must bear the full burden. It describes 'page through' indicating a read operation, and mentions 'canonical dependency edges' as the content. However, it does not explicitly state that it is read-only, nor does it mention any side effects, pagination behavior, or return format. The description is adequate but not comprehensive.
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 sentence that is front-loaded with the core purpose. No extraneous information is present, and it is efficiently written.
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?
The tool has 7 parameters and no output schema or annotations. The description covers the high-level purpose but lacks details about return values, pagination behavior, or how parameters interact. It is minimally complete for an experienced user but could be more informative.
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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter. No parameter-specific clarifications are given.
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 (page through) and resource (canonical dependency edges) and context (from an in-memory installation snapshot created by openInstallation). It distinguishes itself from siblings like detectInstallations or getInstallationSnapshot by specifying it deals with dependency edges rather than snapshots or detection.
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 after calling openInstallation, but does not explicitly state when to use this tool versus alternatives like getInstallationSnapshot or describeResource. No when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the transparency burden. It discloses the tool is 'Read-only' and mentions pagination via limit/offset, but it does not describe the response format, potential errors, or any side effects. The information is adequate but not rich.
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 sentence that efficiently conveys the tool's purpose and key behavioral attribute (read-only). No word is wasted, and it is front-loaded with the usage guidance.
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 no output schema, the description could be more complete by explaining what the paginated list contains (e.g., resource names, types). For a listing tool, it covers the basics but lacks details about pagination metadata or response 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?
The input schema already describes all 4 parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter details beyond what the schema provides, such as valid values or format constraints.
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 provides a 'paginated list of all resources in a module' with specific file extensions, distinguishing it from sibling tools like kotor_find_resource (for searching) and kotor_list_modules (for listing modules). The verb 'list' and resource 'module resources' are 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 begins with 'Use when you need a paginated list...' which implies the context, but it does not explicitly state when not to use it or mention alternatives among the many sibling tools. The guidance is implicit rather than explicit.
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 must convey all behavioral traits. It only states 'Read-only,' which is minimal. It does not disclose what happens on invalid input, error states, or any side effects beyond the read-only nature.
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, front-loaded sentence with zero waste. It efficiently conveys the purpose and usage context.
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?
For a tool with one parameter and no output schema, the description covers the essential purpose and safety (read-only). It lacks details about the summary format or behavior on missing data, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'game' parameter. The description adds no extra meaning beyond the schema's 'Game alias: k1 or k2'. Baseline 3 applies.
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 provides a summary of global.jrl plot categories and entries, and explicitly notes it is read-only. This is a specific verb-resource combination that distinguishes it from sibling tools like kotor_describe_jrl or kotor_list_resources.
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 begins with 'Use when you need...' which explicitly tells the agent when to invoke this tool. While it does not provide exclusions or alternatives, the single-sentence guidance is direct and actionable.
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?
No annotations are provided, so the description carries full burden. It states 'Read-only,' indicating no destructive side effects. But it does not disclose other behaviors like whether it requires an installed game or reads from archives. For a read-only tool, this is adequate but minimal.
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: one sentence plus the 'Read-only' tag. It front-loads the purpose and lists key outputs without unnecessary words. Every element earns its place.
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 no output schema, the description lists output components (ARE, LYT, WOK, resources, scripts), giving a solid picture of what the tool returns. Parameters are fully covered. For a module analysis tool with many siblings, this is sufficiently complete, though it could mention the format or structure of the 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?
Schema coverage is 100% with clear descriptions for both parameters (game and module_root). The description adds 'full module analysis' but does not provide additional semantic meaning beyond the schema. Thus, baseline score of 3 is appropriate.
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?
Description explicitly states 'full module analysis' and lists specific components (ARE, LYT rooms, WOK list, resource counts, scripts), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools like kotor_describe_dlg or kotor_describe_jrl, which is a minor gap.
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 phrase 'Use when you need full module analysis' provides clear context for when to use this tool. It also notes 'Read-only.' However, it does not explicitly state when not to use it or mention alternative tools for more specific needs, which would improve 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?
With no annotations, the description bears full burden. It mentions loading the installation if not cached, which is helpful. However, it does not disclose whether the tool is read-only, potential side effects, or error behavior, leaving 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 two sentences, each earning its place: first sentence states purpose and output, second adds caching behavior. No redundant 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?
For a simple information tool without output schema, the description covers the key return values and caching behavior. It could mention error handling or validity interpretation, but is sufficient for an agent to use 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 coverage is 100% with both parameters described. The description adds marginal value by listing output fields, but does not elaborate on the parameters beyond what schema provides. 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 tool's purpose: providing installation summary including path, game, validity, errors, missing files, and counts. It distinguishes itself from siblings by focusing on a summary rather than detailed snapshots or detection.
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 specifies when to use ('when you need installation summary') but lacks explicit guidance on when not to use or alternatives among siblings. Given the many sibling tools, more contrast would be beneficial.
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?
With no annotations, the description must fully disclose behavior. It correctly identifies the tool as read-only and lists the resource locations and optional filters. However, it does not mention pagination behavior (limit/offset) or other side effects, but the core trait is well communicated.
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, front-loaded sentence with no filler. Every word is meaningful and the structure is optimal for quick parsing.
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?
Despite having 7 parameters and no output schema, the description is minimal. It omits details about pagination, return format, error conditions, and constraints like maximum results. The high parameter count demands more context than provided.
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 coverage is high (86%), so the baseline is 3. The description adds no parameter-specific meaning beyond 'optional filters'. It does not explain what each filter does or provide examples, leaving the schema to carry the burden.
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: 'list resources from override/modules/chitin with optional filters'. It includes a usage context ('Use when exploring installation contents') and declares it as read-only. This effectively distinguishes it from sibling tools like kotor_list_modules or kotor_list_archive, which have narrower scopes.
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 provides a clear context ('Use when exploring installation contents') but lacks explicit guidance on when not to use this tool or which alternatives to prefer. Sibling tools with similar functions (e.g., kotor_list_modules, describeResource) are not compared, leaving the agent to infer appropriate usage.
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?
No annotations are provided, so the description must carry the burden. 'Page through' implies a read-only operation, and 'in-memory' suggests speed, but no explicit mention of side effects, auth needs, or rate limits. It adds context about compaction but is not fully transparent.
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?
Two sentences, no unnecessary words. The purpose and a key parameter detail are front-loaded. Every sentence earns its place.
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?
No output schema exists, but description does not specify return format or pagination details beyond mentioning compacted vs. metadata-only. With 7 parameters and no annotation, the description is adequate but not rich.
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 coverage is 100%, so baseline is 3. The description adds value by explaining includeData's effect ('for compacted per-resource documents'), but other parameters (like limit, offset) are not elaborated beyond schema. Moderate added meaning.
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 uses the specific verb 'Page through' and identifies the resource as 'a compacted in-memory installation snapshot created by openInstallation'. It clearly distinguishes the action from sibling tools like openInstallation (which creates the snapshot) and listResources.
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 context on when to use the includeData parameter ('for compacted per-resource documents'). While it implies use after openInstallation, it does not explicitly contrast with alternatives or state when not to use.
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?
With no annotations provided, the description carries the full burden. It declares 'Read-only', which is helpful, but it does not disclose other behavioral traits such as pagination behavior, performance implications, or error handling. For a tool with pagination parameters, more transparency is expected.
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 with two sentences, no wasted words, and front-loaded with the purpose. Every sentence earns its place.
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?
The tool has 5 parameters and no output schema. While the description covers the core purpose, it lacks details about the return format, pagination behavior, or any constraints beyond the schema. Given the complexity, additional context would improve 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 coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides. It does not explain the meaning or relationship of parameters like 'limit' or 'offset' in 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 verb 'find' and the specific resource 'TLK strref', distinguishing it from sibling tools like general 'kotor_find_referrers'. The reference to 'TLK/2DA Find References parity' adds clarity.
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 says 'Use when you need to find which resources use a TLK strref', which provides clear when-to-use guidance. However, it does not mention when not to use or alternative tools, missing the explicit exclusions for a perfect score.
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?
No annotations provided; description carries full burden. States 'Read-only' which is a key behavioral trait, but lacks details on output format, error conditions, or side effects beyond read-only.
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?
Single, front-loaded sentence with no filler. Clearly communicates purpose and key constraint (read-only) efficiently.
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?
Provides usage context and read-only hint, but lacks details on what the summary contains (fields, counts). Given sibling complexity and no output schema, a more specific output description would improve 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 100%, so the schema documents all 4 parameters. The description does not add additional meaning beyond the schema; 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?
Description clearly states the tool provides a 'reference summary' for 'any GFF resource', listing specific resource types (scripts, conversations, etc.), distinguishing it from sibling tools like kotor_read_gff which likely return full 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?
Explicitly says 'Use when you need a reference summary' and marks as 'Read-only', but does not explicitly advise against using for full data access or mention alternatives like kotor_read_gff.
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?
With no annotations provided, the description must disclose behavioral traits. It states 'Writes to disk' and includes a destructiveHint annotation within the description, alerting that it modifies the filesystem. However, it does not mention overwriting behavior, error handling, or directory creation. The transparency is adequate but incomplete.
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 two sentences: a clear use-case trigger and a clarification on the 'source' parameter. The final 'Writes to disk' is slightly redundant with the first sentence, but overall it is efficient and front-loaded. Each sentence adds value, though could be slightly more concise.
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 has 5 parameters (4 required) and no output schema, the description explains the primary function and parameter usage but omits return value information. For a writing tool, agents might expect to know if the operation returns a success indicator or path. The description is sufficient for basic usage but not fully complete.
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 100%, so baseline is 3. The description adds value by listing possible values for 'source' (OVERRIDE, CHITIN, MODULES), which is not in the schema. This extra context helps agents choose the correct parameter values.
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 'write a resolved resource to disk', specifying the action and target. It distinguishes from sibling tools like kotor_find_resource which does not write. The verb 'write' and resource 'resolved resource' are 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 starts with 'Use when you need to write a resolved resource to disk', providing a clear trigger for usage. It mentions optional 'source' restriction, but does not explicitly state when not to use or name alternatives. Given sibling tools, the context implies alternative actions like finding or describing, but not explicit.
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?
With no annotations provided, the description clearly states the tool is read-only and does not write to disk, and it explains caching behavior (reuse or rebuild). It lacks details on potential memory usage or handle lifetime, but for a simple read-only operation, the transparency is adequate and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover the tool's purpose, behavior, and side effects without redundancy. Every word serves a purpose, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains the return value (a handle for paged queries) and the caching behavior. It does not specify the handle format or usage instructions, which could be improved, but overall provides sufficient context for a tool with three simple 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 coverage is 100% with descriptions for all three parameters. The tool description does not add new parameter semantics beyond the schema, such as clarifying the 'path' format or 'refresh' implications. Baseline 3 is appropriate as the schema already documents the parameters sufficiently.
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 builds or reuses an in-memory installation snapshot and returns a handle for paged queries. It specifies the resource (installation snapshot) and action (build/reuse), and distinguishes itself as compacted and read-only, setting it apart from siblings like getInstallationSnapshot or loadInstallation.
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 creating a snapshot for follow-up queries but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like getInstallationSnapshot. No direct comparison or exclusion criteria are given, leaving the agent to infer context based on the 'read-only' and 'compacted' nature.
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?
Declares read-only and paginated behavior, which are key for agent decision-making. No annotations exist, so description carries burden; could mention additional constraints like rate limits or empty results.
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?
Single sentence packs purpose, usage hint, pagination, and safety trait with zero 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?
Covers key aspects for a search tool (purpose, filtering, pagination) but omits output format. Given no output schema, describing return structure would improve 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 covers 80% of parameters with descriptions. The description adds context about pagination but does not explain the 'game' parameter. Baseline 3 justified as schema does most of the work.
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?
Clearly states it searches resource names by regex, distinguishing it from sibling tools like listResources and kotor_find_resource.
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?
Specifies when to use (regex search) and gives pragmatic advice (prefer location/type filter on large installs). Lacks explicit exclusions or comparison with alternatives.
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?
No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only,' telling the agent the tool has no side effects. It also warns that searches are 'expensive over full install,' providing cost context beyond what annotations alone would 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 concise: two sentences that pack purpose, usage advice, and behavioral traits without any filler. Every sentence earns its place.
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?
While the description explains what the tool does and how to use it, there is no output schema and the description does not specify the format or structure of the results. For a query tool, this is a notable gap, preventing the agent from fully understanding what to expect.
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 100%, so the baseline is 3. The description adds value by noting that module_root narrows the search and explaining the expense, which helps the agent decide how to set parameters. It also clarifies the meaning of 'value' by listing example types (script resref, tag, etc.), complementing the 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 tool's purpose: to find which resources reference a given script resref, tag, conversation, or resref. It uses specific verbs ('find which resources reference') and identifies the resource types, distinguishing it from siblings like kotor_find_strref_referrers.
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 guidance on when to use the tool and how to narrow the search with module_root to avoid expense over full install. While it doesn't explicitly list alternatives, it implies appropriate contexts and gives practical advice.
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 notes the tool is read-only and provides resolution order, which adds behavioral context. However, with no annotations, more details (e.g., error handling, performance, case sensitivity) would 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?
Two efficient sentences cover purpose, glob support, resolution order, and read-only nature. No wasted words, and critical information is front-loaded.
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 simple resource lookup tool with no output schema, the description provides sufficient context: purpose, usage, glob support, resolution order, and safety (read-only). The schema covers all parameters.
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 coverage is 100%, so the schema already documents parameters well. The description adds value by explaining the resolution order and tying parameters to the overall purpose (e.g., 'see all locations' for all_locations).
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: finding the first match for a resref or seeing all locations. It specifies support for glob patterns and resolution order, effectively distinguishing it from siblings like 'kotor_extract_resource' or 'kotor_search_resources'.
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 says 'Use when you need the first match for a resref or to see all locations,' providing clear usage context. It doesn't mention when not to use it or alternatives, but the differentiation from sibling tools is 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?
With no annotations provided, the description carries full burden. It clearly states the tool is 'Read-only; returns plain text (no ANSI).' This informs the agent that no modifications occur and output format is plain text, which is sufficient for a read-only analysis tool.
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 two sentences: the first defines purpose and output, the second provides usage context and behavioral info. Every sentence adds value, and critical information is front-loaded. 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 simplicity (3 parameters, no output schema), the description adequately covers what the tool does, what it returns (text diagram with specific elements), and when to use it. The return format is specified as plain text, which is sufficient for agents to understand the 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?
Schema coverage is 100%, with all three parameters described in the schema. The description adds no new meaning beyond the schema; it merely restates the default for use_color. Thus a baseline of 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 tool retrieves a text validation diagram for a walkmesh (BWM/WOK), listing specific components (perimeter, transitions, outer boundary). It distinguishes itself from sibling tools, which are other resource query tools, by its unique focus on walkmesh validation.
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 includes explicit usage context: 'Use when you need to understand an area's walkable layout, door links, or boundary for modding or debugging.' It implies the tool is for analysis, not modification, but does not explicitly state when not to use it or list alternatives.
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?
No annotations provided, so description bears full burden. It explicitly states 'Read-only', which is a key behavioral trait. However, it does not disclose other potential behaviors such as error handling or performance characteristics.
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 consists of two sentences with no extraneous information. It is front-loaded with the primary use case and includes only essential behavioral context (read-only).
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 is a simple read-only lookup with 5 parameters and no output schema, the description is adequate for a competent agent. It covers purpose and safety. It does not describe the return format, but the tool's name and sibling context imply typical result behaviors.
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?
All 5 parameters have descriptions in schema (100% coverage). The description adds value by summarizing the three query modes (row index, column, value search), which helps the agent understand how to combine parameters effectively.
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?
Description clearly states the tool queries a 2DA table by row index, column name, or value search. The verb 'query' and resource '2DA table' are specific. It also notes the tool is read-only, helping distinguish it from potential siblings like 'kotor_read_2da'.
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?
Directly says 'Use when you need to query a 2DA table', providing a clear when-to-use scenario. However, it does not mention when not to use it or explicitly compare to siblings like 'kotor_read_2da' or 'kotor_lookup_tlk'.
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?
Description discloses read-only behavior and hints at large response sizes by advising to use field_paths/max_depth/max_fields to stay under limits. Since no annotations are provided, the description carries the full burden, and it adequately covers behavioral aspects without contradictions.
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?
Three sentences, front-loaded with purpose, then parameter guidance, then read-only flag. No unnecessary words; every sentence adds 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?
The tool has no output schema, so the description should clarify what is returned. It states 'full GFF tree as JSON', which is sufficient. It advises on handling large responses, contributing to completeness. A minor gap could be explaining that GFF is a nested structure, but not essential.
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 coverage is 100%, so baseline is 3. Description adds value by explaining the purpose of optional parameters (field_paths, max_depth, max_fields) in the context of response limits, going beyond the schema's individual 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?
Description clearly states verb 'read' and resource 'GFF tree as JSON', lists example resource types (DLG, UTC, ARE), and distinguishes from sibling tools by specifying it returns the full tree.
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?
Explicitly states when to use: 'when you need the full GFF tree as JSON'. Provides guidance on using field_paths, max_depth, and max_fields to stay under limits. Does not explicitly mention alternatives or when not to use, but sibling tool names like kotor_describe_dlg imply alternatives exist.
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 labels the tool as 'Read-only', which clarifies it does not modify state. This is sufficient since no annotations are provided. It could elaborate on what 'candidate' means, but the safety profile is clear.
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 two sentences, each serving a distinct purpose: usage guidance and behavioral note. It is front-loaded with the key verb and resource, with 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 has no parameters, no output schema, and no annotations, the description provides all necessary context: when to use, what it does, and its read-only nature. It is complete for the tool's simplicity.
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 zero parameters, and schema description coverage is 100%. The description does not need to add parameter details. Baseline score of 4 is appropriate for a parameterless tool.
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 explicitly states the tool discovers candidate K1/K2 installation paths using environment variables and platform defaults. The verb 'discover' and resource 'installation paths' are specific, and it differentiates from sibling tools like loadInstallation or getInstallationGraph.
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 begins with 'Use when you need to discover candidate K1/K2 installation paths', providing explicit use context. However, it does not mention when not to use it or point to alternative tools for related operations like loading or snapshotting.
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?
No annotations provided, so description carries burden. It declares 'Read-only,' a key behavioral trait. Lacks details on side effects, auth, or error behavior, but for a listing tool this is adequate.
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?
Two sentences, no wasted words. First sentence states purpose and usage context, second adds behavioral trait. Efficient and front-loaded.
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 simple tool with one parameter and no output schema, the description fully covers purpose, usage, and behavioral context. No 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 coverage is 100% with one parameter 'game' described as 'Game alias: k1 or k2.' Description adds no further context beyond the schema, meeting baseline but not exceeding.
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 lists all modules with human-readable area names, which distinguishes it from sibling tools that might list modules differently or without readable names.
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?
Explicitly specifies when to use: when you need all modules with human-readable area names. Also implicitly indicates when not to use (e.g., if you need to modify) by noting 'Read-only'.
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:

[![KotorMCP MCP server](https://glama.ai/mcp/servers/oldrepublicwizard/KotorMCP/badges/card.svg)](https://glama.ai/mcp/servers/oldrepublicwizard/KotorMCP)

Score Badge

Copy to your README.md:

[![KotorMCP MCP server](https://glama.ai/mcp/servers/oldrepublicwizard/KotorMCP/badges/score.svg)](https://glama.ai/mcp/servers/oldrepublicwizard/KotorMCP)

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/oldrepublicwizard/KotorMCP'

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