What can you do with this server?

It lets you manage the lifecycle of a local open.mp/SA-MP test server. * server_start: start the configured local open.mp server and wait until it is ready (idempotent). * server_status: check whether the local server process is running and get its status (read-only). * server_stop: stop the local open.mp server (destructive).

How do I use MCP on My SAMP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP on My SAMP Start the server and when it's ready, send /help and check the response." 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.

de en es ja ko ru zh

MCP on My SAMP

by marhenrik635-oss

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

MCP on My SAMP

Scope: local servers or servers you own/are authorized for. Not a tool for public-server automation.

What can it do?

MCP on My SAMP lets AI agents test game servers with repeatable workflows:

start / stop / check open.mp status;
start / stop / check headless RakClient status;
wait for the client to actually be Spawned;
send allowed slash commands;
read client output history;
verify the server response was received by the client;
discover commands from the Pawn gamemode source;
reject commands outside the allowlist.

It does not provide flood, spam, lag injection, arbitrary RCON, or automation of public servers.

Related MCP server: Brainstorm

Workflow

flowchart LR
    A[AI Agent] -->|MCP stdio| B[MCP on My SAMP]
    B --> C[open.mp Server]
    B --> D[Headless RakClient]
    D -->|UDP localhost| C
    C -->|server response| D
    D --> B
    B -->|assertion| A

Valid round-trip proof:

command dikirim
→ server callback menerima command
→ gamemode mengirim response
→ client menerima response
→ MCP assertion berhasil

Spawned alone is not proof a command succeeded.

Installation

1. Set up Python

Python 3.10 or newer is required.

2. Install the project

Run from the repository root:

Windows

py -3 -m venv .venv
.venv\Scripts\activate
python -m pip install --upgrade pip
python -m pip install ".[dev]"

Linux / macOS

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install ".[dev]"

3. Verify

pytest -q

Expected output:

35 passed

The open.mp and RakClient binaries are only needed for live tests. Python unit tests can still run without those binaries.

Configuration

Create a local config file from the template:

Windows

copy config.example.json local-server.json

Linux / macOS

cp config.example.json local-server.json

Fill in the file:

{
  "executable": "vendor/openmp/Server/omp-server.exe",
  "working_dir": "vendor/openmp/Server",
  "args": ["--config-path", "config.json"],
  "ready_text": "Legacy Network started on port",
  "startup_timeout": 30
}

Change executable and working_dir to match the open.mp location on your machine. local-server.json is not committed to Git because paths differ per machine.

Running the MCP server

Server only

mcp-gta-samp --config local-server.json

With headless RakClient

Windows

mcp-gta-samp ^
  --config local-server.json ^
  --client-executable vendor/rakclient-bin/rakclient.exe ^
  --client-arg --server ^
  --client-arg 127.0.0.1:7777 ^
  --client-arg --nick ^
  --client-arg MCPBot ^
  --client-arg --scripts-dir ^
  --client-arg vendor/rakclient-bin/scripts ^
  --gamemode-source vendor/openmp/Server/gamemodes/mcp_test.pwn

Linux / macOS

mcp-gta-samp \
  --config local-server.json \
  --client-executable vendor/rakclient-bin/rakclient \
  --client-arg --server \
  --client-arg 127.0.0.1:7777 \
  --client-arg --nick \
  --client-arg MCPBot \
  --client-arg --scripts-dir \
  --client-arg vendor/rakclient-bin/scripts \
  --gamemode-source vendor/openmp/Server/gamemodes/mcp_test.pwn

The MCP transport uses stdio.

MCP tools

Tool	Function
`server_start`	Starts the server and waits for readiness.
`server_status`	Checks server status and PID.
`server_stop`	Stops the server.
`client_start`	Starts the headless RakClient.
`client_status`	Checks client status.
`client_stop`	Stops the client.
`client_send_chat`	Sends an allowed slash command after `Spawned`.
`client_get_history`	Retrieves buffered client output.
`client_assert_output`	Ensures specific output was received by the client.
`server_list_commands`	Lists commands from the Pawn source.
`server_assert_command`	Validates a command against the allowlist.

The last two tools are available when --gamemode-source is used.

Workflow for AI agents

1. server_status
2. server_start jika belum berjalan
3. client_start
4. tunggu state Spawned
5. server_list_commands
6. server_assert_command("/help")
7. client_send_chat("/help")
8. client_assert_output("MCP Test Commands:")
9. client_get_history bila perlu diagnosis
10. client_stop
11. server_stop

Important instructions for the agent:

do not access public servers;
do not treat boot, join, or Spawned as a command round-trip;
on failure, classify the boundary: boot, connection, spawn, queue, outbound packet, server callback, server response, client parser, or MCP assertion;
always stop processes after a test;
make sure UDP port 7777 is free again.

Live test example

A test gamemode is available at:

vendor/openmp/Server/gamemodes/mcp_test.pwn

Available commands:

/help
/status

If the Pawn source is changed, recompile the .amx from the server folder:

qawno\pawncc.exe -i.\qawno\include -o.\gamemodes\mcp_test .\gamemodes\mcp_test.pwn

Live workflow:

server_start
→ client_start
→ client mencapai Spawned
→ client_send_chat("/help")
→ client_assert_output("MCP Test Commands:")
→ client_assert_output("/status - show a test response")
→ client_stop
→ server_stop

The headless RakClient proves protocol, state, and commands. It does not produce screenshots. Visual testing requires a separate rendered GTA client.

Development

Running tests:

pytest -q

Building a wheel:

python -m pip wheel . --no-deps -w dist

Installing the wheel:

python -m pip install dist/mcp_gta_samp-0.1.0-py3-none-any.whl

Core structure:

mcp_gta_samp/       package Python dan MCP facade
tests/              unit, contract, dan bridge tests
config.example.json template konfigurasi
vendor/             binary dan fixture live test

Security

This MCP restricts usage to local/owned servers. Do not include credentials, proxy pools, private configs, private logs, or server test data in public repositories.

If you run a server from the internet, add your own authentication and network isolation. This package is not designed as a public game-control API.

License

MIT License. See LICENSE.

Available Tools

3 tools

server_startA

Idempotent

Start the configured local open.mp test server and wait for readiness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover idempotency (idempotentHint=true), read-only status (readOnlyHint=false), and destructiveness (destructiveHint=false). The description adds the 'wait for readiness' behavior, which is beyond what annotations provide, giving the agent a clear expectation of the tool's runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes meaning: 'start', 'configured local open.mp test server', and 'wait for readiness' are all necessary and sufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple tool with no parameters, an output schema, and annotations covering idempotency and safety. The description fully covers the intended action and readiness behavior, leaving no critical gaps for an agent to call it correctly.

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 there are no parameter semantics to document. Per the baseline for 0 params, a score of 4 is appropriate; the description doesn't need to compensate for schema gaps.

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 ('Start') and resource ('configured local open.mp test server') and adds 'wait for readiness' as a behavioral outcome. This clearly distinguishes it from siblings server_stop and server_status through action and intent.

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 start action and readiness wait make the context obvious: this is for bringing the server up. It does not explicitly name alternatives or when-not conditions, but the sibling names and the verb provide clear contextual guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

server_statusA

Read-only

Return local open.mp test server process status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds the 'local' and 'process status' scope, but does not provide additional behavioral detail such as what exactly the status output contains or whether it might throw errors if no server is running. With the output schema present, the agent can likely infer return structure, so the description adds minimal but acceptable value.

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 delivers the essential meaning with no filler. It names the resource and the type of operation without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter, read-only status tool with an output schema present, the description is complete enough to guide correct invocation. There are no prerequisites, options, or alternatives that need clarifying beyond what the summary already provides.

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?

There are zero parameters, so the description has no parameter meaning to add. The baseline for no-parameter tools is 4, and there is no relevant gap to compensate for.

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 ('Return') and a clear resource ('local open.mp test server process status'), making the tool's function immediately obvious. It also differentiates itself from siblings server_start and server_stop by describing a read-only status check rather than a state-changing operation.

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 implies the tool is for checking status rather than starting or stopping the server, which are the sibling operations. It does not explicitly state 'use this when you need to check status and not start/stop', but the context and naming make the intended use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

server_stopA

Destructive

Stop the configured local open.mp test server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds no behavioral context beyond the verb 'Stop'. It does not clarify consequences such as terminating active sessions or clearing server state. There is no contradiction with annotations, but the description relies entirely on structured metadata.

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 action and the target directly, and every word 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 zero-parameter destructive action with annotations covering safety and an output schema present, the description is sufficient for basic invocation. It is slightly thin on operational context such as behavior when the server is already stopped, but that is not necessary for calling the tool correctly.

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 zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies because the description cannot add meaning beyond the empty 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 precise action ('Stop') and the exact target ('configured local open.mp test server'). This clearly distinguishes it from sibling tools server_start and server_status, which have complementary purposes.

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 server_start or server_status. The description only states the action and target, leaving the agent to infer usage from the tool name and siblings rather than from explicit instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Aug 21, 2026
- First observedserver_start
- First observedserver_status
- First observedserver_stop

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a single, clear responsibility: start, stop, or check status. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow the identical pattern of 'server_' followed by a simple verb (start, stop, status). This is perfectly consistent and predictable.

Tool Count5/5

Three tools is exactly right for the narrow scope of managing a local server. Each tool is essential and earns its place without unnecessary bloat.

Completeness4/5

The tool set covers the core lifecycle (start, stop, status) but lacks a restart operation, which is a common need. However, agents can still accomplish restart via stop+start, so this is a minor gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

try B
md.install
Create guides as MCP servers to instruct coding agents to use your software (library, API, etc).
Documentation Access Developer Tools Coding Agents
132
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Minecraft RCON MCP Server
Games & Gamification Developer Tools Testing & QA Tools
MinecraftCodeFoundary
A
license
A
quality
D
maintenance
Connects AI agents to Minecraft servers via RCON to execute commands, monitor logs, and perform read-only SQLite database queries. It is specifically designed to facilitate AI-assisted plugin development, live debugging, and automated testing workflows.
Updated 7 months ago (2026-02-13 10:03 UTC)
6
11
MIT
Brainstorm
Communication Autonomous Agents
TheodorStorm
A
license
Not graded
quality
F
maintenance
Enables AI agents to communicate, coordinate, and collaborate on complex tasks through a local MCP server.
Updated a month ago (2026-08-09 09:39 UTC)
15
8
ISC
Local Machine MCP Server
File Systems Command Line Databases
authmeonline
F
license
Not graded
quality
C
maintenance
Turns your local machine into an MCP server with a GUI, allowing agents to execute file operations, run commands (including admin), manage background processes, and query databases, with optional ngrok exposure.
Updated 3 months ago (2026-06-18 02:21 UTC)
-
Roblox Executor MCP Server
Games & Gamification Code Execution
RealSlimShady2000
A
license
A
quality
B
maintenance
Enables AI agents to execute Lua code, inspect scripts, spy on remotes, and interact with a running Roblox game client through an MCP interface.
Updated 2 months ago (2026-07-17 09:44 UTC)
6
22
76
1
MIT

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/marhenrik635-oss/mcponmysamp'

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

MCP on My SAMP

What can it do?

Workflow

Installation

1. Set up Python

2. Install the project

3. Verify

Configuration

Running the MCP server

Server only

With headless RakClient

MCP tools

Workflow for AI agents

Live test example

Development

Security

License

Links

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API