How do I use FunPay MCP Server?

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., "@FunPay MCP Server show me my recent sales" 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.

FunPay MCP Server

by fakelag28

Overview Schema Related Servers Score Discussions

Python

Remote

FunPay MCP Server

Python 3.10+ MCP FunPay Tests License Public

FunPay MCP Server — это MCP-сервер (Model Context Protocol), предоставляющий AI-агентам полный программный доступ к аккаунту FunPay: чтение чатов и заказов, создание и редактирование лотов, возвраты средств и многое другое.

Сервер работает напрямую с web-API FunPay, без Telegram и сторонних зависимостей, и реализует тот же поток запросов, что и FunPayCardinal, но без наследования его кода.

FunPay MCP Server is an MCP server that gives AI agents full programmatic access to a FunPay account: read chats and orders, create and edit lots, refund payments, and more. It talks directly to FunPay's web API, with no Telegram or third-party dependencies, and reproduces the request flow used by FunPayCardinal without forking its code.

⚡ Возможности / Features

💬 Чаты и сообщения / Chats and messages

get_chats() — список всех чатов с превью последнего сообщения и отметкой непрочитанных.
get_chat_history(chat_id, last_message_id=None) — история сообщений конкретного чата (входящие/исходящие, автор, таймстамп, изображения).
get_chats_histories(chat_ids) — пакетное чтение историй нескольких чатов одним запросом.
send_message(chat_id, text, interlocutor_id=None) — отправка сообщения в чат.
get_chats() / get_chat_history() / get_chats_histories() / send_message() — full chat read/write via FunPay's runner/ long-polling endpoint, same approach as FunPayCardinal.

📦 Заказы / Orders

get_orders_counters() — счётчики активных продаж и покупок через runner/orders_counters.
get_sales(include_paid, include_closed, include_refunded, limit) — список заказов со страницы «Мои продажи» с полным описанием, ценой, валютой, покупателем, статусом и датой.
get_order(order_id) — детальная карточка заказа: описание, цена, параметры заказа, продавец, покупатель, статус.
refund(order_id) — оформление возврата средств покупателю.

🏪 Лоты и категории / Lots and categories

get_my_lots(subcategory_id) — все ваши лоты в указанной подкатегории.
get_lot_fields(lot_id) — текущие значения полей формы редактирования лота.
save_lot(lot_id, fields) — создание или обновление лота.
delete_lot(lot_id) — деактивация (удаление) лота.
raise_lots(lot_ids) — поднятие лотов в каталоге (rate-limited).
get_categories() — список категорий (по играм) с подкатегориями.
get_subcategories(category_id) — подкатегории конкретной категории.

👤 Профиль и баланс / Profile and balance

get_me() — собственный профиль: id, username, активные счётчики.
get_user(user_id) — публичный профиль любого пользователя FunPay.
get_balance() — баланс в RUB, USD и EUR (доступно и всего). FunPay в новом UI не различает «доступно» и «всего», поэтому total_* и available_* возвращают одно и то же значение (выводимый баланс).

Related MCP server: fiverr-mcp

📦 Установка / Installation

Требования / Requirements

Python 3.10+
Действующий аккаунт FunPay
golden_key cookie и User-Agent из браузера, в котором вы авторизованы на FunPay

Установка из исходного кода / Install from source

git clone https://github.com/fakelag28/funpay-mcp-server.git
cd funpay-mcp-server
python -m venv .venv
source .venv/bin/activate
pip install -e .

⚙️ Первичная настройка / Setup

1. Получите `golden_key` / Get the `golden_key`

Авторизуйтесь на https://funpay.com в браузере Chromium.
Откройте DevTools (F12) → Application → Cookies → https://funpay.com.
Скопируйте значение cookie golden_key.
Также скопируйте значение User-Agent браузера: DevTools → Network → любой запрос → Headers → User-Agent.

2. Запуск сервера / Run the server

golden_key никогда не принимается через аргументы CLI и не хранится в коде. Используйте переменные окружения:

export FUNPAY_GOLDEN_KEY="<ваш golden_key>"
export FUNPAY_USER_AGENT="<ваш User-Agent>"
python -m funpay_mcp

Или через .env:

cp .env.example .env
# отредактируйте .env, затем:
export $(cat .env | xargs)
python -m funpay_mcp

Переменные окружения / Environment variables

Переменная	Обязательна	По умолчанию	Описание
`FUNPAY_GOLDEN_KEY`	✅	—	Значение cookie `golden_key`
`FUNPAY_USER_AGENT`	❌	Chrome 124 Linux	User-Agent браузера с активной сессией
`FUNPAY_TIMEOUT`	❌	`15`	HTTP timeout, секунды
`FUNPAY_LOCALE`	❌	`ru`	`ru`, `en` или `uk`
`FUNPAY_PROXY`	❌	—	Один URL, например `socks5://localhost:1080`

🧩 Подключение к MCP-клиенту / Connecting an MCP client

Claude Desktop

В claude_desktop_config.json:

{
  "mcpServers": {
    "funpay": {
      "command": "python",
      "args": ["-m", "funpay_mcp"],
      "env": {
        "FUNPAY_GOLDEN_KEY": "<ваш ключ>",
        "FUNPAY_USER_AGENT": "<ваш UA>"
      }
    }
  }
}

Cursor / любой MCP-клиент

Аналогично: зарегистрируйте сервер как funpay и передайте FUNPAY_GOLDEN_KEY / FUNPAY_USER_AGENT через env.

🔧 Разработка / Development

pip install -e .[dev]
pytest                          # 7 unit-тестов
FUNPAY_GOLDEN_KEY=*** \
  FUNPAY_USER_AGENT=*** \
  python tests/test_live.py     # live-тест против реального FunPay

Структура проекта / Project layout

funpay-mcp-server/
├── src/funpay_mcp/
│   ├── client.py     # HTTP-клиент, golden_key, PHPSESSID, CSRF, runner/ polling
│   ├── parsers.py    # JSON-парсер runner-ответов + HTML-парсер trade-страницы
│   ├── account.py    # 17 методов бизнес-логики
│   ├── models.py     # 10 Pydantic-моделей
│   └── server.py     # FastMCP: 17 @mcp.tool() регистраций
├── tests/
│   ├── test_smoke.py # 7 unit-тестов
│   └── test_live.py  # live-тест (требует golden_key)
├── pyproject.toml
├── .env.example
└── .gitignore

Архитектура / Architecture

HTTP-клиент использует runner/ long-polling endpoint (как в FunPayCardinal) для получения реальных данных чатов и счётчиков заказов. runner/ возвращает JSON с типизированными объектами, а не HTML, что упрощает парсинг и позволяет читать сразу несколько чатов одним запросом.
CSRF-токен извлекается из атрибута data-app-data на главной странице и автоматически обновляется при каждом успешном ответе.
Throttle 400 мс между запросами защищает от FunPay anti-flood правил.
golden_key хранится только в env, не логируется, не пишется в файлы, не коммитится.

🔒 Безопасность / Security

golden_key — это эквивалент вашего пароля от FunPay. Никогда не коммитьте его, не вставляйте в публичные чаты и не логируйте. Если ключ утёк — немедленно смените его в настройках аккаунта FunPay (выйдите из всех сессий).
Все mutating-операции (send_message, refund, save_lot, delete_lot, raise_lots) рекомендуется вызывать только по явному одобрению пользователя в чате с AI-агентом.
Сервер single-account: один golden_key на один процесс.

📄 Лицензия / License

Этот проект распространяется под лицензией AGPL-3.0. См. файл LICENSE. This project is licensed under the AGPL-3.0 License. See LICENSE.

Available Tools

16 tools

delete_lotD

ParametersJSON Schema

Name	Required	Description	Default
`lot_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`lot_id`	Yes
`message`	No
`success`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_balanceD

ParametersJSON Schema

Name	Required	Description	Default
`lot_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`total_eur`	Yes
`total_rub`	Yes
`total_usd`	Yes
`available_eur`	Yes
`available_rub`	Yes
`available_usd`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_categoriesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_chat_historyD

ParametersJSON Schema

Name	Required	Description	Default
`chat_id`	Yes
`last_message_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_chatsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_lot_fieldsD

ParametersJSON Schema

Name	Required	Description	Default
`lot_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`fields`	Yes
`lot_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_meD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`username`	No
`active_sales`	No
`active_purchases`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_my_lotsD

ParametersJSON Schema

Name	Required	Description	Default
`subcategory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_orderD

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`raw`	No
`date`	No
`price`	Yes
`amount`	No
`status`	Yes
`chat_id`	Yes
`buyer_id`	Yes
`currency`	No
`seller_id`	No
`parameters`	No
`closed_date`	No
`description`	Yes
`buyer_username`	Yes
`seller_username`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_salesD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`start_from`	No
`include_paid`	No
`include_closed`	No
`include_refunded`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_subcategoriesD

ParametersJSON Schema

Name	Required	Description	Default
`category_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_userD

ParametersJSON Schema

Name	Required	Description	Default
`user_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`avatar`	No
`banned`	No
`status`	No
`username`	Yes
`registration_date`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

raise_lotsD

ParametersJSON Schema

Name	Required	Description	Default
`lot_ids`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

refundD

ParametersJSON Schema

Name	Required	Description	Default
`order_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`success`	Yes
`order_id`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

save_lotD

ParametersJSON Schema

Name	Required	Description	Default
`fields`	Yes
`lot_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`lot_id`	Yes
`message`	No
`success`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

send_messageD

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`chat_id`	Yes
`interlocutor_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`chat_id`	Yes
`message`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

Install Server

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

TDQS

C2/5.0

Disambiguation4/5

Most tools are clearly distinct, such as get_me vs get_user and get_chats vs get_chat_history. However, get_sales and get_order could be confused since both relate to transactions, and get_my_lots vs get_lot_fields might be ambiguous without clear descriptions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., get_balance, send_message, delete_lot). Even exceptions like refund and raise_lots still adhere to the pattern, creating a predictable and uniform naming scheme.

Tool Count4/5

With 16 tools, the server is slightly above the ideal 3-15 range, but the breadth is justified by the need to cover user, order, lot, chat, and category management. No tools feel redundant, and the count is not overwhelming.

Completeness4/5

The toolset covers core marketplace workflows well: user profiles, balance, refunds, sales/orders, lot CRUD (save/delete/get), and categories. Missing operations like explicit lot search or order creation are minor gaps, as buyers would normally initiate these actions.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Scrollport
com.scrollport
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Agent Orchestration Developer Tools
1
Asyntai – AI Support Agent for Websites
com.asyntai
Run your website's AI support agent from Claude, Cursor or any MCP client. Manage the knowledge base, edit agent instructions, read conversations and leads, reply live to visitors, and check plan usage. 54 tools, OAuth sign-in, no API key. Free with every Asyntai account: https://asyntai.com/documentation/mcp/
AI & Machine Learning App Automation Customer Support
1
mcp-server
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
MIDAS Protocol C
io.github.BbrainFrance
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Finance Payments & Billing
2

Related MCP Servers

@chainpayto/mcp-serverofficial
Blockchain Cryptocurrency Payments & Billing
chainpayto
A
license
A
quality
D
maintenance
Enables AI agents to directly operate ChainPay cryptocurrency payment system, including order creation, balance checks, and withdrawals.
Updated 4 months ago (2026-04-24 12:16 UTC)
6
17
MIT
fiverr-mcp
E-commerce & Retail Communication Project Management
marwankous
A
license
A
quality
C
maintenance
Enables AI assistants to manage Fiverr seller accounts directly from the browser session. Supports gig management, order tracking, messaging, analytics, and profile updates without API keys.
Updated 2 months ago (2026-06-19 01:58 UTC)
14
MIT
moysklad-mcp-ru
ERP Systems Finance
marfarin
F
license
Not graded
quality
C
maintenance
Enables AI agents to read and write MoySklad inventory, orders, reports, and documents via JSON API 1.2 with safety gates.
Updated 2 months ago (2026-06-26 11:57 UTC)
Telegram MCP Server
Muhammadyunusxon
A
license
Not graded
quality
A
maintenance
Enables AI assistants to control a personal Telegram account for sending/reading messages, media, group management, and more via the MTProto API.
Updated a month ago (2026-07-28 07:40 UTC)
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/fakelag28/funpay-mcp-server'

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

FunPay MCP Server

⚡ Возможности / Features

💬 Чаты и сообщения / Chats and messages

📦 Заказы / Orders

🏪 Лоты и категории / Lots and categories

👤 Профиль и баланс / Profile and balance

📦 Установка / Installation

Требования / Requirements

Установка из исходного кода / Install from source

⚙️ Первичная настройка / Setup

1. Получите golden_key / Get the golden_key

2. Запуск сервера / Run the server

Переменные окружения / Environment variables

🧩 Подключение к MCP-клиенту / Connecting an MCP client

Claude Desktop

Cursor / любой MCP-клиент

🔧 Разработка / Development

Структура проекта / Project layout

Архитектура / Architecture

🔒 Безопасность / Security

📄 Лицензия / License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@chainpayto/mcp-serverofficial

Latest Blog Posts

MCP directory API

1. Получите `golden_key` / Get the `golden_key`