SAMP-MCP

Server Quality Checklist

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

Latest release: v1.0.10
Disambiguation2/5
Many tools have unclear boundaries, such as compile_pawn vs compile_and_load_pawn, get_status vs get_dashboard, read_server_log vs search_server_log vs get_server_diagnostics, and generate_boilerlate vs get_snippet. The setup/guidelines tools (set_server_root, setup_ai_environment, aaa_mandatory_read_first_guidelines) also overlap in purpose, making misselection likely.
Naming Consistency4/5
The vast majority follow a consistent verb_noun snake_case pattern (get_players, read_server_cfg, install_plugin, audit_script), which makes the suite predictable. Minor deviations like player_action and aaa_mandatory_read_first_guidelines introduce slight inconsistency but do not break the overall convention.
Tool Count2/5
With 53 tools, the surface is far above the 25+ threshold and feels bloated for an agent to navigate. Several tools could be consolidated, such as merging audit variants, setup/guideline tools, and overlapping read/diagnostics tools.
Completeness4/5
The domain coverage is impressively complete: server config, logs, player management, RCON, Pawn compilation/editing with encoding safety, backups, audits, plugin/include management, deployment, and feature workflow are all represented. Minor gaps exist (no uninstall plugin/include, no file delete/rename, no backup pruning), but there are no critical dead ends.
Average 3.6/5 across 53 of 53 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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 only says 'Read', which implies a non-destructive operation, but it does not explain whether the file is decoded, whether 'Thai support' affects output, what happens if the file is not found, or what the return value contains. The 'Thai support' hint suggests some special behavior but is not elaborated.
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 and immediately conveys the core action and target resource. It is concise and front-loaded, though the '(Thai support)' parenthetical is vague and does not fully earn its place without explanation.
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 simple single-parameter read tool, the description gives the essential invocation context. However, with no output schema and no annotations, the agent is left without details about return format, error behavior, or encoding quirks suggested by 'Thai support'.
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% for the single parameter 'name', including an example value. The description adds no new parameter meaning, but the baseline of 3 is appropriate because the schema already documents the parameter sufficiently.
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 states a clear verb ('Read'), a specific resource type ('.inc file'), and a location ('include directories'), which distinguishes it from broader file-reading tools like read_pawn_script. However, the parenthetical '(Thai support)' is ambiguous and does not clearly differentiate it from reading other include-related 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?
No explicit guidance is given about when to use this tool versus alternatives such as read_pawn_script, list_includes, or install_include. The phrasing implies it is for .inc files in include directories, but there are no stated conditions, exclusions, or sibling references.
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 responsibility for disclosing behavior. It only says the tool gets statistics; it does not mention whether it queries a remote server, whether it is read-only, what format the result takes, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core purpose with minimal waste. The examples in parentheses add useful specificity without bloating the description.
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 simple status-read tool, the description is minimally adequate, but it lacks any mention of return shape, optional-address behavior, or how this differs from the many diagnostic siblings. The absence of an output schema increases the need for a bit more 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?
There is only one parameter, and the input schema already fully documents it as an optional host:port to override the project server. The description adds no additional meaning about 'address' beyond what the schema provides, so the baseline of 3 applies.
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 identifies a specific verb ('Get') and resource ('current server statistics') and gives concrete examples (hostname, players, map). However, it does not distinguish this from the sibling get_server_diagnostics, whose name suggests a potentially overlapping purpose.
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?
There is no guidance on when to prefer this tool over alternatives such as get_players, get_rules, or get_server_diagnostics. The description implies a basic status check but offers no exclusions or comparison clues.
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 the full burden of behavioral disclosure. It only states the operations without mentioning the impact of stopping/restarting a live server, potential downtime, required permissions, or whether the action returns any feedback. This is a mutation tool, and the description does not warn about consequences beyond the literal action.
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 short sentence that communicates the tool's full purpose with no filler. Every word is necessary and the key actions are front-loaded. It is appropriately sized for a one-parameter tool with an explicit enum.
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 one-parameter enum tool with no output schema, the description covers the basic calling contract. However, it lacks operational context: no mention of side effects, expected return value, or any caution around restarting a production server. Given the tool can disrupt server availability, the description should at least hint at that context, making it minimally adequate rather than fully complete.
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%: the single parameter is fully documented with an enum and a description. The tool description merely repeats the enum values ('Start, Stop or Restart') without adding new meaning, so the 3 baseline for high schema coverage applies. It adds no extra syntax or semantic nuance beyond what the schema already provides.
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 states a clear action set (Start, Stop, Restart) applied to a specific resource (SAMP server process). It distinguishes this tool from siblings like get_status or audit_performance because it directly manages the server lifecycle rather than observing it. Slight deduction for using the broad verb 'manage' rather than a more specific verb, but the enumerated actions remove ambiguity.
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 given about when to use this tool versus alternatives such as get_status or get_server_diagnostics. The description simply states what it does and offers no contextual cues, prerequisites, or exclusions. An agent is left to infer that any start/stop/restart need should route here, but the description never explicitly says that.
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 entire burden. It only states that the tool searches two named sources; it does not disclose result format, pagination, failure modes, freshness, or whether the search is live or cached. 'Search' implies read-only behavior, but little else is 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?
A single front-loaded sentence states the action, target sources, and purpose with no filler or redundancy. Every word contributes to understanding.
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 one-parameter search tool with full schema coverage, this is minimally viable, but the lack of an output schema and annotations leaves uncertainty about return values and limitations. The description does not explain how results are presented or how this search differs from other search tools.
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 single 'query' parameter is already documented as 'Search keywords'. The description adds only that results target official SAMP Wiki and Forum Archive content, which is useful but does not materially expand parameter meaning 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 a specific action ('Search') and a specific resource ('official SAMP Wiki and Forum Archive') for a defined purpose ('information/examples'). It does not explicitly differentiate from sibling search tools like web_search or search_pawn_script, but the named resource makes the scope reasonably distinct.
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?
There is no guidance on when to use this tool versus sibling alternatives such as web_search, search_pawn_script, or search_server_log. The description implies it is for SAMP-related external documentation, but it never states exclusions or selection criteria.
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 carry the full behavioral burden. It states the scanning intent and implies a read-only operation, but it does not disclose output format, handling of comments or string delimiters, duplicate handling, or behavior on parse errors. This is a gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the core operation in the first sentence. The second sentence adds a practical use case. No filler or redundant material is present, though it is slightly thin on behavioral detail.
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 one-parameter, no-output-schema tool, the description conveys the basic operation and a use case. However, it does not explain what the tool returns (e.g., list format, deduplication, positions) or any edge-case behavior, leaving some uncertainty for an agent invoking it blind.
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 'path' parameter adequately. The description adds only general context ('script') and does not introduce any additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (scan) and resource (script) and clearly identifies the output (all string literals). It is distinguishable from related tools like read_pawn_script or inspect_project by focusing on string literal extraction, though it does not explicitly name a sibling.
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 gives a usage context ('useful for localization or cleanup') but does not explicitly state when to use this tool over alternatives like search_pawn_script or audit_script, nor does it mention any exclusions or limitations such as file type restrictions.
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 disclosing behavioral traits. It implies a read-only diagnostic operation but does not explicitly state that it performs no modifications, what it scans, how deep the analysis goes, or what the output looks like. For a tool with no annotation safety hints, this is a meaningful gap.
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?
A single, front-loaded sentence that directly states the tool's job and includes useful examples. Every word contributes; there is no fluff or redundant schema repetition.
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 parameterless tool, the description is reasonably complete, but with no output schema and no annotations, there is no explanation of the diagnostic report format, scope of logs analyzed, or operational side effects. The examples help, but the absence of any return-value or behavioral context leaves the agent with moderate uncertainty about what invoking the tool actually produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so there is no parameter information missing. Although the description does not add parameter-level detail, none is required; the baseline of 4 for no-parameter tools applies.
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 states a clear verb ('Analyze'), a specific resource ('server logs'), and an intended outcome ('common issues'), with concrete examples like Crash signatures and Plugin load failures. It is sufficiently distinct from the read/search log siblings because it frames the action as diagnostic analysis rather than raw retrieval, though it does not explicitly contrast with audit_performance.
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?
There is no guidance on when to use this tool versus the many related sibling tools such as read_server_log, search_server_log, or audit_performance. The description implies the tool is for diagnosis, but it does not state conditions, exclusions, or alternatives, leaving the agent to infer the appropriate 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, the description must disclose behavior on its own. It says 'temporary', which hints at non-persistent effects, but it does not state whether the injected code is executed, whether it can disrupt a running server, whether cleanup occurs, or whether the operation is reversible. For a tool that injects arbitrary Pawn code, this lacks the safety-relevant behavioral detail an agent needs.
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 with no wasted words. It front-loads the action ('Create a temporary Filterscript'), then names the mechanism ('compile it'), and finishes with the contextual tag 'Hot Injection'. Every word carries meaning.
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 code-injection tool with no annotations and no output schema, the description is too thin. It omits important contextual details: whether the server must be running, what effect the compiled script has after injection, whether the temporary script is cleaned up, and what risks or side effects may occur. The single-parameter schema is well documented, but the operational context is incomplete.
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% for the single 'code' parameter, and that schema description already states 'Pawn code to inject into OnFilterScriptInit'. The tool description does not add further parameter semantics, so the baseline score 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 uses a specific verb ('Create') and resource ('temporary Filterscript'), and adds a distinct mechanism ('compile it (Hot Injection)'). Among siblings this is the only tool described as creating a temporary script for injection, which clearly separates it from compile_pawn, write_pawn_script, and compile_and_load_pawn.
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 given for when to use this tool versus alternatives. The description does not mention trade-offs, prerequisites (such as a running server), or cases where a persistent script or regular compile would be preferable. The parenthetical 'Hot Injection' implies a runtime use case, but no explicit usage direction is provided.
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 only says a command is executed via RCON and does not mention potential side effects, permission requirements, safety implications, or whether commands may alter server state.
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. It efficiently states the operation and target, making it appropriately concise for a simple one-parameter tool.
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 the simple schema, the lack of annotations and output schema means the description should provide more context about return values, side effects, and operational risk. It currently gives an agent little basis to predict what happens when the command is executed.
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 already covers the single 'command' parameter with 100% coverage and an example. The description adds no additional semantic detail beyond the schema, so the baseline score 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?
States a specific verb ('Execute') and resource ('a command on the SAMP server via RCON'). This clearly identifies what the tool does and differentiates it from sibling read/audit/config tools by naming the RCON execution channel.
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 given about when to use this tool versus alternatives. With many siblings like player_action, manage_server, and read_server_cfg, the description does nothing to help an agent choose between them.
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 carries the full burden. It does disclose the specific behavioral focus (checking for missing %e in mysql_format), which is useful. However, it does not state whether the scan is read-only, whether it scans the entire script or only relevant sections, or what the output looks like.
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?
A single, well-structured sentence that immediately states the tool's purpose and the specific risk it detects. There is no wasted wording, and the key information is front-loaded.
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 simple one-parameter tool, the description is mostly sufficient. However, with no output schema, it does not explain what the agent should expect in the response (e.g., list of findings, pass/fail status). It also doesn't clarify the boundary between this tool and audit_script, which could cause mis-selection.
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 the only parameter 'path' described as 'Path to the script file'. The description's phrase 'Scan a script' reinforces this but adds no meaning beyond the schema. Baseline 3 is appropriate when the schema already documents the parameter sufficiently.
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 states a specific verb ('Scan') and resource ('a script') and narrows the purpose to SQL Injection risks, specifically missing %e in mysql_format. It is clear about what the tool does, though it does not explicitly contrast itself with the similarly named sibling audit_script.
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?
There is no guidance on when to use this tool versus alternatives like audit_script or audit_performance. The intended use case is implied by the name and description, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does add value by stating the return format (structured error/warning list), which is useful. However, it does not disclose potential side effects such as whether an .amx output file is produced, whether existing artifacts are overwritten, or whether external dependencies (like include paths) are required.
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 with zero filler: the first states the action and toolchain, the second states the return behavior. The key information is front-loaded and every word 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?
For a simple one-parameter tool this is mostly adequate: it states the action, the compiler used, and the return value. However, with no output schema, no annotations, and an ambiguous sibling (compile_and_load_pawn), the description should have addressed side effects (e.g., generated .amx file) and the selection boundary between the two compile siblings. These gaps leave an agent to guess.
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 single 'path' parameter is already documented as the path to the .pwn file. The description's mention of compiling a '.pwn script' somewhat reinforces the schema but adds no additional semantic detail about path format, expected extension handling, or constraints. Baseline 3 is appropriate when the schema handles the parameter documentation.
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 uses a specific verb ('Compile') with a clear resource ('.pwn script using pawncc.exe') and states the return type (structured error/warning list). It is clear and unambiguous about the operation, though it does not explicitly distinguish itself from the closely-related sibling compile_and_load_pawn.
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 about when to use this tool versus compile_and_load_pawn, which is the obvious alternative. The description implies usage context ('compile a .pwn file') but never states exclusions, prerequisites, or selection conditions. An agent must infer the distinction between compiling-only and compile-and-load on its own.
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 the behavioral disclosure burden. It signals a read-only snapshot via 'Get' and 'summary,' and 'real-time' adds useful freshness context. However, it does not disclose output shape, failure behavior, or whether the dashboard data is aggregated or raw.
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 no filler. The resource ('dashboard') and primary concepts ('real-time summary,' 'server health, players, and performance') are front-loaded and immediately actionable.
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 simple read-only tool with one optional parameter and no output schema, the description is mostly sufficient. Still, given the large sibling set and the lack of return-format or selection guidance, an agent would benefit from additional context about what the returned summary contains and when this tool is the right choice.
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 already documents the only parameter fully with a clear description, so the parameter semantics burden is already met. The tool description adds no additional parameter-level meaning, making the baseline 3 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 states a clear verb ('Get') and resource ('dashboard'), and specifies the content as a real-time summary of server health, players, and performance. It is distinguishable from many siblings, though it overlaps somewhat with get_status, get_players, and get_server_diagnostics in 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?
There is no guidance on when to prefer get_dashboard over the many related inspection tools such as get_status, get_server_diagnostics, or audit_performance. The description implies a general dashboard use case but provides no exclusions or alternative routing.
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 carries the full burden. The verb 'Get' and the word 'current' imply a read-only, point-in-time query, and the parenthetical clarifies scope, but no additional behavioral traits are disclosed such as side-effect guarantees, failure behavior, or output format. It is minimally transparent 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, front-loaded sentence with no filler. The parenthetical examples add useful specificity without bloating the text, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, zero-required tool this is mostly adequate, but there is no output schema and no usage guidance, so the agent is left to guess the return structure and when to prefer this over comparable tools. The examples partially compensate but do not fully cover the missing 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%, and the only parameter, 'address', is already well documented as 'Optional host:port to query instead of the project server'. The description adds no additional parameter meaning, so the baseline score of 3 applies.
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 states a specific verb ('Get') and resource ('current server rules') with concrete examples ('gravity, weather, version'), so the agent can tell what the tool acts on. It does not explicitly differentiate from close siblings like get_status or get_server_diagnostics, so it misses the extra point for 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?
The description gives no guidance on when to use this tool versus alternatives such as get_status or get_server_diagnostics, and it states no prerequisites or exclusions. It merely states what it does, which is insufficient for choosing 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?
With no annotations provided, the description carries the behavioral disclosure burden. The verb 'get' implies a read-only retrieval and 'code snippet' suggests the return value, which provides basic transparency. However, it does not disclose whether this pulls from local resources, requires network access, or has any notable limitations.
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, front-loaded with the action and object, and contains no filler or redundant phrasing. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is mostly sufficient: it names the output type and the category domain. Still, with no output schema and no usage guidance, the description leaves return format and selection criteria implicit, so the agent must infer some details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the single 'category' parameter with an enum of values and a description. The description adds loose examples like MySQL and Login that map to the enum values, but it does not meaningfully expand parameter meaning beyond what the schema already provides.
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 and resource: getting a common SAMP code snippet. It gives example content areas like MySQL and Login, which helps an agent understand the tool's scope, though it does not explicitly differentiate it from similar snippet-generation siblings like generate_boilerplate or get_essential_libraries.
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?
There is no guidance on when to use this tool versus alternatives such as generate_boilerplate, get_coding_standards, or search_samp_resources. The description provides no context about use cases, exclusions, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does disclose the core behavior: an external GitHub lookup that returns repos and binaries, which implies a non-mutating read. However, it does not address network dependency, rate limits, result volume, or empty-result behavior, which a search tool over an external API would benefit from disclosing.
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 totaling roughly 14 words, with the purpose front-loaded and zero filler. Every word contributes either the search scope, the matching mode, or the return content.
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?
With no output schema and no annotations, the description must explain return values, and it does so only at a high level ('repos and available release binaries'). An agent cannot tell what result fields are available (repo URLs, stars, download links) or how results might feed into siblings like install_plugin; acceptable for a one-parameter tool, but with clear 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 'name' parameter already documented by concrete examples ('YSF', 'streamer', 'mysql'). The phrase 'by name' merely restates what the schema conveys, so the description adds no meaningful semantic detail beyond the high-coverage schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and a clear resource ('SAMP plugins on GitHub'), and states the by-name search mode along with what is returned (repos and release binaries). It is sufficiently distinct from siblings like web_search and search_samp_resources via the GitHub scope, though it never names those alternatives explicitly.
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?
There is no when-to-use or when-not-to-use guidance. Closely related siblings such as search_samp_resources, install_plugin, and web_search exist, but the description does not say how search_plugin relates to them or when to prefer one over another; the usage context is only implied by the purpose sentence.
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 does not state whether this operation is read-only, whether it requires special permissions, whether it queries a live server, or whether the 'current' list may be cached or delayed. The description is minimal and does not reveal behavioral traits beyond 'current list'.
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 focused sentence that clearly states the purpose and the exact output fields, with no filler or redundancy. It is appropriately sized for a simple read-only listing tool.
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 one optional parameter and no output schema, the description provides the essential return information (ID, Name, Score, Ping) and the core action. It could be marginally improved with usage context, but the tool is simple enough that this is largely complete.
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 only parameter, address, has 100% schema description coverage: 'Optional host:port to query instead of the project server.' The tool description does not mention the parameter, but the schema fully explains it, so the baseline of 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 uses a specific verb ('Get') and a specific resource ('current list of players'), and explicitly lists the returned fields (ID, Name, Score, Ping). This clearly distinguishes it from siblings like player_action or get_status, leaving no ambiguity about what the tool does.
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 about when to use this tool versus alternatives. The description does not mention use cases, exclusions, or how it differs from similar calls such as get_status or player_action. The intended usage is only implicit from the tool name and simple description.
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 full behavioral disclosure burden. It mentions config detection and project tracking, which adds some context, but does not explain side effects, persistence, prerequisites, or what 'tracks' means in practice.
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, focused sentence that front-loads the main purpose and adds the config-detection detail economically. There is no filler or 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?
The tool is important for establishing project context, but the description omits useful contextual details such as whether the path must already exist, how host override relates to config detection, and what observable result confirms the root was set. It is minimally sufficient but leaves meaningful 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%, so the schema already documents both path and host clearly. The description adds no additional meaning for either parameter, keeping it at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool points the MCP server to a SAMP project directory and mentions automatic config detection. It names a specific verb and resource, but does not explicitly differentiate it from sibling tools like setup_ai_environment or manage_server.
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 intended use is implied: the tool is for setting/selecting the project root before other project operations. However, it provides no explicit when-to-use guidance, no exclusions, and does not name alternative tools that might be more appropriate in certain situations.
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 the full burden for behavioral disclosure. It reveals that the operation mutates the server installation via NPM, but does not disclose side effects like service restarts, downtime, modification of server state, or potential breakage.
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 concise sentence that packs the verb, object, and method without waste. Every word contributes meaning and the key mechanism is front-loaded.
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?
Although the tool is parameter-free, it is a mutating self-update with no annotations and no output schema. The description does not explain the expected outcome, post-conditions, or whether the operation is safe to run in a running server environment, so relevant context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and the schema covers 100% of the (empty) parameter space, so there is no parameter information for the description to supplement. The baseline of 4 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 states a specific verb ('self-update'), the target ('SAMP-MCP server'), and mechanism ('via NPM'), which clearly identifies the operation. It also distinguishes itself from sibling tools like check_for_updates and update_server_cfg without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, whether to check for updates first, or how it relates to sibling tools such as check_for_updates. The agent is left to infer usage context entirely from the tool's name and mechanism.
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 scan action but does not confirm whether it is read-only, how it reports results, what scope 'the project' covers, or whether it has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear, front-loaded, and contains no wasted words. Every word contributes to explaining the tool's core function.
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 zero-parameter diagnostic tool, the description is minimally viable, but it lacks details about return values, project scope, and whether the scan is recursive or limited to certain file types. Without an output schema, some explanation of the result shape would improve completeness.
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, so the description has no parameter semantics to add. The baseline score of 4 applies because no documentation burden exists for parameters.
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 states a specific verb ('Scan'), resource ('the project'), and expected finding ('#include statements that point to missing files'). It clearly differentiates from siblings like list_includes by focusing on missing files rather than listing all includes.
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 given on when to use this tool versus list_includes, read_include, or compile_and_load_pawn. The intended context is only implied by the verb 'scan', with no explicit exclusions or alternative recommendations.
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 disclosing side effects. It states files are copied, but does not mention whether existing files in the output directory are overwritten, whether the directory is created if missing, or what the tool returns after completion. This is a meaningful gap for a mutating 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, front-loaded sentence that names the action, the file types, and the destination without any filler. Every word carries meaning, and no irrelevant details are included.
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 is simple (one required parameter, no output schema), so the description covers the core action, but it leaves out important execution context such as prerequisites, whether the output directory is prepared automatically, and what a successful run looks like. An agent could call it correctly but may not understand the full impact or preconditions.
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 parameter semantics are already fully documented by outputDir's description. The tool description adds no new information about the parameter itself, matching the baseline of 3 for high schema coverage.
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 a specific verb phrase ('Batch copy') and clearly identifies the resource ('all necessary server files (AMX, Plugins, CFG)') and the destination ('a distribution folder'). This clearly distinguishes it from siblings such as compile_and_load_pawn or manage_server, which do different things.
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 the tool is for creating a deployment package by copying files, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. There is no direct 'when to use' or 'when not to use' guidance, only an implied context.
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 only mentions the output type but does not disclose side effects, whether a file is written, whether it is read-only, or what the generated markdown contains beyond the ambiguous 'commands and dialogs.'
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?
A single, direct sentence with no filler or redundant wording. It front-loads the action and clearly states the deliverable.
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 zero parameters and no output schema, the description is moderately complete for a simple generator tool. However, with no annotations or output schema, it leaves uncertainty about whether the tool writes to disk, returns the markdown, or requires any prior setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since the tool does not accept input.
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 action ('Generate'), the resource ('a markdown summary'), and the scope ('all commands and dialogs in the project'). It is specific enough to distinguish itself from sibling tools such as generate_boilerplate or inspect_project.
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?
There is no guidance about when to use this tool over alternatives, no mention of whether the project must be configured first, and no exclusions or conditions. The description simply states what it does, 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 carries the burden. 'Get a list' implies a read-only operation, and 'from GitHub topics' surfaces an external data source. However, it does not mention potential network dependency, rate limits, failure modes, or what the returned items look like.
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. It efficiently conveys the verb, resource, quality filter, and source in under twenty 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 zero-parameter read-only lookup, the description gives enough context to invoke the tool: it returns a list of curated SA-MP libraries/plugins sourced from GitHub topics. It does not describe the exact return fields or network expectations, but these are minor gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the schema already fully documents the input surface. The description adds no parameter details, but none are required; this is the baseline-4 case for no-parameter tools.
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 a list'), the resource ('SA-MP libraries and plugins'), and the quality filter ('high-quality, popular'). It does not explicitly contrast with siblings like search_samp_resources, so it lacks full sibling differentiation, but the purpose is unmistakable.
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?
There is no guidance on when to use this tool versus alternatives such as search_samp_resources, search_plugin, or install_plugin. The word 'essential' implies a curated starting point, but this is left implicit rather than 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?
Annotations are entirely absent, so the description carries the full burden of disclosing behavior, but it only states the object and location. It doesn't say whether the operation is a non-destructive live filesystem scan, whether subdirectories are recursed, whether results are cached, or what happens when the paths don't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with the verb front-loaded and no filler; every word contributes either the action, the object, or the scope. Nothing could be trimmed without losing information.
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?
Adequate for a zero-parameter listing tool, but 'other common paths' is undefined and, with no output schema present, the return format (absolute vs. relative paths, recursive or not) is never addressed. An agent must guess at these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline of 4 — there are no parameter semantics for the description to document. The description goes slightly beyond the empty schema by clarifying what the tool targets (.inc files in specific paths).
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 names a specific verb ('List'), a concrete resource ('.inc files'), and scoped locations ('pawno/include and other common paths'). This is enough to distinguish it from file-domain siblings like read_include (reads one file), check_includes (validates includes), and install_include (adds an include).
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 when-to-use guidance or exclusions are given. The tool sits among a crowded cluster of include- and file-related siblings (check_includes, read_include, install_include, list_server_files), so an agent gets no help deciding to choose this one over them.
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 identifies the action types but does not explain consequences, reversibility, required permissions, RCON availability, or what happens after the action is performed. For potentially disruptive operations like ban and mute, this is a notable gap.
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. It names the operation, target, method, and supported actions compactly, and every word contributes meaning.
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 simple two-parameter tool with complete schema coverage, the description is minimally adequate: an agent can determine what to call and with what arguments. However, because there is no output schema and no annotation coverage, the lack of information about execution results, side effects, and administrative requirements leaves clear 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?
The input schema already provides full descriptions for both parameters, including an enum for 'action' and a clear definition for 'player'. The description adds RCON context but does not clarify player ID formats, whether the player name must be exact, or how action-specific requirements might differ.
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 names a specific action ('Perform a quick RCON action'), a target ('a player'), and enumerates the exact operation types ('kick, ban, mute'). This clearly identifies what the tool does and naturally distinguishes it from the broader server-management 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 word 'quick' implies this is for lightweight, direct player actions, but the description does not explicitly state when to choose this over alternatives or when not to use it. No sibling tools or exclusion conditions are mentioned, so usage guidance remains 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that a key is updated, but does not cover what happens if the key does not exist, whether other keys are preserved, whether changes require a restart, or any permission implications. For a mutation tool, this leaves significant ambiguity.
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 with no filler. It front-loads the action, names the resource, and immediately clarifies scope with examples. Every word contributes.
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 simple two-parameter mutation tool, the description is mostly adequate, especially with full schema coverage. However, there is no output schema and no annotations, so the agent is left wondering about return values and edge-case behavior such as unknown keys or save semantics. These gaps are notable but not fatal given the tool's low 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?
The schema already documents both parameters with high coverage (100%). The description adds only examples like 'hostname' and 'maxplayers' without enriching the semantics of 'key' or 'value'. This meets the baseline for schemas that carry the parameter documentation 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 identifies a specific action ('update'), the target resource ('server.cfg'), and the scoped semantics ('a specific key'), with concrete examples. This distinguishes it from sibling tools like read_server_cfg and write_server_cfg without needing to open schemas.
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 targeted config updates, and 'specific key' hints at the distinction from whole-file operations, but it never explicitly states when to use this tool versus alternatives like write_server_cfg or set_server_root. No exclusion criteria or decision guidance is 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, the description carries the behavioral disclosure burden. 'Scan' suggests a read-only static analysis, and the examples make the behavior concrete, but it never explicitly states whether the file is modified, what the return value looks like, or whether external resources are needed. This is adequate but 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?
The description is a single, front-loaded sentence with no filler. Every element earns its place: the action, the accepted file types, the purpose, and concrete examples of issues detected.
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 one-parameter tool, this description is mostly sufficient to invoke it, but the absence of an output schema and annotations leaves the return format and side-effect profile unspecified. An agent knows what to scan, but not precisely what to expect back or whether the operation is safe.
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 schema already describes 'path' as 'Path to the script file to audit', so the baseline is 3. The tool description adds meaningful file-type constraints by specifying .pwn or .inc scripts, which is useful context not present in the schema itself.
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 states a specific action ('Scan'), a clear resource ('.pwn or .inc script'), and concrete examples of what it finds ('Large arrays, Hardcoded IDs'). It is clear enough to distinguish from reading or compiling scripts, though it does not explicitly contrast with the closely named sibling audit_performance.
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 purpose statement implies this tool is used when an agent needs to audit a Pawn script for issues, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives like audit_performance or read_pawn_script. The usage context is present only by implication.
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 must carry the behavioral burden. The verb 'Scan' implies a read-only analysis and 'potential' accurately suggests heuristic reporting, but the description does not explicitly state that no files are modified, whether includes are followed, or whether findings are returned as a list, message, or diff.
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-formed sentence that front-loads the core action and subject, then adds a clarifying example in parentheses. There is no redundant wording or filler.
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?
This is a low-complexity tool with one required, fully documented parameter and no output schema or nested structure. The description plus schema gives an agent enough to select and invoke the tool for the stated purpose. A brief note on the return format or side-effect-free behavior would make it fully complete, but the low complexity lowers the burden.
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 fully describes the only parameter ('path') as the path to a script file, so the description adds little beyond saying the file is a script. This meets the baseline for full schema coverage but does not enrich the parameter meaning 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 identifies a specific action ('Scan a script') and a specific resource type ('script') with a clear purpose: detecting potential variable shadowing, and gives a concrete example ('redefining playerid'). It is clear and distinct from generic peers such as audit_script, though it does not explicitly name a sibling alternative.
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 intended use is implied: call this when you want to detect variable shadowing in a single script. However, there is no explicit guidance on when not to use it, what limitations exist, or which sibling tool (e.g., audit_script, search_pawn_script, get_function_body) might be more appropriate for broader or different analysis.
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 carries the behavioral burden. It usefully discloses two non-obvious behaviors: automatic Thai project detection and the instruction not to translate generated Thai strings. It does not describe the output format, but this is a low-risk generation 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?
Two short sentences deliver the core purpose and the critical behavioral constraint without any filler. The key action is front-loaded, and the DO NOT TRANSLATE warning is placed second for emphasis.
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 two-parameter generation tool with full schema coverage, the description is largely sufficient. It captures the main behavior and the Thai-specific caveat; only a brief note about what the generated snippet contains or returns is missing.
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%, and both parameters have meaningful descriptions and an enum. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies.
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 a specific verb and resource: 'Generate SAMP code snippets.' The input schema further clarifies the snippet types, but the description does not differentiate this tool from the sibling get_snippet, so it stops short of 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?
No guidance is given about when to use this tool versus alternatives like get_snippet or transform_pawn_script. The description implies it is for generating new SAMP code, but it provides no when-to-use/when-not-to-use context or named alternatives.
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 must carry the behavioral burden. It does state the operation is a read and that only the last N lines are returned, which is a useful behavioral trait. However, it omits any details about return format, error behavior, or whether the tool is fully read-only in practice beyond the word 'read'.
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?
A single, tight sentence that states the verb, target, and scope with no filler or redundancy. The most important information is front-loaded and every word contributes.
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 one-parameter, schema-covered read operation this is nearly complete. The absence of an output schema is mitigated by describing the result as lines. The main gap is the lack of guidance about when to prefer search_server_log, but the tool's simplicity keeps this from being a major defect.
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%: the only parameter, limit, is documented as 'Number of lines to read'. The description adds no new parameter semantics beyond mapping 'N' to this limit, so the baseline of 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 uses a specific verb ('Read'), a precise resource ('SAMP server_log.txt'), and a clear scope ('last N lines'). This distinguishes it from sibling tools like search_server_log and read_server_cfg without needing to open either schema.
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 gives no guidance on when to use this tool versus alternatives. Given a sibling search_server_log exists that is likely better for pattern-based log investigation, the description should at least hint at the difference, but it does not.
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 implies an overwrite of the current file with backup content but never warns that unsaved changes since the latest backup will be lost, nor does it state what happens if no backup exists. For a mutation operation, this is a significant disclosure gap.
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 with zero filler. The main action is front-loaded ('Restore a .pwn/.inc file from its latest backup'), and the second sentence adds the key usage context. Both sentences earn their 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 no annotations and no output schema, the description should explain what the agent can expect after the call: success outcomes, error conditions (e.g., backup not found), and whether a preceding list_backups is needed. None of this is present. The 'undo' framing helps, but the tool remains under-specified for correct invocation in a real workflow.
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% for both parameters (path, backupName). The description mirrors the schema by mentioning 'latest backup' vs 'specific backup,' which maps cleanly to omitting or supplying backupName. It adds no detail beyond the schema, so the 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 uses a specific verb ('Restore') and identifies the exact resource ('.pwn/.inc file' from backup). It clearly distinguishes itself from sibling file tools by framing it as 'undo' when a write goes wrong, which sets it apart from write_pawn_script and read_pawn_script without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: 'Use this as undo when a write goes wrong.' This gives clear context for invocation. It does not name alternative tools or state when not to use it, so it falls short of a 5, but the use case is unmistakable.
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 must disclose side effects itself; it does convey that this is a full-file overwrite via 'entire', which is the main destructive trait. However, it does not mention permissions, prerequisites (e.g., set_server_root), backup behavior, validation, or error handling.
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?
A single sentence, front-loaded with the verb and scope, with no filler. Every word contributes to meaning, and the redundancy is minimal.
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 destructive write tool with no annotations and no output schema, this is thin: it omits required setup (such as the server root having been set), safety warnings, and expected outcomes. An agent could call it without knowing whether the current config should be preserved or whether a server restart 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 coverage is 100%, and the 'content' parameter already has a description ('Full content of the server.cfg file'). The tool description adds no additional parameter semantics; it restates the entire-file scope already present in 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?
The description uses a specific verb ('Write/Update') and a specific resource ('the entire SAMP server.cfg configuration file'), making the operation unmistakable. The word 'entire' distinguishes it from partial-config or command-level tools like rcon_command.
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?
No alternative tools are mentioned, and there is no explicit when-to-use or when-not-to-use guidance. The word 'entire' weakly implies this is for full-file replacement rather than single-setting changes, but the agent is left to infer that from sibling names.
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 carries the burden of behavioral disclosure. It transparently conveys that the tool performs a network download and writes to pawno/include. However, it does not disclose whether an existing file is overwritten, whether the URL is validated, or what happens if the download or installation fails.
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?
A single sentence with no filler: it names the action, source, file type, and destination. Every word contributes meaning, and the key details are front-loaded.
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 simple two-parameter tool without an output schema, the description covers the core call requirements (URL, name, destination). Still, it leaves out potentially important context such as whether the operation overwrites existing includes, any return/confirmation format, or whether a server root must be set beforehand—gaps an agent might need to probe.
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 both 'url' and 'name' already well-described. The tool description adds meaningful context by clarifying that the URL should point directly to a .inc file (e.g., GitHub raw) and that the file lands in pawno/include, but this is supplementary rather than essential given 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 a specific action ('Download and install a .inc library from a URL') and the target destination ('into pawno/include'). It differentiates from sibling tools like install_plugin by specifying .inc libraries rather than plugins, and from read_include/list_includes by focusing on installation rather than inspection.
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: it is the tool to use when you need to fetch and install an include from a remote URL. However, it does not explicitly state when to prefer it over alternatives such as install_plugin or read_include, nor does it mention any exclusions or prerequisites like needing a configured server root.
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?
There are no annotations, so the description must carry the burden of explaining behavior. It states the search action but does not disclose whether it returns full matching lines, whether the search is case-sensitive, how the limit affects the search, or what happens when no matches are found. The read-only nature is implied but not explicit.
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 part contributes: the action, the resource, and illustrative keyword examples.
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 is simple and the schema covers both parameters, so the description is nearly adequate. However, it does not specify the output format (e.g., matching lines vs. counts), the fact that only the last `limit` lines are scanned, or any guidance on fallback tools if the keyword is not found.
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 schema already documents query and limit. The description adds value by giving concrete example values for query ('Error', 'Crash', 'Failed'), which helps an agent understand what kind of keywords are expected.
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 states a specific action ('Search for specific keywords') and a specific resource ('server_log.txt'), with concrete example keywords. This clearly differentiates it from the sibling read_server_log, which reads the log rather than filtering by keyword.
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: use this tool when you need to find specific terms like 'Error', 'Crash', or 'Failed' in the server log. However, it does not explicitly state when to choose this tool over read_server_log or other log-related siblings, nor does it provide exclusion criteria.
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 burden of explaining side effects. The verb 'Scan' reasonably implies a read-only analysis, and the examples clarify what the tool inspects. However, it does not explicitly state that the script is not modified, whether compilation is involved, or what the return value looks like. Some important behavioral context is missing.
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, efficiently worded sentence that front-loads the action and resource before giving clarifying examples. There is no filler, and every part of the sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is largely complete: it states what the tool does and the kind of issues it finds. It would benefit from explicitly confirming that the scan is non-destructive and from indicating what kind of result is returned, but these gaps are minor 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?
The input schema fully documents the 'path' parameter with the description 'Path to the script file', so schema coverage is 100%. The tool description adds no additional parameter semantics, such as path format, file extension expectations, or whether relative paths are supported. A baseline score of 3 is appropriate because the schema already covers the parameter adequately.
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 names a specific action ('Scan a script'), specifies the resource ('a script'), and states the exact focus ('potential performance issues'). It gives concrete examples (fast timers, heavy OnPlayerUpdate logic), which makes the tool's purpose clear and easily distinguishable from sibling tools like audit_script or audit_sql.
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 when to use this tool: when performance issues in a script are suspected. However, it does not explicitly state when not to use it, nor does it mention alternatives such as audit_script for a broader audit. The usage context is understandable but left implicit.
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 carries the full behavioral burden. It does clarify that the tool checks NPM for a new version, but it does not disclose whether network access is required, whether the operation is side-effect-free, or what happens when no update is found.
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?
A single, front-loaded sentence states the essential action and target with no filler. Every word contributes meaning, and the description is appropriately sized for such a simple tool.
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 zero-parameter, no-output-schema utility check, the description is largely complete: it identifies the target and the action. It could additionally state what kind of result the agent should expect, but the core invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already covers all of them (100% coverage), so the baseline of 4 applies. The description adds no parameter information, which is appropriate since there are no parameters to document.
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 states a specific verb ('Check if') and a specific resource ('a new version of SAMP-MCP on NPM'). It clearly communicates a read-only availability check and is distinguishable from sibling tools like update_mcp_server without needing to open any schema.
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 given about when to use this tool versus alternatives, nor does it mention that this only checks while update_mcp_server actually performs the update. The intended usage is only implied by the action itself.
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 the full burden. 'Get a summary' implies a read-only operation and describes the type of output, but it does not disclose whether the tool scans files, how costly it might be, or whether it has side effects beyond simply reporting. Still, it is clearly a read-style 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?
A single sentence with no filler, front-loading the main action and then naming the specific summary contents. Every word contributes to understanding.
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 zero-parameter tool with no output schema, the description does enough by stating what kind of summary will be returned. It could be slightly more explicit about what 'project size' and 'command/dialog counts' refer to, but the invocation is simple and clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain about parameters. The description is free to focus on behavior and output, which it does.
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 names a specific operation ('Get a summary') and a clear resource ('the project'), with explicit metrics: project size, line counts, and estimated command/dialog counts. This differentiates it from the more operational sibling tools like get_status or audit_performance.
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 gives no guidance about when to use this tool versus alternatives, and it names no sibling tools or exclusion conditions. With 50+ siblings, a brief usage hint would meaningfully improve the definition.
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 carries the full burden of behavioral disclosure, and it does warn that the server will restart—a critical side effect. It also uses 'attempt to load', which hints that loading may fail, but it does not explain what happens on compile failure or whether restart occurs regardless.
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 short sentences with no filler; the core action is front-loaded and the restart warning is included without redundancy. Every sentence contributes actionable information.
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 one-parameter tool with high schema coverage, the description covers the essential action and the major side effect. It is less complete on failure semantics and the expected outcome of the load attempt, and it does not cross-reference the compile_pawn sibling, leaving some operational context missing.
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% and the single scriptPath parameter is already thoroughly described as the path to the .pwn file. The tool description adds no further parameter-level detail, so the baseline score 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 opens with a specific verb-resource pair, 'Compile a Pawn script and attempt to load it into the server', which clearly states what the tool does. The restart warning further separates it from the sibling compile_pawn, making the tool's intent unambiguous.
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 makes the tool's function clear and implies it should be used when compilation and live loading are both desired, which is enough to distinguish it from compile_pawn. However, it never explicitly names an alternative or states when not to use it, leaving the choice to inference.
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 full burden. It states the matching behavior and file-type scope, but does not disclose whether the search is recursive, what directory it searches, whether it is case-sensitive, or that it is strictly read-only. This is adequate for a simple find tool but leaves 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?
Two sentences with zero wasted words: the first states the action and scope, the second gives the when-to-use context. 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?
For a 2-parameter tool with no output schema, the description covers purpose and usage but omits the return format and search scope. The absence of annotations increases the need for behavioral details, which are only partially present.
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%; both 'name' and 'maxResults' are documented in the input schema. The tool description adds no parameter details beyond what the schema already provides, so the baseline of 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 uses a specific verb and resource types ('.pwn/.inc/.cfg') and describes the matching method ('partial name match'). This clearly distinguishes the tool from sibling tools like list_server_files and read_pawn_script.
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 second sentence gives a concrete use case: 'Useful when you can't remember the exact file path.' It does not explicitly name alternatives or exclusions, but this context is clear enough for an agent to decide when to invoke it.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. It usefully reveals encoding preservation and the no-translation requirement, but it does not state whether the source file is modified, whether an existing target file is overwritten, or what happens on failure.
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 three short sentences, each earning its place: the core action with an example, the Thai-project usage requirement, and the no-translation constraint. There is no filler or redundancy.
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 core action, parameters, and Thai-specific constraints are present, which is enough for a straightforward invocation. However, with no output schema and no annotations, the description should say a bit more about target file creation/overwrite behavior and what the tool returns.
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 Juice/Watermelon example reinforces the oldTheme/newTheme relationship, but the description does not add meaningful parameter semantics beyond what the schema already documents.
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 names a concrete action ('Clone and refactor a script') and clarifies the transformation with the example 'Juice -> Watermelon'. This is clearly distinct from sibling read/write/search/compile tools, so an agent can tell what this tool does without opening the schema.
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?
It explicitly states a mandatory usage context: 'MANDATORY for Thai projects to preserve encoding,' which tells the agent when to use this tool. It also adds a critical constraint ('DO NOT TRANSLATE Thai strings'), but it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the transformation (UTF-8 to Windows-874) and the triggering symptom, but does not state whether the file is modified in place, whether a backup is created, or how it behaves when the file is already correctly encoded.
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 with no filler: the first states the action and resource, the second explains the exact failure scenario and target encoding. The key information is front-loaded and every clause contributes.
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 single-parameter utility with no output schema, the description adequately covers purpose, trigger condition, and conversion target. It omits only minor details like success/error response format and handling of files that are already valid.
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 only parameter, path, is already fully described in the schema as 'Path to the corrupted file'. The description adds useful context about file types and the corruption scenario but does not define path conventions such as absolute vs relative paths, so it adds limited value over 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 is verb-first ('Fix'), names a specific resource (.pwn/.inc file), and specifies the exact operation: converting mis-encoded UTF-8 Thai text back to Windows-874. It is clearly distinguishable from sibling file tools like read_pawn_script or compile_pawn.
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 gives an explicit trigger condition: use when another AI saved Thai text as UTF-8, causing garbled characters. It does not name alternative tools or state when not to use it, but the scenario is specific enough to guide selection among the file-related 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?
With no annotations, the description carries the full behavioral burden. 'Get' clearly implies a read-only operation, but the description does not disclose output format, possible failure modes, or prerequisites beyond the current connection to a SAMP project. This is acceptable for a simple getter but not highly 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?
The description is a single focused sentence with no filler. It is front-loaded with the action and clearly states the resource and scope.
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 no-parameter read tool, the description is largely complete: an agent can invoke it without further clarification. The main gap is the lack of explicit detail about what the returned 'coding standards and patterns' will look like, especially since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so the parameter baseline is already high. The description still adds useful context by scoping the result to the 'currently connected SAMP project,' which helps the agent understand what implicit context is used.
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 'Get' with a clear resource: 'coding standards and patterns for the currently connected SAMP project.' This distinguishes it from sibling tools like get_rules, get_status, or read_pawn_script, and gives the agent a precise idea of what the tool returns.
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 intended use is implied: call this when you need the project's coding standards or patterns. However, there is no explicit guidance about when not to use it, what it should be preferred over, or how it relates to other inspection tools in the sibling list.
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 carries the burden and does disclose the main side effects: downloading/installing a plugin and updating server.cfg. It does not mention whether existing plugin files are overwritten, how server.cfg is modified, or any permission/restart requirements—traits that would be useful for a mutating network/download action.
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 with no filler. The core action and side effect are front-loaded, and the accepted input formats are stated compactly in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a fully documented schema, this is reasonably complete: it names the action, the side effect on server.cfg, and the accepted URL/repo formats. Because there is no output schema, it could have described return/error behavior, but that does not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter descriptions already document the GitHub repo/direct URL format and example names. The tool description adds no new per-parameter meaning beyond restating these formats, so it stays at the baseline.
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 opens with a specific verb and resource: 'Download and install a SAMP plugin (.dll/.so) and update server.cfg.' It also clarifies accepted sources ('GitHub repos' vs 'direct download URLs'), making it distinguishable from sibling tools like install_include or search_plugin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for installing binary SAMP plugins and updating server.cfg. It doesn't explicitly name alternatives or exclusion conditions, but the '.dll/.so' qualifier and the server.cfg side effect convey when it should be selected over install_include or config-editing 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?
No annotations are provided, so the description carries the behavioral burden. 'List' implies a read-only operation, but the description does not explicitly state that it does not modify files, nor does it mention any permissions or operational constraints. This is adequate but 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?
A single sentence that is concise, front-loaded, and free of fluff. It efficiently communicates the full purpose and the filtering behavior.
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 listing tool with one optional parameter, the description is largely complete. The only notable gap is the lack of any detail about the backup return format, but this is minor given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the path parameter already has a clear description. The tool description reinforces that omitting the path covers all files, which adds slight context, but most parameter meaning is already in 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 states a specific action (list), a clear resource (backups), and the scope (a specific file or all files in the project). It is immediately distinguishable from sibling tools like restore_pawn_script or list_server_files.
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 clearly indicates when to use the tool and how to narrow scope via the path parameter. It does not explicitly mention alternatives or when not to use it, but the use case is simple and unambiguous.
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 present, so the description carries the full burden of behavioral disclosure. It states that files are listed but does not say whether the listing is recursive, whether directories are included, whether hidden files are returned, or what the response format looks like. This leaves notable ambiguity for an agent invoking the 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?
Two short sentences communicate the operation, the resource, and the intended use case with no redundancy. The key behavior is front-loaded and every part 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?
For a one-parameter listing tool, the description is mostly complete: it identifies the subdirectory target and the purpose. The absence of an output schema means return details are unstated, but the nature of 'list files' makes the expected result reasonably inferable.
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 schema already describes 'subdir' as 'Subdirectory to list', and the tool description adds meaningful examples and purpose by naming gamemodes, plugins, include, and the search for .pwn/.inc source files. This helps the agent construct valid 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 uses a specific verb and resource: 'List files in a SAMP server subdirectory' with concrete examples like gamemodes, plugins, and include. It also states the intended use case of finding .pwn and .inc source files, clearly distinguishing this from other file content tools.
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 tells the agent when to use this tool: to find source files in a SAMP server subdirectory. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a simple listing operation among many file-oriented 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?
With no annotations provided, the description must carry the behavioral transparency burden. The verb 'Read' clearly indicates a non-destructive operation, but no additional behavior is disclosed, such as whether raw file contents are returned, file path expectations, or error behavior. It is minimally transparent but not richly so.
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 with no wasted words. It is front-loaded with the action and resource, 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?
For a zero-parameter read-only tool, this description is mostly complete. It identifies the exact file to read and implies the return of its contents. A more explicit statement about the return format or file location would be marginally helpful, but is not essential for such a simple operation.
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 properties, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, this is appropriately handled; the description does not need to explain parameters that do not exist.
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 states a specific verb ('Read') and a specific resource ('the SAMP server.cfg configuration file'). This clearly distinguishes it from write-oriented siblings like write_server_cfg and update_server_cfg, and from read_server_log which targets a different file.
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 context of reading a configuration file is clear, but there is no explicit guidance about when to choose this tool over siblings such as read_server_log or the write/update config tools. Usage is implied rather than directly stated.
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 present, so the description carries the behavioral transparency burden. 'Verify' implies a read-only check, but the description does not explicitly state side effects, failure behavior, or return format.
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 one sentence with no filler and places the trigger condition first. This is appropriately sized and front-loaded.
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 schema fully documents both parameters, and the simple verification scope is clear. Without an output schema or annotations, an explicit statement of read-only behavior and expected return would improve completeness, but the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema, so the baseline is 3. The description adds only that filesModified are the 'expected files' whose existence is checked, which is a modest semantic addition.
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 verb 'verify' names the action, and the object is specific: the plan checklist and the existence of expected files. It also scopes usage to 'after implementing a feature,' which clearly separates it from audit/compile/read siblings.
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 provides a temporal trigger: after implementing a feature. It does not name alternative tools or exclusion rules, but the trigger is sufficient to select this tool in the design_feature-to-implementation workflow.
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 the behavioral burden. It conveys that this is a read-only web look-up action, but it does not mention response format, network dependency, rate limits, or search limitations. The behavior is simple and low-risk, so a middle score is appropriate.
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 short sentences, front-loaded with the core action, followed by concrete examples of queries. Every line earns its place with no redundant detail.
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 one required string parameter, a documented optional domain parameter, and no nested or output schema, the description is sufficient for an agent to decide when to call it. It could mention what kind of results are returned, but the current framing gives enough 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%, and both parameters (query and domain) are already well described with examples in the input schema. The description adds no additional parameter semantics, so the baseline of 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?
States a specific verb and resource: 'Search the web for general information.' The SA-MP examples make its scope concrete and clearly separate it from server-local search siblings like search_server_log or search_pawn_script.
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?
Gives clear context for when to use it—answering questions about SA-MP versions, plugins, and game mechanics. It does not explicitly name alternatives or exclusions, but the intended use case is apparent.
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 the full burden and does disclose important behavior: encoding/language safety, corruption risk with standard tools, and the critical line-replacement semantics (only startLine replaces only that single line, not to end of file). It could also mention permission requirements or whether files are created if missing, but the most safety-critical behaviors are surfaced.
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 fairly compact and front-loads the most critical instruction ('MANDATORY'). Both sentences carry operational value. The all-caps emphasis is a bit noisy, and the single-line behavior is stated twice, but there is no filler and the key warning is impossible to miss.
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 5-parameter write tool with no output schema, the description plus fully-covered schema equips an agent to invoke it correctly: required path/content, optional line replacement caveat, encoding override, and full-file overwrite behavior (in schema). It does not discuss return values, but that is not critical for a write operation. The main missing element is a direct statement about what happens on success or failure.
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 already has 100% parameter coverage, so the baseline is 3. The description goes beyond the schema by explicitly warning that startLine and endLine must both be provided when doing a range replacement and clarifying that startLine alone replaces only one line. This is a valuable semantic clarification that prevents misuse.
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 identifies the target resource type (.pwn/.inc files) and states this is the safe, intended tool for handling them, distinguishing it from standard file tools. It does not explicitly say 'writes a file', but the tool name plus 'use this for .pwn/.inc files' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong when-to-use guidance: 'MANDATORY: ALWAYS use this for .pwn/.inc files' and warns that 'Standard tools WILL corrupt files'. It implies when not to use standard tools, and the .pwn/.inc scoping differentiates it from sibling write tools like write_server_cfg. It doesn't enumerate sister alternatives explicitly, but the instruction is exclusions enough.
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 carries the full behavioral burden, and it discloses meaningful traits: it.is a retrieval operation ('Returns'), the rules are authoritative ('mandatory'), and calling order matters ('Call this FIRST'). It also scopes the content to 'this specific SAMP project.' It does't explicitly state that it is side-effect-free or describe failure behavior, but those are minor for a read-only, 0-param 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?
A single 17-word sentence with the critical directive 'CRITICAL: Call this FIRST' front-loaded ahead of the resource description. Every word earns its place; there is no redundancy or filler.
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 0-parameter, no-output-schema tool, the description is nearly complete: it tells the agent when to call ('FIRST'), what it will receive (encoding and language rules), and the scope (this SAMP project). The only minor gap is that it does't describe the format of the returned rules, but the return value is the content itself and the description already identifies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts 0 parameters, so the baseline 4 applies and there are no parameter semantics for the description to clarify. The schema is already empty with 100% coverage, so nothing parameter-related is missing 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 uses a specific verb ('Returns') with a concrete resource: 'the mandatory encoding and language rules for this specific SAMP project.' It clearly states what the tool does and scopes it to the current project. It doesn't explicitly contrast with siblings like get_coding_standards, but the 'Call this FIRST' directive and 'aaa_' name prefix set it apart as the mandatory entry-point tool.
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 instruction 'CRITICAL: Call this FIRST.' provides explicit ordering guidance, making this a prerequisite before any sibling project tools are used. It does't name alternatives or state when not to use it, but for a 0-parameter guideline-retrieval tool the first-call directive is unambiguous and actionable, matching 'clear context, no exclusions.'
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 carries the full burden. It discloses that the tool writes two files and affects AI-agent behavior (tool usage and encoding). However, it omits important behavioral traits such as whether it overwrites existing files, whether it is idempotent, or whether it depends on set_server_root being configured first.
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, tightly front-loaded with the mandatory marker, then the concrete action, target, and rationale. Every clause earns its place; no filler or redundant restatement of the tool name.
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 zero-parameter setup tool, the description covers the core what and why, but it leaves meaningful gaps: no mention of prerequisities like set_server_root, no overwrite or re-run behavior, and no output/return information. Since there are no annotations or output schema, those gaps are not filled elsewhere.
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 is empty and the tool has zero parameters, so there is no parameter documentation burden. The description still usefully identifies the target context ('your SAMP server root') without needing to explain any input fields.
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 a specific verb and resource: 'install .cursorrules and SAMP_RULES.md into your SAMP server root.' It also explains the downstream effect on AI agents, making it easy to distinguish from sibling install/plugin/include tools. The 'MANDATORY SETUP' prefix reinforces its role as an initialization step.
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 labels the call as 'MANDATORY SETUP', giving the agent clear context that this is a required setup action before normal work. It does not mention alternatives or exclusions, but the mandatory framing is strong enough to signal when to use it.
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 present, the description carries the full behavioral burden. It discloses the key behaviors: the plan is 'shown to the user inline for review' and the agent must 'WAIT for explicit user confirmation before writing code.' This effectively communicates that the tool is non-implementing and gated on user approval, though it stopsshort of stating explicit side-effect or return-value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, and the most important instruction is front-loaded. Each sentence adds distinct value: when to use it, what it produces, and the critical wait-for-confirmation behavior.
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 planning-only tool, the description captures the essential workflow: generate plan, display it, wait for confirmation. It does not specify what happens after confirmation or describe output structure, but the absence of an output schema is partially mitigated by the statement that the plan is shown inline.
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 adequately describes all three parameters. The description does not add parameter-specific meaning beyond that, but the baseline of 3 is appropriate because no compensation is necessary.
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 a specific verb phrase 'create a structured plan with edge case analysis' tied to a clear resource ('new system'), and explicitly places it before implementation. This clearly distinguishes it from the many sibling tools that actually write, compile, or modify code.
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 opening 'Before implementing ANY new system' gives a clear, explicit trigger condition for when this tool should be used. It does not name specific alternative tools or list when-not-to-use cases, but the context strongly implies this is the planning gate before any implementation work.
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 carries the behavioral burden. It clearly discloses the read-only extraction behavior and what is returned ('only the function code with optional doc comments'), plus a performance trait. It does not mention failure behavior when the function is absent, but for a straightforward read operation the core behavior is 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?
Three tightly written sentences, each earning its place: first identifies the operation, second gives the efficiency rationale, third specifies the exact return contents. No filler or 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?
For a simple extraction tool with no annotations and no output schema, the description covers purpose, return scope, efficiency benefit, and optional doc comments. The main omission is behavior when the function name is not found, but the overall context is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters. The description adds minimal extra semantic value beyond echoing 'by name' and 'doc comments.' Baseline 3 is appropriate because the schema does the heavy lifting.
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?
States a specific verb ('Extract') plus resource ('complete body of a function by name from a .pwn/.inc file'), and explicitly differentiates from reading the entire file. This distinguishes it from sibling read tools without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Much more efficient than reading the entire file' gives clear contextual guidance for when to choose this tool over a full-file read. It does not name alternatives like search_pawn_script or get_snippet, nor provide explicit when-not conditions, so it stops short of a 5.
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 carries the full behavior burden. It discloses the key safety trait (`ONLY safe way to handle encoding and language`) and the corruption risk of alternatives, plus the optional line-range behavior. It doesn't mention the return format or that the operation is read-only, but the tool's name and the lack of mutation imply enough for most agents.
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?
Four short, purposeful sentences. The mandate is front-loaded, the warning is concrete, and the optional range feature is stated in a single clause. There is zero filler or repetition of schema content.
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 relatively simple file-read tool with four parameters and no output schema, the description covers the essential selection, safety, and capability information. A brief statement of the return value would have made it complete, but that omission is minor given the name and the rest of the definition.
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. The description adds that paths should be .pwn/.inc files and that line ranges are optional, but it doesn't deepen the semantics of `encoding` or `path` beyond what the schema states. This is a solid baseline with minor added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description makes it unmistakable that this tool reads .pwn/.inc files, with `MANDATORY: ALWAYS use this for .pwn/.inc files` and a mention of optional line-range reading. It distinguishes itself from generic or sibling readers by warning that standard tools will corrupt these files and by scoping to Pawn script/extensions.
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 gives explicit when-to-use guidance (`ALWAYS` for .pwn/.inc) and an explicit exclusion (`Standard tools WILL corrupt`). It doesn't directly contrast with the sibling `read_include`, but the mandatory phrasing covers the main selection scenario, leaving only a minor gap for alternative-sibling routing.
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 carries the full burden. It discloses the search scope, the output format (file paths, line numbers, context), and the efficiency advantage over reading files. While it does not mention every edge behavior, it is transparent enough for a non-destructive search operation and does not contradict any annotation.
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 concise sentences, front-loaded with the core action and scope. Every sentence earns its place: what it searches, what it returns, and why it is preferred over reading files. No filler or repetition.
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 description covers the tool's purpose, scope, and return values, and the schema handles all parameters. No output schema exists, so the stated return format is valuable. It could be slightly more complete by naming sibling alternatives, but an agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents query, maxResults, and contextLines. The description adds no extra parameter meaning, but none is needed because the schema covers semantics. 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 states a specific verb ('Search') and resource (text inside .pwn/.inc files) with scope ('across the entire project'). It also explains what is returned: file paths, line numbers, and surrounding context. This clearly distinguishes it from file-reading tools like read_pawn_script.
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 'Much more efficient than reading entire files' gives direct guidance to prefer this tool over read_pawn_script for locating text. The .pwn/.inc scope and project-wide search imply when it applies, though it does not explicitly exclude sibling tools like search_server_log or fuzzy_find_file. Clear context, but no formal when-not guidance.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KongGithubDev/SAMP-MCP'

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