L
lagaam-ai/lagaam
MCP server that stops an AI agent's Trino or Pinot query before it stalls your shared cluster: priced from the engine's own plan, refused with a fix the agent can act on
无 SECURITY.md
在 GitHub 查看 ↗链接已于 2026-11-12 核查 · HTTP 200 · 打开的是厂商自己的官网
安装与配置
- 复制上面的命令
- 粘成
claude_desktop_config.json里mcpServers的一项(本地服务器用 command + args,示例见 客户端接法) - 重启客户端
客户端配置(取自该仓库的安装命令)
{
"mcpServers": {
"lagaam-ai-lagaam": {
"command": "uvx",
"args": ["lagaam"]
}
}
}解析自我们于 2026-10-26 抓取的该仓库 README;我们未执行过。
command/args 来自仓库写明的安装命令;不确定时请以该项目 README 为准。
VS Code(.vscode/mcp.json —— 键名是 servers)
{
"servers": {
"lagaam-ai-lagaam": {
"command": "uvx",
"args": ["lagaam"]
}
}
}VS Code 顶层键是 <code>servers</code>,其余与上面那份相同。
Claude Code(命令行)
claude mcp add --transport stdio lagaam-ai-lagaam -- uvx lagaam
Claude Code 不收 JSON 文件,用这条命令直接加。
配置项的键名以你的客户端为准:客户端与 CLI
- ★ 数取值
- 1 ★ · lagaam-ai/lagaam · 取自 GitHub 搜索 API · (2026-11-13 20:00:50 核对)
- 来源明细
- 收录自 punkpeye/awesome-mcp-servers 榜单(我们从中收集的条目之一) · 条目类型:MCP 服务
- 收录与活跃
- 收录于 2026-10-23 · 最近见到 2026-11-14 · 共见到 26 次 · 被 23 个来源列出
- 评分构成
- 综合分 2,300 · 1 ★ · 23 个来源 · mcp
- 安装
uvx lagaam
常见问题(答案都来自我们的记录)
怎么安装?
该仓库给出的安装命令是
uvx lagaam。我们的记录里它是仓库自己提供的;不保证在你的客户端上直接可用。它适合谁 / 用来做什么?
我们把它归在这些标签下: MCP 服务。标签来自条目自身,不是我们强加的分类。
谁维护它、还在更新吗?
仓库
lagaam-ai/lagaam;我们收录于 2026-10-23;最近见到 2026-11-14。这里没有"官方认证"或"质量评级"——我们只记录来源与时间。One agent query shouldn't stall everyone's Trino. On a shared cluster, a
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
missing partition filter or an accidental cross join doesn't cost you a bill —
it costs everyone else their queries. Lagaam is an MCP server that sits
between your AI agents and your lakehouse (Trino and Apache Pinot): every
query is schema-grounded, priced from the engine's own plan before it runs,
checked against a budget, and audited — and the bad one is refused before it
runs, with a fix the agent can act on.
Real session, real Trino, nothing mocked — reproduce it with
uv run --project server python examples/demo.py.
Real session, real Pinot 1.5.1 realtime table, nothing mocked — reproduce it
with uv run --project server python examples/demopinot.py.
## The problem
Agents write syntactically-valid, catastrophic SQL, and on a shared cluster
the damage isn't theirs alone. A missing partition filter turns into a full
scan that ties up every worker; an accidental cross join fills worker memory
while everyone else's queries wait behind it; a retry loop runs it again. A
SELECT drags 40 columns into a context window that needed 2. The usual
fix is to not give agents database access at all.
Lagaam gives them access with reins on:
Cost is a quotation, not a bill. Every query is priced from the
engine's own plan before execution — EXPLAIN (TYPE IO) for the bytes it
would scan, EXPLAIN (TYPE LOGICAL) for the widest row count any operator
would build (the number a cross join blows and a LIMIT cannot hide).
Over budget → blocked, with the number and the fix.
Un-estimable means no. No table statistics, a self-join that breaks
the estimate, a passthrough the planner can't see — the gate fails safe
instead of hoping.
Read-only, enforced in the AST. Single SELECT only. No DDL/DML, no
multi-statement injection, no SELECT , no table-function passthrough,
and a LIMIT is injected when missing. Validated SQL is re-rendered, so
what runs is exactly what was checked.
Agents ground themselves. listcatalogs and describetable return
exact names, types, and row estimates — scoped to the agent's table grant,
so the agent never learns names it isn't allowed to touch.
Results are verified before they're trusted. Zero rows, truncated
pages, all-NULL columns — the agent gets a warning with a next action, not
a silently misleading answer.
Every call is audited. One JSONL line per tool call: who, what,
allowed or denied, and why.
## Doesn't Trino already limit this?
It limits a query once it is running. Lagaam refuses it before it starts.
Keep both.
| | Acts | What the agent sees | Catches a cross join that reads little |
| query.max-scan-physical-bytes | during execution: terminated once the bytes are scanned | a query failure | no — it counts bytes read, not rows built |
| query.max-execution-time | during execution: terminated after the time is spent | a query failure | only after it has held the cluster that long |
| Resource groups (hardPhysicalDataScanLimit, softMemoryLimit, …) | on the next query: new queries queue once the group is over its share | its later queries wait | no — the running query continues |
| Lagaam | before execution, from EXPLAIN | a refusal with the number and the fix | yes — it prices the rows the widest step would build |
it costs everyone else their queries. Lagaam is an MCP server that sits
between your AI agents and your lakehouse (Trino and Apache Pinot): every
query is schema-grounded, priced from the engine's own plan before it runs,
checked against a budget, and audited — and the bad one is refused before it
runs, with a fix the agent can act on.
Real session, real Trino, nothing mocked — reproduce it with
uv run --project server python examples/demo.py.
Real session, real Pinot 1.5.1 realtime table, nothing mocked — reproduce it
with uv run --project server python examples/demopinot.py.
## The problem
Agents write syntactically-valid, catastrophic SQL, and on a shared cluster
the damage isn't theirs alone. A missing partition filter turns into a full
scan that ties up every worker; an accidental cross join fills worker memory
while everyone else's queries wait behind it; a retry loop runs it again. A
SELECT drags 40 columns into a context window that needed 2. The usual
fix is to not give agents database access at all.
Lagaam gives them access with reins on:
Cost is a quotation, not a bill. Every query is priced from the
engine's own plan before execution — EXPLAIN (TYPE IO) for the bytes it
would scan, EXPLAIN (TYPE LOGICAL) for the widest row count any operator
would build (the number a cross join blows and a LIMIT cannot hide).
Over budget → blocked, with the number and the fix.
Un-estimable means no. No table statistics, a self-join that breaks
the estimate, a passthrough the planner can't see — the gate fails safe
instead of hoping.
Read-only, enforced in the AST. Single SELECT only. No DDL/DML, no
multi-statement injection, no SELECT , no table-function passthrough,
and a LIMIT is injected when missing. Validated SQL is re-rendered, so
what runs is exactly what was checked.
Agents ground themselves. listcatalogs and describetable return
exact names, types, and row estimates — scoped to the agent's table grant,
so the agent never learns names it isn't allowed to touch.
Results are verified before they're trusted. Zero rows, truncated
pages, all-NULL columns — the agent gets a warning with a next action, not
a silently misleading answer.
Every call is audited. One JSONL line per tool call: who, what,
allowed or denied, and why.
## Doesn't Trino already limit this?
It limits a query once it is running. Lagaam refuses it before it starts.
Keep both.
| | Acts | What the agent sees | Catches a cross join that reads little |
| query.max-scan-physical-bytes | during execution: terminated once the bytes are scanned | a query failure | no — it counts bytes read, not rows built |
| query.max-execution-time | during execution: terminated after the time is spent | a query failure | only after it has held the cluster that long |
| Resource groups (hardPhysicalDataScanLimit, softMemoryLimit, …) | on the next query: new queries queue once the group is over its share | its later queries wait | no — the running query continues |
| Lagaam | before execution, from EXPLAIN | a refusal with the number and the fix | yes — it prices the rows the widest step would build |
收录徽章(可选)
想把收录标记放进 README 就复制这行,可选,不影响收录。
[](https://anclum.com/zh/s/lagaam-ai-lagaam/)
- 来源
- awesome · https://github.com/lagaam-ai/lagaam
- 按领域浏览
- MCP 服务
- Traction
- 1 ★
- 收录来源
- 23 个独立来源
- 收录于
- 今天
- 安全策略
- 我们没在该仓库根目录找到
SECURITY.md(这不代表不安全)
同类推荐
所属领域与标签
每个标签都能点进去看同类的全部条目。数字是当前库里的真实条数。