一个 MCP (Model Context Protocol) 服务器，为 AI 助手提供可靠、结构化的 Multi Theft Auto: San Andreas 文档访问权限。
它结合了快速关键词搜索、语义匹配和基于 SQLite 的缓存，使智能体能够发现正确的 API 并获取权威文档，而无需手动抓取 Wiki。
11 个用于发现、文档检索、缓存操作和工作流指导的 MCP 工具
事件优先发现 (search_events, find_events_for_task)
基于 SQLite 向量搜索的语义任务匹配
智能关键词扩展 (例如，database -> db* API)
内置弃用检测和警告
具有可配置生命周期的本地 SQLite 缓存
CI 验证门控、冒烟测试和发布自动化
Related MCP server: Documentation Retrieval MCP Server (DOCRET)
要求：
Node.js 24+
Bun 1.3+ (可选运行时)
pnpm 10+ (用于本地开发)
启动器说明：
您可以通过 npx、pnpx、bunx 或 yarn dlx 风格的流程启动/安装。
运行时支持跨运行时：Node.js (通过 node:sqlite) 和 Bun (通过 bun:sqlite)。
npm install -g mtasa-docs-mcp或者：
pnpm add -g mtasa-docs-mcp
git clone https://github.com/Luminaire1337/mtasa-docs-mcp.git
cd mtasa-docs-mcp
pnpm install
pnpm build如果您的环境跳过了可选的本地依赖项，请运行：
pnpm install --force全局：~/.cursor/mcp.json
项目：.cursor/mcp.json
{
"mcpServers": {
"mtasa-docs": {
"command": "npx",
"args": ["-y", "mtasa-docs-mcp"]
}
}
}工作区：.vscode/mcp.json
用户：命令面板 -> MCP: Open User Configuration
{
"servers": {
"mtasa-docs": {
"command": "npx",
"args": ["-y", "mtasa-docs-mcp"]
}
}
}或者通过终端添加：
code --add-mcp "{\"name\":\"mtasa-docs\",\"command\":\"npx\",\"args\":[\"-y\",\"mtasa-docs-mcp\"]}"claude mcp add-json mtasa-docs '{"type":"stdio","command":"npx","args":["-y","mtasa-docs-mcp"]}'全局配置文件：~/.config/opencode/opencode.json
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"mtasa-docs": {
"type": "local",
"command": ["npx", "-y", "mtasa-docs-mcp"],
"enabled": true
}
}
}配置文件：~/.gemini/antigravity/mcp_config.json
{
"mcpServers": {
"mtasa-docs": {
"command": "npx",
"args": ["-y", "mtasa-docs-mcp"]
}
}
}{
"mcpServers": {
"mtasa-docs": {
"command": "node",
"args": ["/absolute/path/to/mtasa-docs-mcp/build/index.js"]
}
}
}如果 mtasa-docs-mcp 已经发布，请将命令替换为：
{
"mcpServers": {
"mtasa-docs": {
"command": "npx",
"args": ["-y", "mtasa-docs-mcp"]
}
}
}search_functions
search_events
find_functions_for_task
find_events_for_task
get_function_docs
get_multiple_function_docs
get_function_examples
list_functions_by_category
get_cache_stats
recommend_doc_workflow
clear_cache
pnpm build
pnpm test
pnpm test:runtime
pnpm smoke
pnpm smoke:cross-runtime
pnpm verify
pnpm verify:full有用的检查：
pnpm check:versions - 保持 package.json 和 MCP 服务器版本一致
pnpm check:changelog - 确保 CHANGELOG.md 具有当前发布标题
pnpm check:tool-names - 防止遗留工具命名回归
pnpm test:runtime - 运行 Node 和 Bun 冒烟路径的集成运行时测试
pnpm smoke:cross-runtime - 针对 Node 和 Bun 运行时运行冒烟检查
脚本位于 scripts/ (构建、冒烟、发布防护)。
发布自动化由 .github/workflows/release.yml 处理。
在 package.json 和 src/index.ts 中提升版本号。
使用 ## [x.y.z] - YYYY-MM-DD 将发布说明从 Unreleased 移动到 CHANGELOG.md 中的版本化部分。
创建并推送发布标签：git tag v<version> && git push origin v<version>。
分支策略：
v1.0.0 之前：允许直接推送到 master。
从 v1.0.0 开始：所有对 master 的更改均使用基于 PR 的开发。
在发布标签推送 (v*.*.*) 时，发布工作流会：
检查版本是否已存在于 npm 上
运行 pnpm verify:full
使用受信任的发布 (OIDC) 将带有来源证明的包发布到 npm
使用 GitHub OIDC 将 server.json 发布到 MCP 注册表
从 CHANGELOG.md 创建/更新 GitHub Release
验证已发布包的可安装性并运行冒烟测试
在 npm 包设置中，为此存储库和工作流配置受信任的发布者：
存储库：Luminaire1337/mtasa-docs-mcp
工作流文件：.github/workflows/release.yml
环境 (如果使用)：匹配您的 GitHub Actions 配置
确保 server.json 存在于存储库根目录并使用此包名称：mtasa-docs-mcp
为 io.github.Luminaire1337/mtasa-docs-mcp 配置 MCP 注册表所有权
发布工作流使用 mcp-publisher login github-oidc，并且仅在 npm 发布门控通过时才发布
.github/workflows/ci.yml - 推送/PR 到 master 时的验证 (Ubuntu + macOS)，以及标记 PR 上的可选实时 Wiki 集成测试
.github/workflows/release.yml - 发布标签 (v*.*.*) 时的自动发布和 GitHub Release
AGENTS.md - 架构和贡献者指南
FEATURES.md - 路线图和想法
CHANGELOG.md - 发布历史
SECURITY.md - 漏洞披露政策
GNU 通用公共许可证 v3.0。请参阅 LICENSE。
Clear the MTA:SA documentation cache for a specific function or all functions.
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | Function name to clear cache for, or 'all' to clear everything |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of behavioral disclosure. It states 'clear the cache' which indicates a destructive action, but does not elaborate on side effects, reversibility, scope (global vs. session), or any warnings about data loss. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that communicates the essential purpose. It is appropriately concise, but could include additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain what the tool returns (e.g., success message, count of cleared entries) or any confirmation of the operation. Given the lack of an output schema, this omission leaves the agent uncertain about the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter. The description adds no substantive new meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: clearing the MTA:SA documentation cache for a specific function or all functions. It distinguishes itself from sibling tools which focus on searching, listing, or getting documentation, not cache management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies its use case (cache clearing), but does not mention prerequisites, when not to use, or alternative approaches like refreshing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Task-to-events matcher. Use when you need event names for handlers/triggers (e.g., resource lifecycle, player joins, marker hits). Returns ranked MTA:SA events only.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes | Description of the event workflow you need (e.g., 'when player joins', 'resource start', 'on marker hit') | |
| side | No | Filter by client-side or server-side events | |
| limit | No | Maximum number of suggestions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Returns ranked MTA:SA events only' without detailing ranking logic, side effects, permissions, or other behavioral traits beyond a basic hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loads the purpose with 'Task-to-events matcher', and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description only hints at return format ('ranked MTA:SA events'), which is somewhat sufficient for a simple retrieval tool but lacks details on ranking and result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no new meaning beyond what the schema already provides for each parameter, meeting the baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'Task-to-events matcher' with concrete examples ('resource lifecycle, player joins, marker hits') and distinguishes from siblings like search_events and find_functions_for_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when you need event names for handlers/triggers', providing context but no explicit when-not-to-use or alternative tools, though sibling names imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Task-to-functions matcher. Use this FIRST when user intent is high-level (e.g., 'vehicle dealership', 'login panel'). Returns ranked MTA:SA functions/events optimized for follow-up documentation retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes | Description of what you want to accomplish (e.g., 'login system', 'spawn vehicle', 'create gui window') | |
| limit | No | Maximum number of suggestions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions it returns 'ranked MTA:SA functions/events optimized for follow-up documentation retrieval', implying no side effects. However, it does not disclose potential performance considerations or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and usage guidance. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, usage, and return type for a simple search tool. However, lacks explicit mention of output format (e.g., list of function names) but is sufficient given context of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description re-emphasizes task_description for high-level intent but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a 'task-to-functions matcher' with specific verb and resource. It distinguishes from siblings by emphasizing use for high-level intent and returning ranked results, contrasting with sibling tools like find_events_for_task or search_functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Use this FIRST when user intent is high-level', providing concrete examples ('vehicle dealership', 'login panel'). This clearly differentiates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about the MTA:SA documentation cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. It does not disclose whether this is a lightweight read operation or if it has side effects. However, the name implies a safe get operation, making it minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states purpose with no extra words. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should describe what statistics are included (e.g., caching timestamps, entry counts). It lacks this detail, reducing completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with no parameters, baseline is 3. Description adds no detail about what statistics are returned, missing an opportunity to clarify the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves statistics about a specific cache, using a specific verb and resource. It distinguishes itself from sibling tools like clear_cache or search functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not indicate that it's for monitoring cache health or that it should be polled sparingly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch authoritative docs for exactly ONE MTA:SA function/event by canonical name. Preferred over manual web browsing. For multiple names, use get_multiple_function_docs in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | Function/event name (case-insensitive) | |
| use_cache | No | Whether to use cached documentation | |
| include_optional_arguments | No | Whether to include optional arguments in the parameters section |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It implies a read-only operation ('Fetch authoritative docs') but does not explicitly state whether it modifies state, requires authentication, or has rate limits. It lacks details about error handling or behavior for invalid names, but the safety profile is generally inferable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. All sentences add value: purpose, preference, and sibling guidance. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about output format, error handling, caching behavior (despite a cache parameter), and prerequisites. For a simple lookup tool, the missing information is moderate. No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters having descriptions. The description does not add extra meaning beyond what the schema already provides for each parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches docs for exactly one MTA:SA function/event by canonical name, and distinguishes from the sibling 'get_multiple_function_docs' by specifying the single-name scope. It also positions itself as preferred over manual browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this for single names and to use get_multiple_function_docs for multiple names. Also advises it's preferred over manual web browsing, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get only code examples for one function/event after docs lookup. Use when writing implementation snippets and tests.
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | Function/event name (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it is read-only and returns code examples, but does not disclose behavior on missing functions or rate limits. Adequate for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no wasted words. The purpose is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is sufficient for an agent to understand the tool's purpose and appropriate use. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter function_name is described in the schema. The description adds that it is case-insensitive, which is valuable beyond the schema definition. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves only code examples for a specific function/event, distinguishing it from sibling tools like get_function_docs. It explicitly mentions the use case: after docs lookup for writing snippets and tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context ('when writing implementation snippets and tests') and implies it follows a docs lookup. It does not explicitly exclude alternatives, but the phrasing is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch docs retrieval for implementation phase. Provide exact function/event names (ideally from search/find tools) and get combined authoritative docs in one response.
| Name | Required | Description | Default |
|---|---|---|---|
| function_names | Yes | Array of function/event names to fetch | |
| include_examples | No | Whether to include code examples | |
| include_optional_arguments | No | Whether to include optional arguments in each parameters section |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lacks behavioral details like response format, error handling, rate limits, or the authoritative source. Only mentions 'combined authoritative docs' but doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and usage hint. Could be structured slightly better but remains clear and succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description partially covers return value ('combined authoritative docs') but lacks details on response structure or error scenarios. Adequate for a batch retrieval tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining that function_names should be exact names from search/find tools and that include_examples and include_optional_arguments control documentation detail. This context aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'batch docs retrieval for implementation phase' with specific verb and resource. It distinguishes from siblings like get_function_docs (single) and search_functions (searching) by emphasizing batch and exact names from search/find tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description hints at when to use ('implementation phase', 'from search/find tools') but does not explicitly state when not to use or compare with alternatives like get_function_docs, get_function_examples, or recommend_doc_workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate canonical function/event names in a category. Useful for discovery when query terms are vague.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The category to list functions from | |
| limit | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the tool is read-only, has side effects, or requires authentication. While listing is likely safe, the description relies on inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the primary action, with no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for this simple list tool, given the schema covers both parameters. It differentiates from sibling tools and is adequate for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond what the schema provides for 'category' and 'limit'; the schema already sufficiently describes their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Enumerate canonical function/event names in a category', with a specific verb (enumerate) and resource (canonical function/event names in a category), distinguishing it from sibling tools that search or find specific functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Useful for discovery when query terms are vague', which helps an agent know when to choose this tool, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Planner tool that tells LLMs exactly which mtasa-docs tools to call next for a given task. Use this to enforce MCP-first workflows and avoid manual wiki scraping.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes | What the user wants to build or debug | |
| known_function_names | No | Function names already known in the conversation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states the tool 'tells' which tools to call, implying a read-only recommendation, but does not disclose any potential side effects, authentication needs, or output format. For a tool with no annotations, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous words. The first sentence conveys core functionality, the second gives usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters (1 required), no output schema, and no annotations, the description is largely complete. It explains the tool's role and when to use it. However, it lacks details on the output format or how recommendations are presented, which could help an agent understand the tool's behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptions for both parameters. The tool description does not add meaning beyond what the schema provides: 'task_description' is for user's task, 'known_function_names' for already known names. Baseline 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a planner that tells LLMs which mtasa-docs tools to call next for a given task. It uses specific verb 'tells' and resource 'which tools to call', distinguishing it from sibling tools which are individual doc retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to enforce MCP-first workflows and avoid manual wiki scraping', giving clear usage context. It implies when to use but does not explicitly state when not to use or mention sibling alternatives, though its unique role as a planner makes alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Event discovery tool. Search MTA:SA client/server events only (not regular functions), then chain into docs tools with exact event names.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Event name or keyword to search for | |
| side | No | Filter by client-side or server-side events | |
| limit | No | Maximum number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses scope (MTA:SA events) and workflow, but lacks details on search behavior (case-sensitivity, pagination) or side effects. Still, it adds useful context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description adequately covers what the tool does and how to use it, though it could mention result format or pagination limits for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description does not add additional meaning to parameters beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for events (not functions) in MTA:SA client/server events, distinguishing it from sibling tools like search_functions. It also specifies the intended workflow of chaining into docs tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'only (not regular functions)' and instructs to 'chain into docs tools with exact event names,' providing clear when-to-use and next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Primary discovery tool. Search MTA:SA functions and events by name or keyword before coding. Returns canonical function names with side/category so LLMs can reliably chain into docs tools.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Function name or partial name to search for | |
| side | No | Filter by client-side, server-side, or shared functions | |
| limit | No | Maximum number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It states it returns canonical function names with side/category, implying a read-only search. No mention of rate limits or pagination, but the purpose is transparent and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no wasted words. Front-loads the primary purpose and ends with a clear outcome statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema, the description adequately describes return content (canonical names with side/category). It covers the tool's role in a workflow. Minor gaps: no mention of no-results behavior or limit parameter, but sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds contextual value but no parameter-specific details beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search), resource (MTA:SA functions and events), and value (returns canonical names with side/category for chaining). It distinguishes itself as the 'primary discovery tool' before coding, setting it apart from sibling documentation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage 'before coding' and hints at chaining into docs tools. It doesn't specify when not to use or alternatives, but the context is clear enough for an agent to understand it's the first step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3clear_cacheclear_mtasa_cachefind_events_for_taskfind_functions_for_taskfind_mtasa_functions_for_taskget_cache_statsget_function_docsget_function_examplesget_mtasa_cache_statsget_mtasa_function_docsget_mtasa_function_examplesget_multiple_function_docsget_multiple_mtasa_function_docslist_functions_by_categorylist_mtasa_functions_by_categoryrecommend_doc_workflowsearch_eventssearch_functionssearch_mtasa_functionsclear_mtasa_cachefind_mtasa_functions_for_taskget_mtasa_cache_statsget_mtasa_function_docsget_mtasa_function_examplesget_multiple_mtasa_function_docslist_mtasa_functions_by_categorysearch_mtasa_functionsScored across 11 tools
Each tool has a clearly distinct purpose: search tools (search_functions, search_events) differ from task matchers (find_functions_for_task, find_events_for_task), retrieval tools handle single/batch/examples, and cache/listing/planner serve unique roles. No overlap or confusion.
All tool names follow a consistent verb_noun snake_case pattern (e.g., clear_cache, search_functions, get_function_docs). No mixing of cases or verb styles, making the pattern predictable and easy to navigate.
With 11 tools, the server is well-scoped for its documentation purpose. Each tool earns its place, covering search, retrieval, cache management, category listing, and workflow planning without excess or deficiency.
The tool surface provides a complete workflow: discover (search/task matchers), retrieve (docs, examples, batch), manage (cache stats/clear), explore (category listing), and plan (workflow recommender). No obvious gaps for a documentation server.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that gives your AI access to the source code and docs of all public github repos
An MCP server that integrates with Discord to provide AI-powered features.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
