Hosted: plan and build multi-table test and demo data, export 25 formats, with checks shown.
Scored across 13 tools
Most tools map to distinct stages of the synthetic-data workflow: plan, validate, generate, monitor, query, export, and inspect. A few pairs require careful reading to distinguish, notably generate_dataset vs start_generation (sync vs async) and check_answers vs get_certificate (answer checking vs certification/answer key).
The set follows a mostly consistent snake_case verb_noun convention: generate_dataset, query_dataset, export_dataset, validate_blueprint, cancel_generation. Minor deviations are blueprint_guide and whoami, which are noun/reference-style names rather than verb-led actions.
Thirteen tools is well-scoped for a platform covering dataset planning, generation, validation, querying, export, certification, and account introspection. Each tool appears to earn its place, with the async lifecycle tools justified by long-running generation jobs.
The surface is broad and covers the main lifecycle from discovery and planning through generation, validation, querying, export, and answer checking. Minor gaps exist around managing generated datasets, such as listing or deleting existing datasets, but agents can work around this given the temporary dataset retention model.
The reference for the engine's full design language (the `blueprint` argument of generate_dataset,
start_generation and validate_blueprint): roles, distributions, formulas that read parent columns
and draw noise, per-group sequences (seq, lag, cumsum, ar1 drift, random walk), aggregates, event
windows, cause-and-effect, lifecycles, with patterns, and an index of chapters. Read it before
writing a blueprint.
Args:
topic: a chapter's id from the index (or several, comma-separated) for that chapter in full, with
a world that builds as written: JSON payloads (webhooks, audit trails), threads of messages,
one party's duplicate records, running balances, rosters made from demand, a source system's
raw drops and schema changes, planted problems for an eval. Empty for the reference.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safe-read profile is fully covered without the description. The description adds that an empty topic yields the index/reference and that topics expand into worked "worlds", but discloses nothing about size, cost, or truncation for large chapters.
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 purpose is front-loaded and the topic explanation is useful, but the middle section bloats: "JSON payloads (webhooks, audit trails), threads of messages, one party's duplicate records, running balances, rosters made from demand, a source system's raw drops and schema changes, planted problems for an eval" is a long illustrative list that does not help an agent choose or call the 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?
An output schema exists, so return values need no explanation, and the description covers what content is reachable and how `topic` selects it. For a one-parameter read-only reference tool this is essentially complete, with only the chapter-id vocabulary left to the index itself.
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 does it well: it defines `topic` as a chapter id from the index, allows several comma-separated ids, and states that empty returns the whole reference. Only the exact id format/naming is left implicit.
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 names a specific resource (the engine's full design language / blueprint argument) and enumerates exactly what it covers: roles, distributions, formulas, sequences, aggregates, event windows, lifecycles. It also distinguishes itself from siblings by tying the content to the `blueprint` argument of generate_dataset, start_generation and validate_blueprint, so an agent can tell this is the reference companion, not a generator.
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?
"Read it before writing a blueprint" gives an explicit trigger condition for calling this tool, which is exactly the guidance a reference tool needs. It does not name a when-not condition or an alternative resource, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running start_generation job. It stops at the next stage boundary and keeps nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive, idempotent, non-read-only behavior, so the bar is lower; the description adds genuinely useful semantics by noting cancellation is not immediate ('stops at the next stage boundary') and that no partial output is retained ('keeps nothing'). It still omits whether the job_id remains queryable afterward and what the response contains.
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?
Two short sentences, front-loaded with the action, with no filler. Every clause carries information about scope or timing.
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 single-parameter tool with no output schema and annotations covering safety, the description is nearly complete on behavior, but it never tells the agent where to obtain job_id or what happens to the job record after cancellation — the one real gap 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?
One parameter with 0% schema description coverage, and the description never explains job_id — where it comes from (presumably start_generation) or its format. It only implicitly links the param to a 'running job', so it does not compensate for the documentation gap.
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 ('Stop a running start_generation job') and names the sibling tool that creates the job, so an agent can distinguish it from start_generation, get_status, and the other siblings without opening a schema.
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?
Usage is implied by the pairing with start_generation, but there is no explicit statement of when to cancel versus checking status (get_status) or letting the job finish. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The dataset's ground truth: every number it is held to, and the business's standard numbers (MRR, churn, billed
revenue, win rate...), by month, worked out when it was made. Use it to test whatever answers questions about the
data -- an agent, a dashboard, a cube, a text-to-SQL model -- and to say exactly why a wrong answer is wrong.
Call it four ways:
1. dataset_id alone: the key's numbers (`kpis`: id, title, unit, months) and `questions` to ask, drawn from
the key ("What is MRR at each month's end for 2025-07?"), each with an id. Their answers are not shown.
2. answers={question_id: number}: each answer graded within its tolerance; a wrong one is named as the
usual misreading it equals (voided invoices counted, churn over every account), when it is one.
3. values with kpi: numbers computed anywhere (ClickHouse, a semantic layer, a BI tile), as one number, a
{"2025-07": 123.4, ...} series by month, or [[month, value], ...]. Says whether they are that KPI (a tile
is read as its latest month, the year to date, ...), and what they are instead when not.
4. sql (and kpi): a query over this dataset's own tables (DuckDB, as query_dataset), run here; a wrong one is
told which KPI it computes, or the one change after which it returns the key.
The values are plain numbers, so an answer from any engine is checked the same way; export_dataset(format="demo",
dialect="clickhouse") hands over the same data and key to load into ClickHouse.
| Name | Required | Description | Default |
|---|---|---|---|
| kpi | No | ||
| sql | No | ||
| seed | No | ||
| values | No | ||
| answers | No | ||
| questions | No | ||
| dataset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond that: tolerance-based grading, naming a wrong answer as the specific misreading it equals, reading a BI tile as its latest month, and running SQL over the dataset's own DuckDB tables. This is genuinely useful disclosure of failure and evaluation behavior.
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 purpose is front-loaded and the four modes are cleanly numbered, so it scans well. Some sentences are convoluted (the parenthetical asides about misreadings and tile interpretation), costing a little readability, but every sentence carries information.
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 takes on the burden of describing returns and does so per mode: kpis and questions in mode 1, per-answer verdicts in mode 2, KPI identification in mode 3, and query verdicts in mode 4. An agent has enough to call it correctly across all four modes.
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 load, and it does for six of seven parameters, defining concrete formats for values (scalar, {'2025-07': 123.4}, [[month, value]]), the question_id-to-number shape of answers, and the role of kpi and sql. The seed parameter is never mentioned in either the schema or the description, leaving one parameter opaque.
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 opening sentence states a specific verb and resource: it holds the dataset's ground-truth numbers and grades answers against them. It also explicitly contrasts itself with siblings by noting the sql mode runs 'as query_dataset' and pointing to export_dataset for handing the same data to ClickHouse.
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 enumerates four distinct invocation modes with the exact argument combination that selects each (dataset_id alone, answers, values+kpi, sql+kpi) and states the purpose of each. An agent can pick the right mode without guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a generated dataset as a file. Returns a `download_url` the person can open (or you can
fetch, e.g. with curl) for as long as the dataset is held, about 2 hours. Give the person the link
rather than pasting file contents into the chat.
Args:
dataset_id: from a prior generate_dataset call.
format: data: csv, parquet, jsonl, json, avro, xlsx, feather, orc, sqlite, duckdb, sql.
code and docs: dbt, notebook, dictionary, dbml, mermaid, prisma, sqlalchemy,
typescript, jsonschema, expectations, django, openapi, mockapi.
`sql` is schema.sql (DDL with keys) + data.sql (COPY/INSERT) — the way to seed a
real database: run the returned SQL through your own database connection, since
this server never holds a database credential itself.
`demo` is the handover for a demo or an eval: the database with a one-step loader,
the ER diagram, answer_key.json (every number by month), questions.jsonl and
the proof of each request.
dialect: for `sql`: postgres, mysql, sqlite, mssql, oracle, bigquery, snowflake, clickhouse
(MergeTree tables; above 500k rows, typed Parquet with load.sql). For `demo`:
postgres (psql) or clickhouse (Parquet loaded with clickhouse-client).
inline: also return the file itself as `base64` (only for files under a few MB). Use it
when you must write the file yourself and cannot fetch a URL.
Returns:
filename, content_type, bytes, download_url, expires_at (unix seconds), and `base64` when
`inline` and small enough.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | csv | |
| inline | No | ||
| dialect | No | postgres | |
| dataset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent=true and destructive=false, but the description adds substantive behavior beyond them: the download_url lives only ~2 hours, `inline` works only for files under a few MB, and the server never holds a database credential so SQL must be run through the caller's own connection. Minor gaps remain (what happens on expiry, retry behavior).
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?
Front-loaded with purpose and the critical return value, then organized into clean Args and Returns sections. Despite its length, every line resolves a real ambiguity (format semantics, dialect scope, inline size limit) rather than padding.
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?
There is no output schema, so the description appropriately enumerates the return fields (filename, content_type, bytes, download_url, expires_at, base64). Combined with parameter semantics and expiry/credential caveats, an agent has everything needed to call and use this 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?
With 0% schema description coverage the description carries the full load and does so thoroughly: it explains dataset_id's provenance, enumerates valid `format` values grouped by data vs code/docs and explains special cases (`sql`, `demo`), and restricts `dialect` to the relevant formats with concrete options. A bare schema with only defaults would leave an agent guessing.
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 names a specific verb and resource ('Export a generated dataset as a file') and immediately clarifies the output (a download_url). It is trivially distinguishable from siblings like generate_dataset or query_dataset, which produce/query rather than export.
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?
Gives explicit usage guidance at the point of decision: hand the person the link rather than pasting contents, and use `inline` only 'when you must write the file yourself and cannot fetch a URL.' It also anchors `dataset_id` to a prior generate_dataset call. It does not explicitly contrast with sibling tools or state when not to export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ready-made datasets Misata publishes: free sample databases (direct download, public domain)
and premium datasets with a full answer key (a free preview, then a one-off price). Check this
first when someone wants sample, demo, practice or teaching data for a common scenario (retail,
e-commerce, SaaS, manufacturing SPC, predictive maintenance, insurance claims, fraud/AML,
clinical, network security): handing over a dataset that already exists is instant. If none fits
their tables, generate one instead.
Args:
query: what the person needs, in their words. Only orders the list (closest first); every
dataset is still returned, so judge the fit yourself from the tables and summary.
Returns:
datasets: [{slug, kind (free|premium), title, summary, rows, tables, page_url, and
download_url (free) or free_preview_url + buy_url + price_usd (premium)}].
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: the query does not filter (every dataset is always returned, only ordered), free datasets are public-domain direct downloads, premium ones are preview-then-one-off-price, plus the exact returned fields including download/preview/buy URLs and price. No contradiction with readOnlyHint.
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?
Well front-loaded (purpose, then when-to-use, then Args/Returns) and uses clear sections. Slightly padded by the long parenthetical scenario list and the 'instant' aside, but nothing is misleading or wasted enough to harm selection.
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 supplies the return shape (datasets array with slug, kind, title, summary, rows, tables, page_url, and the free/premium download fields), plus the non-filtering semantics. An agent has everything needed to call it and interpret results.
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% (no description on `query`), so the description carries the full burden and does it well: it is free-text in the user's words, it only orders results closest-first, and it does not filter — telling the agent to judge fit itself. That is meaning no schema field conveys.
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?
Specific verb+resource: publishes/finds ready-made datasets, split into free sample DBs and premium datasets with answer keys. It explicitly distinguishes itself from the generate path ('If none fits their tables, generate one instead'), so an agent can separate it from generate_dataset without opening either schema.
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?
'Check this first when someone wants sample, demo, practice or teaching data for a common scenario' gives an explicit trigger, and the fallback ('generate one instead') names the alternative action with its condition. The named scenario list further pins down when this applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a verified relational dataset and wait for it: every foreign key checked, dates correctly
ordered, declared aggregates and rates exact, before anything is returned. Deterministic for a seed.
Use this when you give a `schema` or `ddl` (seconds). For a plain-English `request` the engine
designs the tables with a model, which can take several minutes: call start_generation instead and
poll get_status, so the call does not sit open and time out.
Args:
request: Plain-English description (needs an LLM key unless `schema`/`ddl` is also given). With no key,
design it yourself instead: blueprint_guide, then `blueprint` below.
schema: A Misata schema dict for exact structural control. No key needed for structure. Its `numbers`
(revenue by month, churn, MRR, shares, averages) are held exactly: see the server instructions.
A column's `moves_with` ({"column": "customers.income", "strength": 0.6}) pairs it with another
number of its row or its parent's, by rank, each keeping its own values.
ddl: CREATE TABLE statements. No key needed for structure. Beside it, schema={"numbers": [...],
"window": {...}} holds the story's numbers on these tables.
seed: Reproducibility seed — the same request/schema and seed always produce the same rows.
research: Ground realistic numbers (prices, growth rates) in real published facts via a web
search. Off by default (an anonymous caller's request should not trigger external
calls unless asked for); needs a key regardless of `schema`/`ddl`.
blueprint: The engine's full design language (blueprint_guide has the reference): readings around
a parent's nominal, drift, autocorrelation, cause-and-effect, event windows, exact
aggregates. Use it whenever the data must behave like the real process. No key needed;
run validate_blueprint on it first.
story: A built-in shape held to exact numbers, the way Studio's plan screen states them. No key
needed; built by code in seconds. {"pack": "saas_sales", "window": {"start": "2024-09",
"end": "2026-08"}, "curves": [{"lever": "mrr_curve", "points": {"2024-09": 50000,
"2026-08": 200000}}], "rates": [{"lever": "monthly_logo_churn", "value": 0.02,
"events": [{"name": "Q3 churn spike", "start": "2025-07-01", "end": "2025-09-30",
"multiplier": 2.5}]}]}. Shapes: saas_sales, ecommerce, fintech, healthcare. Every
stated number is held exactly and read back in SQL; get_certificate has the answer key.
`numbers` sets plain sizes and shares ({"customers": 3000, "products": 400, "return_rate":
0.06}). With no model key the shape's content is generic (ecommerce sells electronics,
books, toys): write it yourself as `content`, e.g. {"catalog": [{"name": "Linen Duvet
Cover", "category": "Bedding", "brand": "Fernhill", "price": 89.0}, ...]} (30-100 items
in this business's own categories, at its real prices).
Returns:
dataset_id: pass this to get_certificate / query_dataset / export_dataset.
passed: whether every check held. A dataset that did not pass is still returned, with
`certificate.findings` saying what failed — inspect before trusting it.
verification: a short, plain-language account of what was checked and what held — show it to the
person as the proof, in place of asking them to take the data on trust.
tables: {name: {columns, preview_rows (first 20), total_rows}} — the preview only; every
row is in the stored dataset, reachable by query_dataset/export_dataset.
certificate: the short form (claims, requirements, findings). get_certificate returns the rest
(patterns, realism scorecard, every proof chart).
| Name | Required | Description | Default |
|---|---|---|---|
| ddl | No | ||
| seed | No | ||
| story | No | ||
| schema | No | ||
| request | No | ||
| research | No | ||
| blueprint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses blocking behavior, timeout risk, deterministic seeding, external research being off by default, LLM key requirements, and that failed datasets are still returned with findings. This is rich operational context not captured by 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 front-loaded, with the core behavior and async alternative stated first. The Args and Returns sections are dense and example-heavy; they earn most of their space for a complex tool, though some detail could be trimmed.
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 and seven params, the description supplies a Returns section that explains dataset_id, passed, verification, tables, and certificate. It also explains failure behavior and where every row is reachable, making it complete for an agent to call 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 description coverage is 0%, so the description must carry parameter meaning. It explains every parameter: request, schema, ddl, seed, research, blueprint, and story, including nested structures like moves_with and story rates.
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 a specific verb and resource: 'Make a verified relational dataset and wait for it.' It also distinguishes this synchronous path from the async sibling by saying to use start_generation for plain-English requests that can take minutes.
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 when-to-use guidance: use this tool when providing schema or ddl (seconds), use start_generation plus get_status for plain-English requests. It also names validate_blueprint before blueprint use and describes key requirements per mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full certificate for a dataset made by generate_dataset: every claim (stated vs actual),
every requirement's status and evidence, realism findings, planted defects/anomalies if any, and
the pattern charts. This is the whole answer key, not the trimmed form generate_dataset returns.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description earns credit by disclosing the payload's depth and contents (full vs trimmed), which is meaningful behavioral context the annotations cannot convey. It does not mention rate limits, auth requirements, or pagination, keeping it below a 5.
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?
Two sentences with no filler: the first establishes what the tool returns and enumerates contents, the second front-loads the key differentiation from the trimmed generate_dataset output. Every clause carries information.
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?
There is no output schema, so the description must describe the return surface — and it does so thoroughly, listing every category of certificate content. With annotations covering the safety profile and a single obvious parameter, nothing an agent needs to call this correctly is missing.
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 single parameter dataset_id is undocumented in the schema. The description implicitly scopes it by tying the tool to 'a dataset made by generate_dataset,' which gives the identifier useful provenance, but it adds no format, sourcing, or lookup detail beyond that. Adequate but with a clear gap.
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 ('the full certificate for a dataset') and enumerates exactly what it contains: claims stated vs actual, requirement statuses and evidence, realism findings, planted defects, and pattern charts. It also distinguishes itself from the sibling generate_dataset by noting this is the untrimmed form, so an agent can select it without opening either schema.
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 clearly situates usage: this is the 'whole answer key' versus the trimmed certificate generate_dataset returns, which tells the agent when to prefer this tool. It stops short of an explicit when-not-to-use statement or naming a distinct alternative tool by name, so it is clear context rather than a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a start_generation job is. While running: the stage it is in and how long it has run. When
done: the same answer generate_dataset returns (dataset_id, verification, tables, certificate).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint and destructiveHint=false, lowering the bar, yet the description adds useful state-dependent return detail: running returns stage and elapsed time, done returns dataset_id, verification, tables and certificate. It omits polling frequency or rate-limit behavior, which would complete the picture.
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?
Three telegraphic sentences, front-loaded with the core purpose and then the state-specific returns. Every sentence carries information; nothing is padded.
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 and no annotation-level return info, the description does the heavy lifting by describing what comes back in each state. It is nearly complete, missing only polling/rate guidance and explicit job_id provenance.
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% and the single job_id parameter is undescribed in the schema, so the description must compensate. It does so only indirectly, implying job_id identifies a job produced by start_generation, but gives no format or sourcing detail.
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 resource (a start_generation job) and what it reports ('Where a start_generation job is'), with the return shape spelled out per state. It also anchors itself to the start_generation sibling, so an agent can distinguish it from generate_dataset without opening either schema.
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?
Implicitly establishes the polling pattern after start_generation and clarifies the two states (running vs done), noting that the done-case result matches generate_dataset. It never states an explicit 'use this when' or a 'do not call if' exclusion, so guidance is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See the tables, sizes and relationships the engine would build, before any rows exist. Free (no
rows are made), so it is worth calling before generate_dataset on anything non-trivial: review
what it understood and assumed, then adjust your request or schema before spending a real call.
Args:
request: Plain-English description (needs an LLM key, unless `schema`/`ddl` is also given —
then it is still used to ground realism, e.g. locale and what columns mean).
schema: A Misata schema dict (see the server instructions for the format). No key needed for
structure.
ddl: CREATE TABLE statements. No key needed for structure.
Returns:
route: "chat" (not a dataset request — see `reply`), "design" (the model designed the
tables) or "pack" (matched a built-in shape).
tables: name, estimated rows, columns, foreign keys for each table the engine would build.
understanding: what the engine read the request as (business, archetype, assumptions).
requirements: every specific thing the request asked for, so you can see what was understood.
| Name | Required | Description | Default |
|---|---|---|---|
| ddl | No | ||
| schema | No | ||
| request | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description still adds real behavioral context: the call is free and creates no rows, and an LLM key is required for `request` unless `schema`/`ddl` are supplied. The three possible `route` outcomes further disclose how the call actually resolves.
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?
Front-loaded with the purpose and cost argument in the first sentence, then structured Args/Returns sections. Slightly verbose in the Args block, but every line conveys non-obvious information.
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?
No output schema exists, so the Returns block is genuinely necessary and enumerates route, tables, understanding, and requirements. Combined with annotations and param docs, an agent has everything needed to call and interpret this 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?
With 0% schema description coverage, the description carries the burden and does so well: it explains each of the three params (plain-English request needing a key, Misata schema dict, CREATE TABLE ddl) and their key requirements. Minor deduction because the schema dict format is deferred to 'server instructions' rather than summarized.
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 concrete outcome — 'See the tables, sizes and relationships the engine would build, before any rows exist' — which is a dry-run preview distinct from every sibling. An agent can instantly distinguish it from generate_dataset without opening the schema.
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 it 'before generate_dataset on anything non-trivial' and names the alternative it precedes. It also tells the agent the follow-up action: review assumptions, then adjust the request or schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only SQL over a dataset's own tables (one SELECT/WITH statement; every table name is a view
over that dataset's own files — nothing else on the server is reachable this way).
Args:
dataset_id: from a prior generate_dataset call.
sql: a single SELECT (or WITH ... SELECT) statement. No semicolons, file paths, or
statements that write or read outside the dataset (checked before running).
limit: rows returned (capped at 5000).
Returns:
columns, rows, truncated (whether more rows existed than `limit`).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| limit | No | ||
| dataset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered; the description nonetheless adds substantial non-obvious behavior: single-statement-only, no semicolons or file paths, validation '(checked before running),' a hard cap of 5000 rows, and the 'truncated' signal for overflow. These are enforcement details an agent cannot infer from annotations or schema.
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?
Front-loaded with the core behavior, then cleanly partitioned into Args and Returns sections. Every sentence earns its place; the parenthetical about views and reachability eliminates a real ambiguity rather than padding.
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 compensates by enumerating the return shape (columns, rows, truncated) and explaining what truncated means. All three parameters are documented, the validation and cap behavior are stated, and annotations cover safety — nothing needed to invoke it correctly is missing.
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 load, and it does: it documents the provenance of dataset_id, the exact SQL grammar accepted, the prohibition on writes/outside reads, and that limit is capped at 5000. It omits the schema's default of 1000 for limit, a small gap against a 0%-coverage 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 opens with a specific verb+resource+scope: 'Read-only SQL over a dataset's own tables,' and clarifies the isolation boundary ('every table name is a view over that dataset's own files'). No sibling tool (generate_dataset, export_dataset, plan_dataset, etc.) competes for this slot, so an agent can immediately tell what it does and what it does not reach.
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 supplies a prerequisite that routes the agent correctly: dataset_id 'from a prior generate_dataset call,' which tells the agent this only works on an already-materialized dataset. It does not explicitly state when NOT to use it (e.g. use export_dataset instead when you want the full result downloaded), so it stops short of naming alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a generation in the background and return a job_id at once. Use it for any plain-English
`request` (a model designs the tables, which takes minutes) — then call get_status(job_id) every
20-30 seconds until it says done. Arguments are the same as generate_dataset.
Returns:
job_id, status "running". get_status gives the stage and, when finished, the dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| ddl | No | ||
| seed | No | ||
| story | No | ||
| schema | No | ||
| request | No | ||
| research | No | ||
| blueprint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety/idempotency profile; the description adds the behavior that actually matters here: the work runs asynchronously, the model design step 'takes minutes', the immediate return is job_id/status 'running', and the recommended polling cadence. That is substantial context an agent cannot derive from 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?
Front-loaded with the action and the async contract, then the polling instruction, tightly written with no filler. The trailing 'Returns:' block partially restates the earlier job_id/status point and get_status's role, so it is efficient rather than perfectly lean.
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 long-running async tool with no output schema, the description supplies the essential operational knowledge: immediate job_id return, expected duration, what get_status delivers, and the polling interval. It is only short on the parameter surface, which it explicitly delegates to generate_dataset.
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 7 parameters at 0% schema description coverage, the description compensates for only one of them (it identifies `request` as plain-English and glosses the rest as 'the same as generate_dataset'). The remaining six parameters must be resolved by opening a different tool, leaving a large semantic gap even though the deferral is a reasonable strategy.
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 ('Start a generation in the background') and immediately differentiates itself from the synchronous sibling by noting it 'return[s] a job_id at once' while 'Arguments are the same as generate_dataset'. An agent can tell the two apart without opening either schema.
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?
Gives a clear trigger ('Use it for any plain-English `request`') and a follow-up loop ('then call get_status(job_id) every 20-30 seconds until it says done'), effectively routing to the sibling get_status. It never states an explicit when-not (e.g. when you already have a ready DDL/blueprint, prefer the synchronous path), so it falls short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a blueprint before generating it: every error said as what to change, the design traps it
falls into (a column that will round away, a copy of a value not made yet, a window that counts
nothing), its size against your row cap, and a small preview run (a few thousand rows) with the
verifier's findings and sample rows, so you can see the data behave before the real call. Free.
Returns:
valid, errors (fix these), warnings (read these), planned (sizes the stated numbers set; "keep_size"
on a table keeps its row_count), estimated_rows, row_cap,
preview: {passed, findings, tables: {name: first rows}} when `preview`.
| Name | Required | Description | Default |
|---|---|---|---|
| preview | No | ||
| blueprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds real context beyond them: the preview is only a few thousand rows, the call is free, errors are framed as actionable ('said as what to change'), and warnings are separately characterized as 'read these'.
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?
Front-loads the one-line purpose, then the checks, then a Returns block. The opening sentence is long and comma-dense, but every clause carries distinct information and nothing is padding.
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?
No output schema exists, and the description compensates with an explicit Returns list (valid, errors, warnings, planned, estimated_rows, row_cap, preview findings/tables), which is genuinely helpful. Annotations cover the safety profile. The only real gap is the undefined blueprint object structure, which sibling blueprint_guide likely addresses.
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% for two parameters, so the description carries the burden. It partially compensates — it references the `preview` parameter ('when `preview`') and exposes blueprint field semantics ('keep_size' on a table keeps its row_count) plus the shape of traps (columns, window functions) — but it never defines what a blueprint object is or its structure, leaving the main required parameter under-specified.
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 ('Check a blueprint before generating it') and enumerates exactly what it checks — errors, design traps, size against row cap, preview run. Its placement relative to generation ('before the real call') implicitly distinguishes it from generate_dataset, though it never names that sibling outright.
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?
Gives a clear condition for use: run it before generating, to see the data behave before the real call. It also notes the operation is 'Free', which is a meaningful cost signal for deciding whether to run it. It stops short of naming alternatives or explicit when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which account this connection is, and what it may do: signed in with a Studio MCP key or anonymous, the row cap, and whether a model key is available for plain-English requests.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context: it reports authentication mode and two capability details (row cap and model-key availability), telling the agent what the call surfaces beyond safety.
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?
Single sentence, front-loaded with the core identity answer and then the capabilities. No filler or repetition.
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 no-argument read-only introspection tool with no output schema, the description supplies enough of the return content (auth mode, row cap, model key availability) to know what the call yields. Annotations cover safety.
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?
No input parameters exist, so the schema is trivially complete. The description does not need to explain parameter semantics; baseline 4 applies for a zero-parameter tool.
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 introspection purpose: account identity, auth mode (Studio MCP key or anonymous), row cap, and model key availability. An agent can immediately tell this is a connection-context probe, distinct from sibling dataset and generation 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?
Usage is implied rather than explicit: an agent can infer it should call whoami to inspect current identity and capabilities, but the description offers no when/when-not guidance or alternatives among siblings. No explicit routing is provided.
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.
check_answersblueprint_guide1 field changedInput schema / properties / topicAdded value: +{
+ "default": "",
+ "title": "Topic",
+ "type": "string"
+}generate_dataset1 field changedInput schema / properties / storyAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Story"
+}start_generation1 field changedInput schema / properties / storyAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Story"
+}blueprint_guidecancel_generationexport_datasetfind_ready_datasetgenerate_datasetget_certificateget_statusplan_datasetquery_datasetstart_generationvalidate_blueprintwhoamiGenerate realistic relational test data — 156 field types, 22 locales, JSON/CSV/SQL, free previews.
Validate and clean CSV before import. Find duplicates, missing values and invalid dates with row-level reports. Apply only the cleanup you request; files are not retained. Run view_csv_demo free without a key. Custom CSV: EUR 9 for 100 operations, valid 90 days, no subscription. Setup: https://check.orvel.dev/docs/
No-code databases, forms, portals and AI sites. Manage records and automation via natural language.
No-code databases, forms, portals and AI sites. Manage records and automation via natural language.
Add one secure layer between your agents and this server.
