В первой части разобрали что такое MCP и написали первый инструмент. Сегодня идем дальше — что делать, если запросы сложнее и нейросеть не знает как у вас организованы таблицы (их описание и как они могут соединяться между собой).
Проблема: модель не знает ваши таблицы 🎚
Фиксированный тул — например
get_sales_by_region — работает хорошо для простых запросов. Но что если пользователь спросит: «Сравни выручку по регионам с прошлым кварталом с разбивкой по сегментам клиентов»?Тут нужно несколько таблиц, JOIN и оконные функции. Заранее написать тул под каждый такой запрос — нереально (реально, конечно, но не логично мягко говоря).
Решение: дать модели два инструмента — получить схему и возможность выполнить любой запрос.
Как это устроено: 🎚
@mcp.tool()
def get_database_schema(domain: str = "all") -> str:
"""
Возвращает схему БД: таблицы, поля, типы данных и связи.
Вызывай ПЕРЕД тем как писать SQL-запрос.
domain: 'sales', 'customers', 'products' или 'all'
"""
if domain == "all":
files = ["sales.md", "customers.md", "products.md"]
else:
files = [f"{domain}.md"]
result = ""
for f in files:
with open(f"docs/{f}", "r") as file:
result += file.read() + "\n\n"
return result
@mcp.tool()
def execute_sql(query: str) -> list:
"""
Выполняет SELECT-запрос к базе данных.
Используй только после get_database_schema.
Только SELECT — никаких изменений данных.
"""
conn = sqlite3.connect("metrics.db")
cursor = conn.cursor()
cursor.execute(query)
result = cursor.fetchall()
conn.close()
return result
Модель сначала вызывает
get_database_schema, читает описание таблиц и связей — потом сама пишет SQL и передает в execute_sql.Как организовать файлы схемы: 🎚
Файлы лежат рядом с сервером в папке
/docs. Внутри — описание таблиц, типы данных и как они связаны:## Таблица orders
- order_id INT — первичный ключ
- customer_id INT — FK → customers.customer_id
- region VARCHAR — регион продажи
- revenue FLOAT — выручка
- created_at DATE — дата заказа
## Связи
orders.customer_id → customers.customer_id
Прочитав это, модель сама поймет как делать JOIN между таблицами — объяснять ничего не нужно.
Один MCP или несколько? 🎚
Один MCP-сервер = один проект. Не нужно плодить отдельный сервер под каждую таблицу. Все связанные таблицы и тулы живут в одном сервере. Если у вас две независимые системы — например аналитическая база и CRM — вот тогда имеет смысл делать два разных сервера. Здесь нет явного ответа, нужно подходить индивидуально к каждому проекту.
А если схема хранится в Confluence? 🎚
Рабочий вариант — тул делает запрос к Confluence API и достает описание нужной таблицы прямо оттуда:
@mcp.tool()
def get_table_docs(table_name: str) -> str:
"""
Достает описание таблицы из корпоративной документации.
Используй перед написанием SQL если нужны детали схемы.
"""
# запрос к Confluence API
response = requests.get(
f"{CONFLUENCE_URL}/rest/api/content",
params={"title": table_name, "expand": "body.storage"},
auth=(USER, TOKEN)
)
return response.json()["results"][0]["body"]["storage"]["value"]
🟢 Хотите еще про нейронки ?
🔥 Набираем 80 реакций на этот пост, чтобы подобные посты выходили чаще
Итог: 🤩
❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Какие идеи для использования MCP есть у вас? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.
🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru
@dima_sqlit