This server provides AI assistants with structured access to Multi Theft Auto: San Andreas (MTA:SA) API documentation, enabling function discovery, documentation retrieval, and cache management.
Search for functions/events: Search MTA:SA functions and events by name or partial name, with optional filtering by side (client/server/shared).
Find functions for a task: Describe a programming task (e.g., "spawn vehicle") and get semantically matched functions using vector similarity search and intelligent keyword expansion.
Get full function documentation: Retrieve detailed docs for a specific function including description, syntax, parameters, return values, and code examples — with SQLite caching for faster repeated access.
Get function code examples: Fetch only the code examples for a specific function, useful for fast code generation reference.
Batch documentation retrieval: Fetch documentation and examples for multiple functions simultaneously, ideal when implementing a feature spanning several APIs.
List functions by category: Browse all functions within categories such as Client Functions, Server Events, Standard Lua Functions, Data Types/Classes, etc.
Cache management: View cache statistics and clear cached documentation for specific functions or the entire cache.
Additional features: Built-in deprecation detection, event-first discovery, cross-runtime support (Node.js 24+, Bun 1.3+), and integration with MCP clients like Cursor, VS Code, and Claude Code.
Provides runtime support for the MTA:SA documentation MCP server, enabling cross-runtime compatibility with Bun's SQLite implementation for efficient documentation caching and retrieval.
Supports repository hosting and release automation through GitHub Actions workflows, including OIDC-based trusted publishing to npm and MCP Registry integration.
Provides CI/CD automation for verification, testing, and release workflows, including cross-runtime smoke tests and automated publishing to npm and MCP Registry.
Licensed under GNU General Public License v3.0, ensuring open-source distribution and modification rights for the MTA:SA documentation server.
Supported as a CI/CD platform in GitHub Actions workflows for verification and testing of the MTA:SA documentation MCP server.
Provides primary runtime support for the MTA:SA documentation MCP server with Node.js SQLite implementation for documentation caching and tool execution.
Enables package distribution and installation of the MTA:SA documentation MCP server, with automated publishing through GitHub Actions OIDC workflows.
Used as the package manager for development, building, and testing the MTA:SA documentation MCP server with optimized dependency management.
Provides the database backend for caching MTA:SA documentation with vector embeddings, enabling fast semantic search and intelligent function discovery.
Supported as a CI/CD platform in GitHub Actions workflows for verification, testing, and release automation of the MTA:SA documentation MCP server.
Supported as an alternative package manager for installing and running the MTA:SA documentation MCP server through dlx-style installation flows.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MTA:SA Documentation MCP Server How do I create a vehicle at a specific position?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that gives AI assistants reliable, structured access to Multi Theft Auto: San Andreas documentation.
It combines fast keyword search, semantic matching, and SQLite-backed caching so agents can discover the right APIs and fetch authoritative docs without manual wiki scraping.
11 MCP tools for discovery, docs retrieval, cache operations, and workflow guidance
Event-first discovery (search_events, find_events_for_task)
Semantic task matching with SQLite vector search
Smart keyword expansion (for example, database -> db* APIs)
Built-in deprecation detection and warnings
Local SQLite cache with configurable lifetime
CI verification gates, smoke tests, and release automation
Related MCP server: Documentation Retrieval MCP Server (DOCRET)
Requirements:
Node.js 24+
Bun 1.3+ (optional runtime)
pnpm 10+ (for local development)
Launcher note:
You can launch/install via npx, pnpx, bunx, or yarn dlx-style flows.
Runtime support is cross-runtime: Node.js (via node:sqlite) and Bun (via bun:sqlite).
npm install -g mtasa-docs-mcpor:
pnpm add -g mtasa-docs-mcp
git clone https://github.com/Luminaire1337/mtasa-docs-mcp.git
cd mtasa-docs-mcp
pnpm install
pnpm buildIf your environment skips optional native dependencies, run:
pnpm install --forceGlobal: ~/.cursor/mcp.json
Project: .cursor/mcp.json
{
"mcpServers": {
"mtasa-docs": {
"command": "npx",
"args": ["-y", "mtasa-docs-mcp"]
}
}
}Workspace: .vscode/mcp.json
User: Command Palette -> MCP: Open User Configuration
{
"servers": {
"mtasa-docs": {
"command": "npx",
"args": ["-y", "mtasa-docs-mcp"]
}
}
}Or add it from terminal:
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"]}'Global config file: ~/.config/opencode/opencode.json
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"mtasa-docs": {
"type": "local",
"command": ["npx", "-y", "mtasa-docs-mcp"],
"enabled": true
}
}
}Config file: ~/.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"]
}
}
}If mtasa-docs-mcp is already published, replace the command with:
{
"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:fullUseful checks:
pnpm check:versions - keep package.json and MCP server version aligned
pnpm check:changelog - ensure CHANGELOG.md has current release heading
pnpm check:tool-names - prevent legacy tool naming regressions
pnpm test:runtime - run integration runtime tests for Node and Bun smoke paths
pnpm smoke:cross-runtime - run smoke checks against both Node and Bun runtimes
Scripts are located in scripts/ (build, smoke, release guards).
Release automation is handled by .github/workflows/release.yml.
Bump version in package.json and src/index.ts.
Move release notes from Unreleased into a versioned section in
CHANGELOG.md using ## [x.y.z] - YYYY-MM-DD.
Create and push a release tag: git tag v<version> && git push origin v<version>.
Branching policy:
Before v1.0.0: direct pushes to master are allowed.
Starting at v1.0.0: use PR-based development for all changes to master.
On release tag pushes (v*.*.*), the release workflow:
checks whether the version already exists on npm
runs pnpm verify:full
publishes to npm with provenance using trusted publishing (OIDC)
publishes server.json to the MCP Registry using GitHub OIDC
creates/updates the GitHub Release from CHANGELOG.md
verifies installability of the published package and runs smoke tests
In npm package settings, configure a trusted publisher for this repository and workflow:
Repository: Luminaire1337/mtasa-docs-mcp
Workflow file: .github/workflows/release.yml
Environment (if used): match your GitHub Actions configuration
Ensure server.json exists at repository root and uses this package name:
mtasa-docs-mcp
Configure MCP Registry ownership for
io.github.Luminaire1337/mtasa-docs-mcp
Release workflow uses mcp-publisher login github-oidc and publishes only
when the npm publish gate passes
.github/workflows/ci.yml - verification on push/PR to master (Ubuntu +
macOS) and optional live wiki integration tests on labeled PRs
.github/workflows/release.yml - automated publish and GitHub release on
release tags (v*.*.*)
AGENTS.md - architecture and contributor guidance
FEATURES.md - roadmap and ideas
CHANGELOG.md - release history
SECURITY.md - vulnerability disclosure policy
GNU General Public License v3.0. See 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
