Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
作者提供的说明(英文原文)
Every spreadsheet is a table: Excel, CSV, Parquet and JSON as SQL tables for AI agents.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
适用于网页版、桌面版和手机版 Claude:
https://mcp.tableski.io/在终端中运行这条命令
claude mcp add --transport http tableski https://mcp.tableski.io/粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"tableski": {
"url": "https://mcp.tableski.io/"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"tableski": {
"type": "http",
"url": "https://mcp.tableski.io/"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
ChatGPT 只能连接互联网上的服务器:
https://mcp.tableski.io/菜单名称可能因套餐和版本不同而略有差异。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 yarenty 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于–,最新版本(0.2.0)于11天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Agent-Native Google Calendar - manage events, sync, and public booking
Create and edit Excel files with AI: charts, PivotTables, formulas. No Excel needed.
Excel automation for AI - Sheets, Power Query, DAX, VBA, Tables, Ranges and more. Windows only.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Every spreadsheet is a table — tableski serves them to your agents in SQL.
Excel, CSV, Parquet, JSON — one penguin-family binary that turns your data files into queryable tables and serves them to AI agents over the Model Context Protocol.
-ski is the family name.Prebuilt binaries (macOS arm64/x86_64, Linux x86_64, Windows x86_64) are attached to GitHub releases:
curl -fsSL https://raw.githubusercontent.com/yarenty/tableski/main/install.sh | sh
Windows: download the .zip from the releases page. Or via cargo:
cargo install tableski
tableski is a standard MCP server over stateless Streamable HTTP — point any client at the server URL:
# Claude Code
claude mcp add --transport http tableski http://127.0.0.1:8080/
// Claude Desktop (claude_desktop_config.json) via mcp-remote
{ "mcpServers": { "tableski": { "command": "npx", "args": ["mcp-remote", "http://127.0.0.1:8080/"] } } }
Or raw HTTP: POST JSON-RPC to / with Accept: application/json (see below).
# One model for every format: --file registers by extension, table name = file stem
cargo run -- --file fixtures/sample.xlsx --file fixtures/sample.parquet \ --file fixtures/sample.ndjson --export-dir ./exports
Ask it something (tools: list_tables, query_sql, get_schema, column_statistics, export_result — all output framed as data per Emperor Profile E8). SQL joins work across formats: an xlsx sheet against a Parquet file against an NDJSON log. export_result writes a query's rows to .csv/.xlsx — only inside the --export-dir sandbox (relative names, no ..; the tool is disabled unless the operator passes the flag):
curl -s -X POST http://127.0.0.1:8080/ \
-H 'Content-Type: application/json' -H 'Accept: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"query_sql", "arguments":{"sql":"SELECT p.name, SUM(o.amount) AS total FROM people p JOIN orders o ON p.name = o.name GROUP BY p.name ORDER BY total DESC"}}}'
Sheet names are slugified into table names (People → people, 2024 Orders → t_2024_orders); first rows become column names when they look like headers (--headers auto|first-row|none to override). Column types are inferred: integers, floats, booleans, dates (as timestamps), text.
Real-world workbooks are messy — tableski handles the mess: both Excel date systems (1900 and 1904), formula cells (cached values ingest; #DIV/0!-style errors become NULL), merged cells (top-left value, NULL continuations), display formats (raw values, always), ragged rows, format-only padding (trimmed), unicode sheet names, and a --max-rows cap that fails loudly instead of cutting silently. The nasty-workbook corpus lives in fixtures/corpus/ — every trait has a fixture and a test.
New here? The five-minute demo uploads a two-sheet workbook to tableski.io or a local tableski, asks the first question, and shows how to ask the rest in plain words with kowalski, Claude or Cursor. Try the whole local flow in one go: ./scripts/demo.sh (spreadsheet → question → SQL answer → exported workbook). demo.tape renders it as a GIF with vhs.
With kowalski, the questions come in plain words and the answers come back as a workbook. Its Spreadsheet analyst profiles the tables through tableski, the model writes one SQL query per question, and every number comes from the query engine:
Status: CSV, Excel (xlsx/xls/ods, hardened against real-world workbooks), Parquet, and
NDJSON all serve today; results export to csv/xlsx; binaries ship per release. Launch is next.
By default tableski runs whatever SQL DataFusion accepts, which is right for a local single-user setup. Add --untrusted-sql when the server is reachable by agents or people you do not control:
tableski --file sales.xlsx --untrusted-sql
Then only read-only queries run: SELECT, WITH, VALUES, EXPLAIN, one statement per request, over registered tables only. CREATE, INSERT, UPDATE, DELETE, DROP, COPY, SET, CREATE EXTERNAL TABLE, table functions (read_csv(...), range(...)) and references to unregistered tables or file paths are rejected on the parsed statement, before anything executes, with an error that names the reason. DataFusion's own DDL/DML/statement switches are turned off as a second fence.
One query cannot take the machine down. Defaults, each 0 = unlimited:
| Flag | Default | What it bounds |
|---|---|---|
--max-memory-mb | 2048 | DataFusion memory pool for the session; a query needing more fails with Resources exhausted instead of growing the process. With a cap set, spilling to disk is off, so it fails fast rather than filling the disk. |
--query-timeout-secs | 60 | Wall clock per query, planning included. The query runs on a dedicated thread pool and is cancelled at DataFusion's next yield point; the server keeps answering meanwhile. |
--max-result-rows | 10000 | Rows a query_sql result carries back. Beyond it the result is cut and ends with a -- result truncated ... line; export_result refuses instead of writing a partial file. |
--max-result-mb | 16 | Same, by Arrow in-memory size. |
Cartesian products (CROSS JOIN, or a join without an = condition) are the one shape a timeout cannot stop once running, so --untrusted-sql refuses them on the plan before execution.
The timeout covers planning as well as execution, so a statement that is expensive merely to optimise is cut too. What the pool does not meter: memory allocated by scalar functions (repeat, lpad, ...). Run a server for untrusted clients under a container memory limit, as the tableski.io deployment does. The whole set is exercised by tests/hostile_sql.rs (DDL/DML, filesystem reach, identifier tricks, blow-ups, parser stress, export traversal); add a line there when you find a new bad shape.
The engine is its own crate, tableski-core: register files into a DataFusion SessionContext, then run the tools with call_tool or serve AppState through any emperor-mcp transport. No HTTP, no CLI.
[dependencies]
tableski-core = "0.1"
let sources: Vec<Box<dyn TableSource>> = vec![Box::new(FileSource::new().path("orders.xlsx"))];
let tables = register_sources(&ctx, &sources, &IngestOptions::default()).await?; let state = AppState::new(Arc::new(ctx), tables); let grid = call_tool(&state, "query_sql", json!({ "sql": "SELECT count(*) FROM orders" })).await?;
Tables come from TableSource implementations. FileSource is the files-on-disk one; a source that streams or refreshes (a price feed, a file that is rewritten) implements the same trait and keeps its state behind its own DataFusion TableProvider, so every query sees the rows that exist when it is planned. The module docs of tableski_core::source spell out the contract; crates/tableski-core/tests/table_source.rs is a worked appending source.
For a server with tenants, Quota and UsageMeter (queries per day, bytes stored, files, rows per file) plug into the same state with with_quota; the meter is in memory, persisting usage is the host's job.
Honest positioning — different tools solve different problems:
| tableski | openpyxl-based Excel MCP servers | Google-Sheets MCPs | |
|---|---|---|---|
| Ask questions over data | SQL engine (DataFusion): joins, aggregates, filters — across sheets *and* file formats | cell/range reads; analysis logic lands in the model's context | per-API calls against live Sheets |
| Formats | xlsx/xls/ods + CSV + Parquet + NDJSON, one table model | xlsx (often read *and write*, incl. formatting/charts — tableski doesn't edit workbooks) | Google Sheets only |
| Deployment | single static binary, stateless Streamable HTTP (Emperor Profile P1) | Python runtime + deps | hosted API + OAuth |
| Output safety | every tool result framed as data (prompt-injection mitigation) | typically raw | typically raw |
If you need to *edit* workbooks (styles, charts, cell writes), pair tableski with a writer-oriented server; tableski is the analysis and export engine.
See CONTRIBUTING.md: run the checks, keep the docs in step, and sign off your commits (DCO, git commit -s).
Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in tableski by you shall be dual licensed as above, without any additional terms or conditions.