Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Laplace's Hoard MCP Server Calculate 15% of 2,347 exactly"
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.
A local calculator, symbolic-math, units, dates, statistics and SQL-over-files engine for a local language model: exact where exactness is possible, and every computation logged with an id the model cites and a person can re-run.
Español · Quick start · Connect to Faustus · MCP reference · Portfolio
Actual application, synthetic demo data (--demo), real queries.
Language models are bad at arithmetic, worse at statistics, and they
"summarise" a table from the first rows they happen to see. A local 27B
model will say that 15% of 2,347 is 351, that a CSV has "about 1,200
rows", or that p = 0.06 is significant, fluently and without warning.
Laplace's Hoard gives the model engines that are exact — 0.1 + 0.2 is
the rational 3/10, round(2.5) is 3 — or explicitly approximate with
the precision stated, runs SQL over the real file instead of letting the
model guess, and logs every computation with an id such as
L-000042. The answer cites [L-000042]; the human opens it in the UI,
sees the exact input and output, and can re-run it.
Related MCP server: leftbrain
Area | Available now | Boundary |
Exact arithmetic ( |
| No variables (use |
Symbolic math ( |
| Each call has a hard 10 s timeout in a worker process. |
Units ( | Pint conversions, compound quantities ("5 ft 11 in"), temperature offsets, dimensional checks, compatible units. | Floating point, rounded to 12 significant digits. No currencies (rates need the network). |
Dates ( | Differences with calendar breakdown, adding days/months/years, business days excluding weekends and public holidays (default Spain/Madrid, any country/region the | Business days count both ends unless |
Statistics ( |
| The interpretation states significance only. Undefined results (e.g. a constant sample) are errors, not NaN. |
Data ( | Register CSV/TSV, Parquet, JSON/NDJSON, Excel (one dataset per sheet), SQLite (one per table) or a folder of files - Spanish-style numbers ( | Queries run on a read-only connection with file access and extension downloads disabled, behind a one-statement gate. Model-facing results are capped (1,000 rows, 500 characters per cell). Sources over 1 GB are linked as views instead of copied. Registration runs in the request (no background job queue yet). |
Work log and audit | Every computation from the UI or the assistant gets an id, is searchable and re-runnable; "Assistant activity" lists only the model's own tool calls. | Stored input/output is capped at 20,000 characters per entry. |
Ask your data | A plain-English (or Spanish) question on the Data screen sends the shared language model the schema, per-column profile and up to 5 sample rows of the chosen datasets (never the full table); it must answer with one SQL query, which runs through the same read-only gate as every other query. The SQL is shown and editable, one retry happens automatically if it fails, and the answer is logged ( | UI only - the agent already writes SQL itself via |
Eight concrete walks, each done both by a person in the browser and by an agent over MCP, are written up in docs/USE_CASES.md (what happened when they were walked: docs/USABILITY_REPORT.md). In short:
Where does my money go? Register a Spanish bank export as it comes
(;, 03/04/2026, -1.150,00, Windows-1252): amounts become exact
numbers on their own, then SQL by category, a chart, and a CSV that a
Spanish Excel opens.
"How much did I spend on groceries?" An agent chains data_register
→ data_query → calc and cites every number; 1.000 or 3,5 typed
the Spanish way get a warning or an error that says how to write them.
Job hunt. An Excel workbook (title rows skipped) → response rate by
work mode → fisher_exact on a 2×2 table → business days since the last
application, Madrid holidays excluded.
Activity and photo libraries. A nested JSON export or a SQLite photo
catalogue: registering stays small (hints to UNNEST, BLOBs shown as
their size), and a chart comes back as a link, not an unrequested image.
Benchmarks. linregress of speed against context length, dropping
crashed runs pairwise, then the earlier result looked up by its id.
Everyday numbers. 21 % VAT, 72 pulgadas -> cm, working days in
Madrid until a date, in the notebook or the units and dates screen.
git clone https://github.com/Luissalet/LaplacesHoard.git
cd LaplacesHoardDouble-click Iniciar Laplace's Hoard.cmd. The first run creates
.venv (Python 3.13 preferred), installs requirements-lock.txt, builds
the interface if frontend/dist is missing, then starts the app in the
background, waits for /api/health and opens the browser.
Detener Laplace's Hoard.cmd stops it. The same from PowerShell:
scripts\start.ps1 [-Port 8812] [-Demo] [-NoBrowser] and scripts\stop.ps1.
Manual steps:
py -3.13 -m venv .venv
.venv\Scripts\python -m pip install -r requirements-lock.txt
cd frontend; npm ci; npm run build; cd ..
.venv\Scripts\python -m laplaces_hoardPython 3.11 or newer and Node 22:
python3 -m venv .venv
.venv/bin/python -m pip install -r requirements-lock.txt
(cd frontend && npm ci && npm run build)
.venv/bin/python -m laplaces_hoard --demoThe app answers on http://127.0.0.1:8812 (curl http://127.0.0.1:8812/api/health).
The engines also work as a library without the server, for example
.venv/bin/python -c "from laplaces_hoard.engines import calc; print(calc.compute('0.1 + 0.2'))".
--demo uses data-demo/, seeded with synthetic sales, sensor and HR
files, instead of your own data/; --port and --data-dir (or
LAPLACE_DATA_DIR) override the defaults; --no-browser skips opening a
tab.
Welch's t-test run on a dataset column, with the p-value first and a neutral interpretation.
Laplace's Hoard vendors HoardLink
(laplaces_hoard/hoard_link/), a small resolver shared by the Hoard family
of local apps, so "Ask your data" uses whichever language model
Faustus or another local OpenAI-compatible server (Ollama, llama.cpp, or
similar) already has loaded,
instead of loading a copy of its own. Resolution order: explicit override
in Settings, then Faustus's own model registry, then a shared server found
on loopback. Everything else in this app - calc, math, units, dates, every
data_* tool - works fully without any model at all; Settings → Models
shows exactly what is available and why, with a Re-check button and manual
overrides (Faustus URL/token, per-capability URL/model).
Laplace's Hoard is a plugin for Faustus
and declares itself with faustus-plugin.json at the repo root. Start the
app, then in Faustus open Connectors → Nearby apps → Add. Faustus finds
it on port 8812, checks /api/health, launches the MCP adapter and loads
the exact-numbers skill. The adapter is a stdio script started by path,
with the app's URL in LAPLACE_URL:
$env:LAPLACE_URL = "http://127.0.0.1:8812"
.venv\Scripts\python.exe laplaces_hoard\mcp_server.pytool | read-only | what |
| yes | Exact arithmetic, percentages, number theory |
| yes | Solve, differentiate, integrate, limits, series, matrices |
| yes | Unit conversion |
| yes | Descriptive statistics and hypothesis tests |
| yes | Date differences, business days, time zones |
| yes | Registered datasets |
| no | Add a file or folder as a dataset |
| yes | Schema, profile, sample rows |
| yes | Read-only SQL |
| yes | Chart as an image |
| yes | Recall an earlier computation by id |
It works with any MCP client over stdio; docs/MCP.md has the configuration snippet, every argument, output shape and limit.
Real tool calls made through the MCP adapter (scripts/demo_agent_session.py) against the demo data.
flowchart LR
UI["React interface"] -->|"/api/ui/*"| API["FastAPI app on 127.0.0.1:8812"]
Model["Faustus or any MCP client"] -->|"stdio"| MCP["mcp_server.py"] -->|"/api/agent/*"| API
API --> Engines["engines: calc, math, units, dates, stats, data"]
Engines --> Worker["worker process with hard timeout"]
Engines --> DuckDB[("DuckDB catalogue, read-only queries")]
API --> Log[("SQLite work log and notebook")]FastAPI over pure-Python engines (no FastAPI imports), SQLite for the work log and notebook, DuckDB for the dataset catalogue, one spawn-context worker process with a hard timeout for everything that evaluates expressions, and a React interface. The MCP adapter is a separate script that only speaks HTTP to the app. docs/ARCHITECTURE.md covers the connection model, the SQL gate, the worker and the browser guard.
.venv\Scripts\python -m pytest -q
cd frontend; npm ci; npm run build237 tests, offline, about a minute. They cover the AST whitelist
(__import__, attributes, lambdas, comprehensions), exact decimals and
rounding, precision up to 1000 digits, runaway and memory-bomb inputs
(timeout, recovery, refusal), concurrent calls through the worker, solve
verification, Pint temperature offsets, Welch's t-test and other results
against SciPy, business days across Madrid holidays, day-first and Spanish
dates, the SQL gate against every write and file-reading statement,
registration after queries, file names with spaces and accents, Excel
sheets and SQLite tables as datasets, a data directory under a folder with
an apostrophe, profile numbers on a known table, chart PNGs, the SPA
fallback against path traversal, the error envelope, the UI/assistant
split of the audit log, the faustus-plugin.json checker, and the MCP
protocol itself: the adapter spawned over stdio against a live app,
listing tools (keywords and annotations on each) and calling calc,
data_register, data_query, math, data_chart (a chart_url, and the image only when asked) and
work_log; the shared model backend's status/config endpoints (a token
is never echoed back) and "Ask your data" against a mocked language model
(httpx.MockTransport): what the prompt contains (schema, at most 5 sample
rows), a good SQL answer, one retry that carries the error, a clear error
when the model does not answer in SQL, and the honest "unavailable" state
with no model resolved; saved overrides can be cleared, a config the form
never sends is refused, and a broken backend.json does not stop the app.
The use-case walks added regression tests for Spanish CSVs (separators,
encodings, re-registering), Excel title rows, BLOB and nested columns,
decimal-comma hints in calc/math, notebook error messages and the
Spanish CSV export.
The app binds 127.0.0.1 only and has no telemetry. It makes no network
requests: exchange rates and holiday downloads are out of scope, and
DuckDB extension auto-install is disabled. Data stays in data/
(gitignored) or wherever --data-dir points; registering a file copies it
into the local catalogue and never modifies the original. A middleware
rejects DNS rebinding (wrong Host) and cross-site writes (foreign
Origin or Sec-Fetch-Site: cross-site) on every route. Every tool call is
audited in the work log with its source (UI or assistant), input, output,
duration and status, and "Assistant activity" shows exactly what the
model ran. The Windows launch scripts were exercised with PowerShell 7 on
Linux; CI runs the tests on Ubuntu with Python 3.12 and builds the
interface with Node 22.
A few fixed UI strings stay in English even in the Spanish interface (engine messages, test interpretations, weekday names, chart-kind labels); translating them is planned.
A dataset registered by mistake cannot be removed from the UI or API yet, only re-registered over.
Adding a file means typing or pasting its path; there is no file picker or drag-and-drop yet.
The MCP list_tools payload is sizeable (about 20,000 characters,
roughly 5k tokens, before the first call), which is fine at a 32k
context window but heavy at 8k. Shortening the descriptions waits on a
measurement of whether it hurts tool selection by small models.
The dataset and profile cards can overflow horizontally on very narrow
windows, and a chart shows a missing category as null instead of
hiding it.
See docs/USABILITY_REPORT.md for the full list of open items and how each one was found.
MIT - see LICENSE.
Exact arithmetic. Never do arithmetic in your head: call this, even for "simple" sums.
Write Python-like syntax: + - * / // % ** (or ^), parentheses, comparisons.
Functions: sqrt cbrt root(x, n) exp ln log(x, base) log10 log2, trig, floor
ceil round(x, n) abs, min max sum mean median (numbers or one list),
factorial binomial gcd lcm mod, isprime nextprime factorint (alone), and
percentages: pct(15, 2347) = 15% of 2347, pct_change(old, new) = % change,
ratio(a, b). Constants: pi e tau inf. Numbers are exact: 0.1 + 0.2 = 3/10.
Examples: "pct(21, 1250)", "(1.05^10 - 1) * 100", "mean([3, 5, 8])".
Returns {id, cite, exact, decimal (text, precision significant digits),
is_exact (true when decimal is the exact value), latex}. No variables: use
math for x, y. Cite the number as its cite, e.g. [L-000042].
Keywords: calculate, compute, how much is, percentage, percent of, discount, VAT, interest, average, square root, factorial, is prime, calcular, cuánto es, cuánto son, porcentaje, tanto por ciento, descuento, IVA, interés, media, raíz cuadrada, factorial, es primo.
| Name | Required | Description | Default |
|---|---|---|---|
| precision | No | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses that numbers are exact, gives the return format with cite/exact/decimal, and specifies that the cite should be used when referencing the result. This gives the agent important behavioral context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed with useful information. It is front-loaded with the core directive, then organized into syntax, functions, return format, and keywords. Some keyword repetition could be trimmed, but the structure is clear and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity and no output schema, the description is remarkably complete: it covers syntax, functions, constants, exactness semantics, return fields, limitations, and sibling differentiation. An agent has enough information to invoke it correctly and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by specifying the expression syntax, supported operators, functions, constants, and example expressions. It also explains the role of precision in the decimal output, giving meaning to both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states that this tool performs exact arithmetic and explicitly instructs the agent to call it even for simple sums. It also distinguishes itself from the sibling 'math' tool by noting that variables should be handled there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: never do arithmetic in your head, call this tool for any calculation. It also gives a clear exclusion and alternative, saying 'No variables: use math for x, y,' which routes the agent to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a chart from a read-only SQL query and save it; only returns the image if you ask.
kind: bar, line, area, scatter, histogram (x only), pie (x = category, y = value), heatmap (x and y). x, y and color are column names of the query result, so aggregate in SQL first, e.g. sql="SELECT region, SUM(amount) AS total FROM sales GROUP BY region", kind="bar", x="region", y="total". bar/line/area without y count rows. Uses at most 5000 rows.
The chart is always saved and logged with its own id, visible in the
app's Work log (its detail view shows the image). include_image
defaults to false and returns only a short JSON summary (id, cite,
row_count, encoding) - a text-only model must not receive an unrequested
image, it can crash the turn. Only set include_image=true when you can
see images and actually need to look at this one; otherwise just tell
the person the returned chart_url (or [id] in the app), or call this again with
include_image=true if you need to read values off the chart yourself.
Keywords: chart, plot, graph, bar chart, line chart, histogram, pie chart, visualize, gráfico, gráfica, gráfico de barras, gráfico de líneas, histograma, gráfico circular, visualizar.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | No | ||
| sql | Yes | ||
| kind | Yes | ||
| color | No | ||
| title | No | ||
| include_image | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that every chart is saved and logged with its own id, is visible in the Work log, consumes at most 5000 rows, and returns only a short JSON summary by default. It also warns that an unrequested image can crash a text-only model, which is crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense: it front-loads the core purpose, then details chart kinds, parameter semantics, output behavior, and safety warnings. The keyword list is scannable and useful for selection. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description is remarkably complete: it names the returned JSON fields, explains how to locate the chart in the app, gives the chart_url/id fallback, and covers image-return behavior. An agent has enough information to call this tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0%, so the description carries the full burden, and it succeeds: it explains kind-specific x/y requirements, that x/y/color are column names, that aggregation should happen in SQL, that bar/line/area without y count rows, and the include_image default behavior. Nearly every parameter's semantics is covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Draw a chart from a read-only SQL query and save it.' It then enumerates chart kinds, required columns, and an example, making the tool's purpose unmistakable and clearly distinct from sibling data tools like data_query or data_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: aggregate in SQL first, respects a 5000-row limit, and provides explicit rules for include_image ('only set include_image=true when you can see images'). However, it does not explicitly name alternatives among sibling tools or state when not to use data_chart in favor of, say, data_query or data_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schema, row_count, per-column profile (nulls %, distinct, min/max/mean/sd, top values) and 5 sample rows.
Before answering anything about a table, call this, then data_query:
never guess column names, types or row counts. row_count here is the
true size of the dataset. Sample rows are examples, not the data - do
not summarise the table from them; aggregate with data_query instead.
Keywords: describe this dataset, what columns, schema, how many rows, column types, summary of the table, describe este dataset, qué columnas, esquema, cuántas filas, tipos de columna, resumen de la tabla.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context beyond annotations by stating that row_count is the true dataset size and that sample rows are examples, not the data, preventing misuse. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The output spec is front-loaded and the usage guidance is dense and useful. The keyword block, including Spanish duplicates, adds length but supports retrieval and does not introduce redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers output shape, when to invoke the tool, and how it relates to data_query, especially given there is no output schema. The main gap is the unstated semantics of the `name` parameter, which is already penalized under parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, `name`, has no schema description and schema coverage is 0%. The description never explains that `name` is the table or dataset identifier or how it should be supplied, leaving the agent to infer this from the tool name and surrounding context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first line precisely specifies the tool's output: schema, row_count, per-column profile with named statistics, and 5 sample rows. The instruction to call this before data_query clearly distinguishes it from the data_query sibling, which handles aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: before answering anything about a table, never guessing column names, types, or row counts. It also names the alternative, data_query, for aggregation and warns against summarizing from sample rows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the registered datasets: name, kind, row_count, column names.
Call this first when the user mentions a table or file and you do not
know its dataset name. Query a dataset by its name in SQL. An empty
list means nothing is registered yet: use data_register with the path.
Keywords: what data do you have, list datasets, tables, files, spreadsheets, qué datos hay, qué tablas hay, lista de datasets, archivos, hojas de cálculo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description responsibly adds behavioral context: it lists what is returned and explains the empty-list meaning. This goes beyond re-stating annotations without overclaiming.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core definition and usage guidance are front-loaded in the first two sentences. The keyword list is slightly redundant but can aid retrieval and does not make the description bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description covers purpose, output fields, when to use it, empty-result behavior, and the next action to take. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parametersional signature, so there is nothing for the description to explain. Baseline for a no-parameter tool is 4, and the description adds no conflicting parameter claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List'), resource ('registered datasets'), and the exact output fields (name, kind, row_count, column names). This clearly distinguishes it from sibling query, register, and describe tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call this first when the user mentions a table/file and the dataset name is unknown. It also gives a concrete alternative: if empty, use data_register with the path, and instructs querying by `name` in SQL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one read-only SQL query (DuckDB dialect) over the registered datasets.
Allowed: SELECT / WITH / DESCRIBE / SUMMARIZE / EXPLAIN / PIVOT, one
statement; anything that writes or reads files directly is rejected.
Refer to datasets by name: SELECT region, SUM(amount) AS total FROM sales
GROUP BY region ORDER BY total DESC. Let SQL do the counting and
summing - do not add up returned rows yourself.
Returns {id, cite, columns, rows (at most limit, default 50, max 1000),
row_count (rows returned), total_rows (rows the query produced),
truncated}. Long text cells are cut at 500 characters. Call
data_describe first if you have not seen the schema.
Keywords: query the data, SQL, filter rows, group by, total of, sum of, average of, count, top 10, consultar los datos, filtrar, agrupar por, total de, suma de, media de, contar, los 10 primeros.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive, and the description adds substantial behavioral detail: accepted statements, rejected operations, return shape with id/cite/columns/rows/row_count/total_rows/truncated, the 50-default/1000-max limit, truncation at 500 characters, and the instruction to let SQL do aggregation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured, moving from purpose to constraints to example to return semantics and prerequisite. The keyword list at the end is slightly repetitive but aids retrieval; no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and no output schema, the description supplies everything needed: allowed SQL constructs, example syntax, return field semantics, row limits, truncation behavior, and a clear prerequisite. Nothing material is missing for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates. The sql parameter's syntax and constraints are explained with an allowed-statement list and an example, while the limit parameter's default and maximum are stated in the return-format note. This is more than enough semantic meaning for an agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Run one read-only SQL query (DuckDB dialect) over the registered datasets.' It enumerates allowed statement types and gives a concrete query example, making it clearly distinct from sibling tools like data_list, data_describe, and data_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: must be a single statement, writes and direct file reads are rejected, and data_describe should be called first when the schema is unknown. It does not explicitly enumerate when to prefer siblings like data_list or data_chart, but the guidance is clear enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a local file or folder so it can be queried with SQL: CSV/TSV, Parquet, JSON/NDJSON, Excel, SQLite.
path is an absolute path on this computer (e.g. C:\Users\me\ventas.xlsx).
The dataset name defaults to the file name made SQL-safe ("Ventas 2024"
becomes Ventas_2024) - use the returned name. Excel registers one
dataset per sheet ("__"), SQLite one per table, a folder
all files matching options.glob (default "*.csv"). CSV options:
delimiter, header, encoding (utf-8/utf-16/latin-1; auto-detected when
omitted, so Windows-1252 exports work without setting anything),
date_format (e.g. "%d/%m/%Y"; two-digit-year day-first dates like
"13/02/25" are auto-detected already), decimal_separator and
thousands_separator. Spanish-style numbers ("-1.150,00", "51,05") are
detected automatically and become exact numbers - the result lists them
under numbers_converted; pass decimal_separator="." to keep such a
column as text, or both separators to force another convention.
Excel also takes skip_rows (a title row above the real header is
detected and skipped automatically; set this to override).
Returns the schema and profile (like data_describe); a single-row result
with nested list columns also gets a hint suggesting UNNEST.
Re-registering the same path refreshes it. Not read-only: it copies the
data into the local catalogue (the original file is never modified).
Keywords: load this file, open this spreadsheet, register dataset, import CSV, read Excel, cargar este archivo, abrir esta hoja de cálculo, registrar datos, importar CSV, leer Excel.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| path | Yes | ||
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, the description adds valuable side-effect detail: data is copied into the local catalogue, the original file is never modified, and re-registering the same path refreshes it. This goes well beyond the boolean hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but logically structured: purpose first, then path/naming, format-specific behavior, options, return value, and side effects. Some edge-case detail and the trailing keyword block could be trimmed, but the density is justified by the tool's complexity and each section builds on the previous one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex registration tool with no output schema, the description thoroughly covers what the tool does, supported formats, options, return behavior, and side effects. It even explains the schema/profile return and the UNNEST hint edge case. The only minor omission is explicit confirmation that the `name` parameter overrides the default, which is inferable from context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full parameter burden. It explains path must be absolute, naming defaults to a SQL-safe file name, Excel registers one dataset per sheet, SQLite one per table, folder uses glob defaulting to *.csv, and details CSV/Excel options like encoding, date_format, decimal separators, and skip_rows. This gives the name and options parameters concrete meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Register a local file or folder so it can be queried with SQL', giving a specific verb and resource plus the tool's core purpose. It enumerates supported formats and clearly differentiates it from siblings like data_query, data_describe, and data_list as the ingestion step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use the tool: to load local files or folders for SQL querying, with concrete scenarios like Excel sheets, SQLite tables, and folder globs. It lacks an explicit 'use data_query instead when data is already registered' statement, but the ingestion role and refresh behavior make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Date arithmetic: days between dates, adding time, business days, weekdays, ages, time zones.
operation and its arguments:
diff: start, end, unit days|weeks|months|years (also returns the calendar breakdown years/months/days).
add: start plus days/weeks/months/years (negative to subtract).
business_days: start, end; weekends and public holidays excluded, both ends counted (include_end=false to stop the day before). Default Spain, Madrid calendar; pass country (ISO code: FR, DE, US...) and subdivision.
weekday / iso_week: value. age: birth_date (+ on, default today).
convert_tz: value, from_tz, to_tz (IANA names: Europe/Madrid,
America/New_York, UTC). parse: text.
Dates: prefer YYYY-MM-DD. "today"/"hoy" works. Numeric dates are read
day-first as in Spain (03/04/2026 = 3 April); Spanish month names work.
Cite as its cite, e.g. [L-000042].
Keywords: how many days between, days until, business days, working days, add days, deadline, time zone, what day of the week, how old, cuántos días entre, cuántos días faltan, días laborables, días hábiles, sumar días, plazo, zona horaria, qué día de la semana, qué edad tiene.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | ||
| end | No | ||
| days | No | ||
| text | No | ||
| unit | No | days | |
| start | No | ||
| to_tz | No | ||
| value | No | ||
| weeks | No | ||
| years | No | ||
| months | No | ||
| country | No | ES | |
| from_tz | No | ||
| operation | Yes | ||
| birth_date | No | ||
| include_end | No | ||
| subdivision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds substantial context beyond that: business-day defaults to Spain/Madrid, both ends counted, inclusion of public holidays, day-first numeric date parsing, Spanish month-name support, and the citation requirement. This is exactly the kind of behavioral nuance an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well structured with a lead summary, per-operation bullets, a date-parsing note, and a keyword list. Some redundancy exists between the operation list and the keywords section, but every part adds operational value for a 17-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity, zero schema descriptions, and no output schema, the description is remarkably complete: it covers all operations, parameter meanings, defaults, date-format expectations, locale behavior, and trigger phrases. An agent can determine both when to invoke it and how to construct a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it succeeds. It maps every operation to its relevant parameters: diff uses start/end/unit, business_days uses start/end/include_end/country/subdivision, age uses birth_date/on, convert_tz uses value/from_tz/to_tz, and parse uses text. Even defaults and accepted formats are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Date arithmetic', then enumerates the concrete operations (diff, add, business_days, weekday/iso_week, age, convert_tz, parse). This clearly separates date_calc from generic siblings like calc and math, and from units_convert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong contextual guidance through operation names and a keyword list ('how many days between', 'business days', 'deadline', 'zona horaria', etc.). It does not explicitly name sibling tools or say when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Symbolic math with SymPy: solve equations, derivatives, integrals, limits, series, matrices.
operation is one of: simplify, expand, factor, apart, together, solve,
nsolve, diff, integrate, limit, series, summation, product, matrix,
dsolve, inequality. Syntax as in calc, plus variables; an equation is
written x**2 - 5*x + 6 = 0 (or ==).
solve: expression="2*x + 1 = 7" (or expressions=[...] for a system,
variables=["x", "y"]); domain real|complex. Each solution has values
(exact), numeric and verified (substituted back) - check it.
diff: expression, variable, order. integrate: expression, variable, optional lower/upper for a definite integral. limit: expression, variable, point (e.g. "oo"), direction "+"/"-". series: variable, point, order. summation/product: variable, lower, upper.
nsolve: numeric root near x0. inequality: expression="x**2 < 4".
dsolve: dy/dx = expression, in symbols x and y (e.g. "y - x").
matrix: matrix_op det|inv|rank|rref|eigenvals|transpose|multiply and
matrix=[[1, 2], [3, 4]] (matrix2 for multiply).
variable can be omitted when the expression has only one symbol.
Hard timeout (10 s): on timeout, simplify the input instead of retrying.
Cite results as their cite, e.g. [L-000042].
Keywords: solve for x, equation, derivative, integral, differentiate, simplify, factor, limit, series, matrix determinant, inverse matrix, eigenvalues, resolver, ecuación, despejar, derivada, integral, simplificar, factorizar, límite, serie, matriz, determinante, autovalores.
| Name | Required | Description | Default |
|---|---|---|---|
| x0 | No | ||
| lower | No | ||
| order | No | ||
| point | No | ||
| upper | No | ||
| domain | No | real | |
| matrix | No | ||
| matrix2 | No | ||
| function | No | ||
| variable | No | ||
| direction | No | ||
| matrix_op | No | ||
| operation | Yes | ||
| variables | No | ||
| expression | No | ||
| expressions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds a hard timeout (10 s) with a fallback, the need to cite results via [L-...], and the fact that solve returns verified substitutions. These go beyond annotations and are useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed. It front-loads the purpose, then compactly lists operations with examples. The structure uses bullet points and minimal prose. It includes multilingual keywords, which may be extraneous but do not bloat the core content. No redundant sentences; each earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters, 15 operations, and no output schema, the description covers parameter usage per operation, timeout behavior, citation, and a verification note for solve. The only gap is that return formats for operations other than solve are not specified. Overall, it provides enough to call the tool correctly for most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description fully compensates by detailing each operation's relevant parameters: solve (expression, expressions, variables, domain), diff (variable, order), integrate (lower/upper), limit (point, direction), series (point, order), summation/product (lower, upper), matrix (matrix_op, matrix, matrix2), and nsolve (x0). It also notes that 'variable' can be omitted when only one symbol exists, adding meaning well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs 'Symbolic math with SymPy' and enumerates specific operations (solve, diff, integrate, limit, series, matrices). This clearly distinguishes it from numeric siblings like calc, and the verb+resource is specific. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for symbolic math problems and references 'Syntax as in calc', but it does not explicitly state when not to use it or which alternative to use for numeric calculations. No exclusions or alternative hunt is provided, leaving selection partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Descriptive statistics and hypothesis tests (SciPy), with a neutral one-line interpretation.
test is one of: describe, ttest_1samp (vs mu), ttest_ind (Welch),
ttest_rel (paired), mannwhitneyu, wilcoxon, chi2_contingency and
fisher_exact (data = table, e.g. [[8, 2], [1, 9]]), pearson, spearman,
linregress (x in data/column, y in data2/column2), proportion_ci
(Wilson; successes, trials, confidence), normal_ci (mean CI), binom_test
(successes, trials, p0).
Numbers come inline (data, data2) or from a registered dataset:
dataset + column (+ column2), group_by = a column with exactly two
values for two-sample tests, where = a row filter such as
"region = 'North'". Dataset columns use every row, not a sample.
Report the p_value and effect size as given; the interpretation states
significance only - never add causal claims. Cite as its cite.
Keywords: statistics, t-test, is it significant, p-value, correlation, regression, confidence interval, average, standard deviation, median, estadística, prueba t, es significativo, valor p, correlación, regresión, intervalo de confianza, media, desviación típica, mediana.
| Name | Required | Description | Default |
|---|---|---|---|
| mu | No | ||
| p0 | No | ||
| data | No | ||
| test | Yes | ||
| data2 | No | ||
| where | No | ||
| column | No | ||
| trials | No | ||
| column2 | No | ||
| dataset | No | ||
| group_by | No | ||
| successes | No | ||
| confidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description reveals important behavior: it returns a 'neutral one-line interpretation', reports p_value and effect size as given, states significance only, forbids causal claims, and requires citing as its `cite`. It also warns that dataset columns use every row, not a sample. This is substantial added transparency with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then uses a structured, scannable list of tests and data modes. It is longer than average, and the bilingual keyword list is somewhat redundant, but every substantive section supports invocation and interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no parameter descriptions in the schema, this description is unusually complete: it covers test selection, data input modes, row filtering, group_by constraints, output/interpretation expectations, and citation. It does not detail exact return formatting or distinguish itself from data_describe, but the essential information for correct use is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden, and it does. It maps test names to their parameters, e.g. ttest_1samp (vs mu), fisher_exact (data = table with an example), linregress (x in data/column, y in data2/column2), and proportion_ci/binom_test (successes, trials, confidence/p0). It also explains dataset + column (+ column2), group_by, and where.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the tool's function precisely: 'Descriptive statistics and hypothesis tests (SciPy), with a neutral one-line interpretation.' The body then names all supported tests, such as ttest_1samp, mannwhitneyu, fisher_exact, pearson, and linregress, making it easy to distinguish from arithmetic, date, and data-list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: when to use inline data versus a registered dataset, how group_by works for two-sample tests, how where filters rows, and which parameters each test expects. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a physical quantity to another unit, e.g. quantity="3.5 km/h", to="m/s".
Handles compound inputs ("5 ft 11 in" to "cm"), temperatures with their
offsets ("100 degF" to "degC" is 37.78, not a plain scale), and derived
units (kWh, psi, mph, g/cm**3). Unit names are English/SI symbols (m,
km, mi, ft, in, kg, lb, g, L, gal, degC, degF, K, s, min, h, km/h, mph,
J, kWh, W, Pa, bar, psi) or their common Spanish names (metros,
kilómetros, millas, pies, pulgadas, libras, kilogramos, litros, horas,
minutos...). A decimal comma with no dot in the input ("3,5 km") is read
as 3.5, not 35. No currencies (rates need the network). Returns {id,
cite, to_magnitude, to_unit, formatted} rounded to 12 significant
digits. Cite as its cite, e.g. [L-000042].
Keywords: convert, how many, in meters, in kilograms, miles to km, pounds to kilos, temperature, fahrenheit, celsius, convertir, cuántos, pasar a, en metros, en kilos, millas a kilómetros, libras a kilos, temperatura, grados.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| quantity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral detail: compound input parsing, temperature offset handling, decimal comma interpretation, supported unit families, return shape, 12-significant-digit rounding, and citation instructions. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes: core purpose, examples, edge cases, accepted units, return format, and retrieval keywords. It is front-loaded with the essential conversion behavior and avoids unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description discloses the return object fields and rounding behavior. It covers input formats, unit variations, special cases like temperature offsets, and explicit non-support for currencies. An agent has enough to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the full burden. It thoroughly explains both parameters through examples: quantity accepts values like '3.5 km/h' or '5 ft 11 in', and to accepts targets like 'm/s', 'cm', or 'degC'. Supported unit lists and formatting rules add meaning far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Convert a physical quantity to another unit', with a concrete example. The scope is clearly distinct from sibling tools like calc or math, and the keyword list reinforces the conversion purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: physical unit conversions, compound inputs, temperatures, derived units, Spanish unit names, and decimal comma handling. It also gives an explicit exclusion ('No currencies'), but does not name alternative sibling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent computations from the work log (yours and the human's), newest first, each with its id.
Use it to reuse a number computed earlier instead of recomputing or remembering it, or to look one up by id: query="L-000042" returns that entry in full. engine filters by calc|math|units|stats|dates|data; query searches operation and input text. Items are short summaries (limit default 10, max 50; has_more tells you there are older ones).
Keywords: what did I calculate, previous result, earlier computation, history, look up L-, qué calculé, resultado anterior, cálculo previo, historial.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| engine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral detail: newest-first ordering, inclusion of both user and human entries, short-summary format, limit defaults and maximum, has_more for older items, and the fact that an id query returns a full entry. This goes well beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core behavior is front-loaded in the first sentence, and each paragraph adds distinct value: usage, parameter semantics, and search keywords. The keyword list is slightly long but serves multilingual and paraphrase matching, so it earns its place. Minor redundancy such as restating 'look up L-' in the keywords is acceptable given the concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does a good job describing return shape: entries have ids, are short summaries, newest first, and has_more indicates older results. It does not spell out every field of a full entry or the exact JSON shape, but for a list/query tool with no required parameters and clear behavior, what is provided is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the full parameter burden, and it does. It explains limit (default 10, max 50), query (searches operation and input text; an id like L-000042 returns the full entry), and engine (filters by calc|math|units|stats|dates|data). This gives an agent everything needed to use each parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Recent computations from the work log (yours and the human's), newest first, each with its id.' It clearly frames the tool as a read-only history/reuse tool, which distinguishes it from sibling calculators like calc or math and from data_list, which handles registered data rather than computation history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use cases: 'reuse a number computed earlier instead of recomputing or remembering it, or to look one up by id.' It also explains filtering behavior with query and engine. It does not explicitly name sibling alternatives for new calculations, but the 'instead of recomputing' phrasing makes the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0calcdata_chartdata_describedata_listdata_querydata_registerdate_calcmathstatsunits_convertwork_logScored across 11 tools
The tools map cleanly to distinct domains—arithmetic, symbolic math, units, stats, dates, data registration/query/charting, and history—so confusion is rare. The main overlap is between calc and stats, since calc includes mean/median and stats also covers descriptive statistics, so a query about 'average' could route to either. The data_* tools are clearly separated by lifecycle stage.
Most multi-word tools use a consistent snake_case pattern (units_convert, date_calc, data_list, data_query, data_chart, work_log). The three single-word names (calc, math, stats) are predictable domain shortcuts and don't break readability, but they deviate from a strict verb_noun convention. Overall the naming is consistent enough that an agent can infer function from the name.
11 tools is well-scoped for a general-purpose computation and data analysis server. Each tool covers a meaningful capability without redundant extras, such as having separate tools for every statistical test or SQL variant. The count feels intentional, and each tool earns its place.
The surface covers the full cycle for computation: exact/symbolic math, units, dates, statistics, and data ingestion → description → querying → visualization → history lookup. Minor gaps exist—there is no unregister/drop operation for datasets and no currency conversion—but these are explicitly out of scope or easily worked around. No common workflow dead-ends appear for the stated domain.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
AI access to Quadratic spreadsheets: open files, run Python/SQL, query connected databases.
