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., "@diligence-kernel Ingest the dataroom at /acme/DR and run table 05."
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 matter-scoped M&A diligence vault and review-table execution engine, over MCP.
It ingests a data room, classifies and tags every file, assembles review units, and then runs the review-table prompt corpus against them — filling cells with evidence attached, so the analysis persists for higher-level M&A work and drafting.
Documentation: project wiki — architecture, the corpus, ingestion, running a table, standards, findings reference, operations.
files → extract → classify (Table 05) → assemble review units
→ chunk + embed → vault
→ run a table: retrieve in-scope evidence, fill each cell in dependency order
→ persist cells + evidence + provenance
→ derived artifacts: consent schedule, coverage register, issues listThe prompt corpus in review-table-prompts/ is the schema: 24 table inventories,
591 columns, 591 prompts. The markdown is the source of truth. The database is derived and
rebuildable from it.
Related MCP server: Conflict-Check MCP
It does not draft prompts — the legal-review-table-builder skill does that. It does not
make legal determinations. It does no arithmetic: 00a section 7 is enforced, not
requested, so every figure is reported as stated and reconciliation happens outside.
prompt-graph remains the authoring and evaluation companion. This engine holds its own
parsed copy of the corpus because it needs prompt text, dependency order, and retrieved
evidence in-process; MCP servers cannot call each other.
From 00a-build-plan-and-standards.md, checked on every cell before it persists:
the five-state fallback vocabulary, and the banned synonyms (N/A, None, Silent, …)
Not stated restricted to Date, Number, Currency and Duration columns
Classify answers restricted to configured options
ISO dates with partial precision preserved
no markdown, no citations, and no computed figures in a cell
Verbatim cells must reproduce text that actually appears in the review unit
Matter — matter_open, matter_status
Vault — vault_ingest, vault_search, classification_record
Rows — units_propose, units_assemble
Execution — run_estimate, run_table, run_status
Review — table_read, cell_evidence, cell_review
Corpus — table_describe, column_prompt, columns_find
Artifacts — artifact_list, artifact_build
matter_open("Project Cedar", as_of_date="2026-09-01") # loads 24 tables, 591 columns
vault_ingest("/path/to/dataroom") # extract, chunk, offsets, embed
units_assemble("05") ; run_table("05") # intake classifies and routes
units_assemble("01") ; run_table("01") # a workstream table
table_read("01", only_flagged=True) # what breached the standards
cell_evidence(unit_id, "Assignment Language") # the sentences behind a cell
cell_review(unit_id, "...", review_status="Verified", materiality="Critical")
artifact_build("consent_schedule") # a filter, not a fresh questionBuild order is 00a section 12: start at 05, then 06, then 01, and stop when the matter is
covered. table_describe reports the pairs that must be built together.
PDF, DOCX, XLSX, CSV, HTML and email (.eml, .msg) are read by default — a data room is
not a folder of text files. Anything produced but unreadable (.xls, .doc, .pptx,
archives) is reported, not skipped in silence: an unread file must not look like an
absent one. Three things happen on the way in that matter more than they sound:
Running headers and footers are stripped. An extractor emits them in reading order, so
a clause spanning a page break arrives with Confidential Page 1 of 3 inside the sentence.
Lines repeating at the top or bottom of most pages are removed, with page numbers masked so
Page 1 of 3 and Page 2 of 3 count as the same line.
Offsets survive. The full text is rebuilt from the cleaned pages, so every chunk's character span and page range is exact, and evidence can point at it.
Scans are read by OCR. A PDF page with no text layer is transcribed locally with
tesseract, so nothing leaves the machine. Set DILIGENCE_KERNEL_OCR to tesseract
(default), vision, or off. Without OCR available, the file still ingests and reports
itself rather than disappearing.
00a classifies cap tables, stock ledgers, employee censuses and loss runs as Records —
they report facts as at a date, and the as-of date is what makes one usable. Flattening a
sheet into prose loses two things a reader cannot recover:
Column headers. A chunk holding rows 27 to 52 of a census, with the header left behind in an earlier chunk, is a grid of unlabelled numbers — nothing can tell salary from bonus.
Sheet boundaries. A cap table followed by a census reads as one table that changes shape halfway through.
So a table is chunked by rows, and every chunk restates its sheet name and header:
# Sheet: Employee Census (continued)
Employee ID Name Title Location Hire Date Base Salary ...
E1032 Employee 32 Engineer II Austin, TX 2022-06-15 125200 ...The repetition is written into the stored text too, the way a printed schedule repeats its headings on each page, which keeps every chunk an exact slice and offsets true.
Tables 17, 23 and 25 are built around correspondence, and their review unit is a matter of several communications — so one message is one document, and unit assembly groups them.
Headers are normalized into the text, because From, Cc, Date and Subject are what Table 05 routes on.
The quoted chain is separated and labelled. A reply carrying twelve earlier messages otherwise duplicates their text into every later file, which distorts retrieval and makes "the most recently dated document" meaningless. The history is kept — it is evidence — but marked as repeated.
Attachments are extracted and ingested in their own right, linked back to the message
that carried them, because in a data room the attachment is usually the agreement.
Signature images, calendar items and smime.p7s are recognised as mail furniture.
Privilege markings are reported. 00a: report the marking and stop, never assess
whether privilege applies — "a privileged document reaching the wrong reviewer is a
handling problem." Detection runs on every document, not only email.
The Verbatim check tolerates what extraction does to text — ligatures, soft hyphens, hyphenated line breaks, wrapping, smart quotes, dashes, non-breaking spaces — while still rejecting paraphrase.
A document read by OCR records that fact, its engine and its confidence, and the whole system stays honest about it:
the model is told which documents are transcriptions, and not to correct a garbled word
cell_evidence reports the source of every quotation it shows a reviewer
a Verbatim cell drawn from a transcribed unit is flagged VERBATIM_FROM_OCR, because
matching a quotation against OCR output compares one reading with another and cannot show
the words are the document's
tesseract is the default rather than vision for a specific reason: tesseract garbles,
which is visible, while a vision model transcribes fluently, so its misreadings look like
ordinary text. On a control that a partner will rely on, a legible failure beats a
plausible one.
brew install tesseract poppler # macOS
uv pip install -e ".[ocr]"review-table-prompts/ is the source of truth. prompt-graph holds the versioned history,
the cross-table dependency graph and the evaluation log, and is rebuilt from the markdown:
python scripts/sync_prompt_graph.py --dry-run # parse and report, write nothing
python scripts/sync_prompt_graph.py # replay the corpus into prompt-graphRe-syncing unchanged markdown reports every column unchanged and writes nothing. Edit prompts
in the markdown; use prompt-graph to see what a change would break (impact_of_change), what
the suite looks like as a whole (suite_check), and to hold the evaluation log.
Corpus linting lives there, not here. The kernel validates answers at execution time; it does not lint prompts.
Held in its own private repository — it carries the practice's methodology, which is a different class of material from the engine that runs it. The kernel reads it by path and runs perfectly well without it; the crosswalk is analysis, not runtime.
export DILIGENCE_KERNEL_PLAYBOOK=/absolute/path/to/diligence-playbookSee the crosswalk.
OpenAI by default; Anthropic behind the same interface. Both make the identical call — a cached prefix, a short varying instruction, and a schema the answer must satisfy — so switching is one environment variable.
export DILIGENCE_KERNEL_PROVIDER=openai # or anthropic
export DILIGENCE_KERNEL_MODEL=gpt-5 # default: gpt-5
export DILIGENCE_KERNEL_EFFORT=medium # low | medium | high | xhigh | max
export DILIGENCE_KERNEL_CONCURRENCY=6 # model calls in flight, within a stageColumns of the same stage are filled concurrently and the run waits at each stage boundary, so a downstream prompt always sees its upstream answers. 338 of the 591 columns are stage 1. The first call of each unit runs alone to populate the prompt cache; firing a whole stage at once would make every request miss it.
The default is gpt-5.4. Cost is modelled from the published rates: cached input at a tenth
of fresh, cache writes at each model's own rate (free on gpt-5.4 and gpt-5.5, a premium on
the gpt-5.6 family), and the long-context tier at roughly double above ~128k tokens.
Output dominates this workload — a cell spends ~1,145 output tokens against ~693 fresh input
— so the output rate is what you are really choosing between. The spread is wide:
gpt-5.6-luna runs the same work for about a twelfth of gpt-5.4.
Anything absent from the built-in price table reports its cost as unknown rather than guessing; price it yourself with:
export DILIGENCE_KERNEL_PRICE_IN=1.25 # USD per million input tokens
export DILIGENCE_KERNEL_PRICE_OUT=10.00 # USD per million output tokensOn OpenAI, run_estimate needs no credentials and no network — tiktoken counts locally.
The server is launched by its MCP client, not from a shell, so it inherits nothing from your
terminal. Put the key in a .env at the project root rather than in the MCP config:
cp .env.example .env # then edit it.env is gitignored, and an environment variable already set always wins over it.
uv venv .venv
uv pip install --python .venv/bin/python -e ".[dev,all]" # OpenAI
uv pip install --python .venv/bin/python -e ".[dev,anthropic]" # adds AnthropicVerify the live model path on the smallest possible run. Safe by default — with no flags it checks credentials and estimates cost using the free token-counting endpoint, and spends nothing.
.venv/bin/python scripts/smoke_test.py # free: credentials + cost estimate
.venv/bin/python scripts/smoke_test.py --run # spends: fills 4 cells on one rowIt works on a throwaway database in a temp directory, never a real matter, and refuses to
fill more than 12 cells. --run prints each cell's value, the sentences it was drawn from
with their offsets, and any standards violation.
For a real run, run_estimate reports what run_table would cost before you start it,
with and without the cached unit prefix.
One matter is one database file.
claude mcp add diligence-kernel \
-e DILIGENCE_KERNEL_DB=/absolute/path/to/matters/acme.db \
-e DILIGENCE_KERNEL_CORPUS=/absolute/path/to/review-table-prompts \
-e OPENAI_API_KEY=... \
-- /absolute/path/to/diligence-kernel/.venv/bin/diligence-kernelThe database holds client-confidential material: document text, extracted cells, entity
names. Treat the file like a matter file, and keep the -wal and -shm sidecars with it.
Build a derived artifact by filtering cells that already exist.
00a: never re-derive a schedule by asking a fresh question, so that the schedule and its sources cannot disagree. Each artifact reports how many of its rows are still unreviewed or carry a standards violation.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact | Yes | consent_schedule | coverage_register | closing_conditions | transaction_payments | chain_gaps | issues_list | |
| min_review_status | No | Only carry cells at this review status, e.g. 'Verified'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses some behavior: it does not re-derive schedules from fresh questions (implying it reuses existing data) and it reports counts of unreviewed rows or violations. However, it lacks details on side effects, reversibility, or the creation/update nature. The provided info is a start but not comprehensive.
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 reasonably short but suffers from a formatting anomaly '00a:' that disrupts flow. The sentences are not well connected, and the rule about schedules appears out of place. It is concise but not structurally clean.
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 that there is an output schema (though not shown) and the input schema is fully covered, the description provides the core purpose and some output behavior. However, it lacks context on how to choose artifact types, prerequisites, and typical use cases. It is minimally sufficient but not complete.
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 100%, so both parameters are well documented. The description does not add additional semantic meaning beyond the schema. It mentions filtering cells, which aligns with min_review_status, but does not elaborate further. Baseline of 3 is appropriate.
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 clearly states the core function: 'Build a derived artifact by filtering cells that already exist.' This specifies the verb and resource. However, it does not explicitly differentiate from sibling tools, though none of the siblings appear to perform the same task. The purpose is clear enough.
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 a somewhat cryptic rule: '00a: never re-derive a schedule by asking a fresh question, so that the schedule and its sources cannot disagree.' This hints at a constraint but does not clearly state when to use this tool versus alternatives. There is no mention of when not to use it or any explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the derived artifacts and what each is built from.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation and reveals that it returns provenance info ('what each is built from'). It does not disclose output format or pagination, but the output schema exists to cover return values.
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?
One sentence, front-loaded with the verb and resource, and it includes the key provenance detail without waste. Every word 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?
For a zero-parameter list tool with an output schema, the description is nearly complete. It could mention whether the list is ordered or filtered, but the core purpose and content are fully covered.
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 parameters, so there is no parameter semantics burden. The description adds meaning by explaining what the list contains (derived artifacts and their sources), which is useful context beyond the empty 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 uses a specific verb ('List') and resource ('derived artifacts'), and adds the useful detail that it shows what each artifact is built from. It is clear enough to distinguish from siblings like artifact_build, though it doesn't explicitly name any sibling.
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 a read-only listing use case, and the context of sibling tools (artifact_build) suggests it is for inspecting artifacts rather than creating them. However, it does not explicitly state when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a cell's value and the sentences it was drawn from, with document and offsets.
This is how a reviewer checks a cell without opening the whole document. A cell whose evidence list is empty was filled from no quoted text.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | Exact column name. | |
| unit_id | Yes | The row, from table_read or units_assemble. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It does add a useful behavioral detail: 'A cell whose evidence list is empty was filled from no quoted text,' which helps interpret the output. However, it does not explicitly state that the tool is read-only or describe any side effects, permissions, or failure modes. Given the read-like nature implied by 'Show,' a 3 is appropriate—some transparency is added, but not comprehensive.
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 two sentences, front-loaded with the core function and then the use case and an edge case. There is zero redundancy or filler. Every sentence earns its place, making it an exemplary model of conciseness.
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 the description does not need to explain return values. The description covers the tool's purpose, a usage context, and a behavioral edge case (empty evidence list). The only notable omission is explicit guidance on when to prefer this tool over a sibling like cell_review, but the given context is otherwise sufficient for a simple two-parameter tool.
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 input schema provides 100% coverage for both parameters: 'column' is described as 'Exact column name' and 'unit_id' as 'The row, from table_read or units_assemble.' The description does not add any extra meaning to these parameters beyond what the schema already states. With full schema coverage, the baseline is 3, and the description does not elevate it.
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 pair: 'Show a cell's value and the sentences it was drawn from, with document and offsets.' This clearly states what the tool does. It also distinguishes itself from siblings by framing the use case: 'This is how a reviewer checks a cell without opening the whole document,' which separates it from broader tools like matter_open or table_read.
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 a clear usage context: it is the way a reviewer checks a cell without opening the document. This implies when to use it, but it does not explicitly name alternative tools or state when not to use it. The sibling list includes cell_review, which might be a related alternative, but the description does not mention it or provide exclusion criteria, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a human's judgment on a cell: verification, correction, materiality, consequence.
Materiality and deal consequence are human columns by design; the engine never fills them. A verified or locked cell is not overwritten by a later run.
| Name | Required | Description | Default |
|---|---|---|---|
| lock | No | Lock the cell against re-runs. | |
| value | No | A corrected value. The old one is kept in history. | |
| column | Yes | ||
| unit_id | Yes | ||
| materiality | No | Critical | Material | Monitor | Immaterial. | |
| reviewed_by | No | Reviewer's initials. | |
| review_status | No | Unreviewed | Verified | Corrected | Disputed. | |
| deal_consequence | No | What it means for the deal. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that materiality and deal consequence are human-only columns, and that verified or locked cells are not overwritten by later runs. It also implies this is for human input. This provides meaningful behavioral context beyond what the schema shows. However, it doesn't mention whether the operation is idempotent, any side effects, or error conditions. Still, the disclosure is useful, so a 4 is appropriate.
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 concise—two sentences with no redundancy. It front-loads the purpose and adds the key behavioral notes. Every sentence earns its place. This is excellent conciseness.
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 complexity (8 parameters, 2 required) and that an output schema exists, the description covers core behavioral aspects (human-only fields, overwrite protection) but omits usage guidance such as when to use this tool, prerequisites, or typical scenarios. It also doesn't mention how the tool relates to run_table or cell_evidence. For a complete picture, more context would help, but the essentials are 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?
The schema description coverage is 75%, meaning most parameters already have descriptions. The tool description itself doesn't add additional parameter-specific semantics beyond what's in the schema. It references some concepts (verification, correction) but those are already covered. Since coverage is high, a baseline of 3 is appropriate; the description doesn't go beyond that.
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 action ('Record a human's judgment') on a specific resource ('a cell'), and enumerates the types of judgment (verification, correction, materiality, consequence). This makes the tool's purpose clear and distinct from sibling tools like cell_evidence, which likely deals with evidence rather than judgment. However, it doesn't explicitly differentiate from any specific sibling, so a 4 rather than a 5.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical workflow, or conditions that would make this tool the right choice. The only context is that it records human judgment, but no exclusions or alternatives are given. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store Table 05 classification for files, which is what routes them to every other table.
Use this when you have classified files yourself. Running Table 05 through run_table writes the same records. A file with no workstream is invisible to every workstream table.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | One record per file, each with 'filename' plus any of: workstream, secondary_workstream, document_type, document_role, subject_entity, counterparty, document_date, operative_date, amends_or_issued_under, compilation_flag, completeness, language, routing_disposition. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the routing side-effect, the equivalence to run_table, and the invisibility consequence for files without a workstream. It doesn't mention idempotency, overwrite behavior, or whether records are appended or replaced, but the core behavioral traits are well covered.
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 sentences, each earning its place: what it does, when to use it, and a critical consequence. The most important routing fact is front-loaded.
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 write tool with a rich schema and output schema present, the description covers the essential context: purpose, usage trigger, alternative, and a key failure mode. It could mention whether records are upserted or appended, but the description is largely complete for an agent to decide 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?
Schema coverage is 100%, so the schema already documents the 'records' parameter and its fields. The description adds context about what the records mean (routing) but doesn't add syntax, format, or per-field semantics beyond the schema. Baseline 3 is appropriate.
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 ('Store') and resource ('Table 05 classification for files'), and immediately explains the routing consequence. It distinguishes itself from run_table by noting that running Table 05 writes the same records, so an agent can tell this tool is the direct/manual write path.
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 'Use this when you have classified files yourself' and contrasts with run_table, which writes the same records. This gives clear when-to-use guidance and names the alternative. The warning about files with no workstream being invisible adds a practical condition for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one column's full prompt text, with its upstream and downstream columns.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. | |
| column | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool returns prompt text and neighboring columns, which is helpful, but it doesn't mention whether the operation is read-only (safe) or has any side effects. It also doesn't specify if there are permissions or prerequisites. The description is not contradictory, but it lacks depth in behavioral disclosure, especially for mutation/read aspects.
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 a single, concise sentence that front-loads the core purpose and output. There is no wasted text, and it manages to mention both the prompt text and the upstream/downstream columns, which is important for the tool's specific use. It is appropriately sized for the tool's simplicity.
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 tool has only 2 parameters inevitably both required, has an output schema, and no nested objects flags. The description covers the main purpose and output. It doesn't explicitly state the return format (though output schema may cover that), and it leaves out any mention of edge cases (e.g., invalid column names). Given the relative simplicity and the presence of an output schema, this is reasonably complete, but could benefit from noting the 'full prompt text' includes formatting or length.
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 50%: 'table' is described with an example ('01' or '13'), but 'column' has no description and no enums. The description adds meaning by indicating these parameters identify a specific column for retrieval. However, it doesn't clarify the format of 'column' (is it a string of column name? A number?), so the agent must infer. The tool description partially compensates but could add more syntax guidance.
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 clearly states the tool returns one column's full prompt text with its upstream and downstream columns. This is a specific verb ('Return') and resource ('one column's full prompt text'), and it distinguishes from sibling tools like table_read or columns_find, which likely have broader or different scopes. The description is not a tautology; it adds meaningful detail about output contents.
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 the tool is used to inspect a single column's prompt and its neighbors, but it does not explicitly state when to prefer this over siblings like columns_find or table_describe. There is no explicit 'when to use/when not to use' guidance. However, the description is clear enough that an agent could infer it's for column-specific prompt retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find columns across all 24 tables by name, purpose, or prompt text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words to match in a column name, purpose, or prompt. | |
| native_type | No | Classify | Date | Verbatim | Free Response | Duration. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It states what is searched and hints at the searchable attributes, but it does not disclose return format (though an output schema exists), pagination, or any side effects (which are unlikely for a search). Given the output schema exists, the return behavior might be inferred, but the description alone is minimal. It doesn't contradict any annotations, so a 3 is appropriate for a non-destructive search tool.
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 a single, concise sentence that immediately states the scope and search criteria. It is front-loaded with the key information (what it does and where), and there is no wasted wording. It effectively serves as a clear summary for an agent.
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 search tool with an output schema, the description covers the core functionality. However, it could mention the purpose of the 'native_type' filter or any nuances like case sensitivity or wildcard support, which are not in the schema descriptions. The presence of an output schema reduces the need to explain return values, but the description could still provide more context on search behavior. Overall, it's adequate but with minor gaps.
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 schema covers 67% of parameters: 'query' and 'native_type' have descriptions in the schema (query: 'Words to match...', native_type: 'Classify | Date | Verbatim...'), leaving 'limit' with only a default and no description. The tool description adds a bit of context by mentioning 'name, purpose, or prompt text' which aligns with the 'query' parameter, but it doesn't add details about 'limit' or 'native_type' beyond the schema. With 67% coverage, the description partially compensates but not fully, so a 3 is fair.
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 ('find') and resource ('columns across all 24 tables'), and specifies the search criteria ('by name, purpose, or prompt text'). This clearly distinguishes it from sibling tools like table_describe or table_read, which focus on reading table content or structure. The scope ('all 24 tables') adds precision, so an agent can quickly understand what this 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 searching columns across the entire dataset, which is clear enough. However, it does not explicitly contrast with siblings like table_describe (which might describe a single table) or vault_search (which might search broader content). There are no explicit 'when to use' or 'when not to use' instructions, but the context is sufficient for a simple search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the matter in this database and load the review-table prompt corpus.
One matter is one database file. Loading the corpus is idempotent: unchanged inventories are skipped, a changed one is re-parsed. Call this before anything else.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The matter's name, as the deal team calls it. | |
| side | No | 'buy' or 'sell'. | |
| objective | No | What the deal team is trying to learn. | |
| as_of_date | No | The diligence as-of date, YYYY-MM-DD. Prompts compare dates to it. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full transparency burden. It discloses idempotency ('unchanged inventories are skipped, a changed one is re-parsed') and clarifies the one-to-one mapping between matter and database file. It does not mention side effects like destructiveness, but these are minor for an open/load operation.
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 pack the core purpose, the resource model, the idempotency detail, and an explicit ordering instruction without any fluff. The structure is highly efficient.
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 all parameters fully described, behavioral traits disclosed, an output schema present, and a clear entry-point directive, nothing an agent needs to call this tool correctly is missing. The description even gives naming guidance and the date format.
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 100% and every parameter has a concrete description. The name is defined as 'the matter's name, as the deal team calls it', side is limited to 'buy' or 'sell', objective explains its purpose, and as_of_date specifies format and why it matters ('Prompts compare dates to it').
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 action ('Open the matter... and load the review-table prompt corpus') with a clear resource ('one matter is one database file'). It further clarifies its role as the entry point ('Call this before anything else') and differentiates itself from the operational siblings by being the initial setup 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?
Explicitly instructs the agent to call it before everything else, which is a direct usage directive. It also explains the idempotent loading behavior, telling the agent when work can be skipped, thus providing clear context for when and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the entities named in the Table Instructions, so their placeholders bind.
The corpus ships templates: [Project name], [Exact legal name] ([jurisdiction and entity type]; [role in the group]), [Buyer legal name]. Left unbound, a prompt asks
the model to decide whether a document's party is a review subject against a list of
square brackets — and Unable to determine becomes the correct answer to the wrong
question. Call this before any run, and it reports any placeholder still unbound.
| Name | Required | Description | Default |
|---|---|---|---|
| replace | No | Discard the existing entity list first. | |
| entities | Yes | One record per named entity: {name, jurisdiction, role, is_subject}. is_subject true for target-group entities, false for the buyer, seller and advisers. Roles 'buyer', 'seller'/'parent' and 'adviser' bind their own placeholders. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does mention that it reports any unbound placeholder, but it omits details such as whether entities are appended or replaced (the schema's 'replace' parameter is not referenced) and what happens on invalid input. This is partial transparency.
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 a single paragraph that front-loads the purpose and then explains the rationale and timing. It is not overly long, and every sentence contributes meaning, though it could be tightened without losing substance.
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 presence of an output schema and a detailed input schema, the description adequately explains when to use the tool and what problem it solves. It covers the tool's role in the workflow but does not delve into edge cases or error handling, which are likely covered by the schema and output.
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 schema covers 100% of parameters with descriptive text (e.g., the entities array structure and roles). The description adds context about templates and how placeholders bind, which is useful but not specific to parameter syntax or constraints. Thus, it stays at the baseline for a fully documented 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 clearly states the action ('Record') and the resource ('entities named in the Table Instructions') with a specific goal (bind placeholders). It also provides context about the templates and the problem of unbound placeholders, which distinguishes it from sibling tools that handle other aspects of the workflow.
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 explicitly says 'Call this before any run' and explains the negative consequence of not doing so, giving clear timing guidance. It does not mention alternatives or exclusions, but the context makes its role unambiguous among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what the matter holds: documents, classification, units, and cells filled per table.
Reports documents that carry no classification, because no table can see those.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains the special behavior of including unclassified documents and the rationale behind it. It does not mention side effects, but as a report tool, read-only behavior is implied, and the description does not contradict any 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 exactly two sentences: the first front-loads the main purpose, the second adds a clarifying nuance. There is no fluff, and each sentence 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?
For a simple zero-parameter report tool, the description covers everything needed: what it reports, the special case of unclassified documents, and the rationale. The presence of an output schema handles return format, so nothing critical 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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and none are present, so this is appropriate. The schema coverage is 100% (vacuously), and the description adds no parameter-specific detail because there are none.
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 ('Report') and resource ('the matter'), and enumerates the exact contents covered: documents, classification, units, and cells filled per table. It is clearly distinguishable from sibling tools like table_describe or matter_open, which focus on different aspects.
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 a clear use case: to obtain an overview of a matter's holdings, and explicitly notes that it reports unclassified documents because no table can see them. It does not name alternatives explicitly, but the context is sufficient for an agent to decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what run_table would cost, without running it or spending anything.
Counts the exact requests the run would send. Cells that are already filled, locked, or reviewed are excluded, because a run would skip them. Reports the cost both with and without the cached unit prefix, so the saving from that design is visible.
Call this before any run over more than a handful of rows.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Price against this model instead. | |
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. | |
| refill | No | Include cells that already carry a value. | |
| columns | No | Restrict to these column names. | |
| provider | No | 'openai' or 'anthropic'. | |
| unit_ids | No | Restrict to these rows. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool does not execute anything ('without running it or spending anything'), explains that filled/locked/reviewed cells are excluded (since a run would skip them), and notes it reports costs both with and without the cached unit prefix. This is transparent about scope and side effects (none), going beyond a simple 'estimate' label.
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 compact and front-loaded with the core purpose, then elaborates on mechanics and usage in three tightly-written sentences. Every sentence adds value: purpose, exclusions, cost comparison, and when to call. There is no filler or redundancy.
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 tool has an output schema (not shown but flagged as present) and complete parameter coverage, so the description does not need to describe return format. It covers what the tool does, what it excludes, how it reports cost, and when to use it. Nothing an agent needs to decide whether to call it or to understand its behavior 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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds behavioral context (e.g., exclusions related to refill and cell state) but does not directly explain any parameter beyond what the schema already provides. It helps an agent infer how refill interacts with exclusions, but that is indirect. Since the schema already documents each parameter thoroughly, the description does not need to add more.
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 'Report what run_table would cost, without running it or spending anything,' which names the specific verb (report), the resource (cost of run_table), and explicitly distinguishes it from actually running. It also explains the counting of exact requests and exclusions, so an agent can immediately tell this apart from the sibling run_table tool.
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 an explicit trigger: 'Call this before any run over more than a handful of rows.' This is a direct usage guideline that tells the agent when to invoke it, and it implies the alternative (run_table) without needing to name it. It also clarifies the purpose as a pre-run check, which is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a run's progress, token spend, and any error that stopped it.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | One run; omit for the last twenty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. 'Report' signals a non-mutating read, and the listed outputs are concrete, but there is no explicit statement about side effects, permissions, or how errors are surfaced beyond the output 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?
The description is one efficient sentence with no filler or redundancy. Every word contributes to the tool's purpose and output scope, and the key verb and object are front-loaded.
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 simple one-optional-parameter status tool, the combination of description and schema is nearly complete, and an output schema exists to define returned values. The main omission is explicit guidance on when to prefer this over sibling status/table tools.
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 schema already documents the single run_id parameter at 100% coverage, including the default behavior ('omit for the last twenty'). The description adds no additional parameter meaning, so the baseline score of 3 applies.
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 uses a specific verb ('report') and names the resource ('a run') plus the exact information delivered (progress, token spend, errors). It is clear and distinct from siblings like run_estimate by content, though it does not explicitly call out alternatives.
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 when to use the tool: anytime a caller needs run progress, token spend, or stopping errors. It provides no explicit when-not-to-use guidance or mention of sibling tools, so the context is usable but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a review table's cells, in dependency order, from the documents in each row.
The run is durable: every cell commits as it is filled, so calling again after a failure resumes rather than restarting. Already-filled cells are skipped unless refill is set, and a locked or human-corrected cell is never overwritten.
Each cell is checked against the 00a standards before it persists: the fallback vocabulary, Classify options, ISO dates, no markdown, no arithmetic, and for Verbatim columns that the quoted text actually appears in the row's documents. Violations are recorded on the cell and returned as findings.
This spends money. A 27-column table over 40 rows is roughly 1,080 model calls.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Override the model for this run. | |
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. | |
| reason | No | Why this run exists, for the record. | |
| refill | No | Re-fill cells that already carry a value. | |
| columns | No | Restrict to these column names. | |
| provider | No | 'openai' or 'anthropic'. Defaults to DILIGENCE_KERNEL_PROVIDER. | |
| unit_ids | No | Restrict to these rows. | |
| concurrency | No | Model calls in flight at once, within a stage. Default 6. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: mentions durability, resume on failure, skip unless refill, respect for locked cells, compliance checks, cost estimate, and recording violations as findings. This is thorough for a complex operation.
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?
Paragraphs with clear topic separation, no fluff, but could be more scannable with bullets. The cost detail is useful but not essential upfront, slightly pushing the length down from perfect.
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 a complex tool with output schema and 8 params, description covers execution semantics, edge cases (refill, locked cells), compliance, and cost impact. Output schema exists so return values need no explanation. Complete for an agent to call effectively.
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 100%, so baseline is 3. The description adds context for 'refill' (skip unless set) and notes provider defaults, but doesn't explain syntax for 'table' or 'columns' beyond schema, keeping it at baseline.
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 clearly states it fills review table cells from documents, with a specific verb and resource. It is distinct from sibling tools like run_estimate and table_read by focusing on execution rather than estimation or reading.
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 implicit usage via mention of dependency order, durability, and flags, but no explicit when-to-use or alternatives. For example, it doesn't compare against run_estimate for cost estimation or table_read for checking values, leaving the agent to infer based on the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a table: its review unit, grouping, Table Instructions, and every column.
Each column reports its native type, execution stage, configured options, and any pre-run verification caveat the inventory recorded against its type.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It clearly frames the tool as descriptive and lists the kinds of metadata returned, but it does not explicitly say the operation is read-only or note any side effects, error conditions, or access requirements.
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 tight paragraphs: the first states scope, the second details column-level coverage. No filler or repetition; the most important content is front-loaded.
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 low-complexity describe operation with a documented schema and output schema, the description covers what is described and what each column report includes. It could add explicit read-only/semantic context, but little essential information 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?
The schema describes the single parameter well ('Table number as the corpus defines it, e.g. '01' or '13''), and the description reinforces that the table is the subject being described. With 100% schema coverage, there is no gap to compensate for, so a baseline 3 is appropriate.
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 action and resource: 'Describe a table' and enumerates what is covered (review unit, grouping, Table Instructions, every column). It is clear but does not explicitly distinguish itself from sibling tools like table_read or columns_find.
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?
No guidance on when to prefer this tool over alternatives. The description implies 'use when you need table metadata,' but it never states exclusions, prerequisites, or contrasts with table_read or columns_find.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a filled table: one entry per row, with each cell's value, review status, and violations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. | |
| columns | No | Only these columns. | |
| only_flagged | No | Only cells carrying a standards violation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It does state the output structure (rows with value, review status, violations) and implies a read-only operation, but it does not disclose edge cases like what happens for empty tables, pagination, or error behavior. The 'filled' qualifier is vague, and there is no mention of rate limits or authentication. This is borderline sufficient but lacks needed detail.
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 a single, efficiently worded sentence. It front-loads the primary action and immediately describes the output shape. There is no wasted text.
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 the description need not detail return types. However, the description fails to explain the likely important 'filled' condition, does not mention how `limit` or `only_flagged` affect results (though these are in the schema), and provides no usage context or behavioral expectations. It is adequate for a simple read, but not comprehensive.
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 75% (limit lacks a description), and the tool description adds no extra parameter information. The schema already describes `table`, `columns`, and `only_flagged`. The description does not clarify relationships between parameters or provide additional context, so it stays at the baseline.
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 uses a specific verb ('Read') and resource ('a filled table'), and specifies the output structure (each cell's value, review status, and violations). It is clear enough to distinguish from table_describe (which likely describes schema), but it doesn't explicitly name any sibling alternative, so it does not fully differentiate.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of table_describe for schema, cell_evidence for individual evidence, or any other conditional. The description assumes the agent knows when to call it, which is not reliable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write the review units for a table. Units a human assembled are never replaced.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. | |
| replace | No | Discard existing auto-assembled units first. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key safety property: human-assembled units are never replaced. However, it does not explain behavior for auto-assembled units without the 'replace' parameter, nor does it describe idempotency, permissions, or potential side effects beyond the schema's 'replace' field description. The note adds value but is incomplete for a mutation tool.
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 concise, consisting of two short sentences with no redundant phrasing. The primary purpose is front-loaded in the first sentence, and the second sentence adds a critical constraint. It is appropriately sized for the operation, though it could benefit from a brief usage note without becoming verbose.
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 covers the core purpose and a key safety behavior, but it lacks guidance on when to invoke this tool, any prerequisites (e.g., table existence or prior proposal step), and what happens to existing auto-assembled units when 'replace' is false. The output schema is present, so return format is handled, but the description does not fully contextualize the tool within a workflow, leaving some ambiguity for the agent.
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 100%, so both parameters ('table' and 'replace') are already documented with clear descriptions. The tool description does not add any additional meaning or context for the parameters, relying entirely on the schema. This meets the baseline for a fully covered schema, but no extra value is provided.
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 clear verb ('write') and resource ('review units for a table'), which conveys the core action. It does not explicitly name sibling tools for differentiation, but the action is specific enough to distinguish from related operations like 'units_propose' or 'table_read'. The mention of never replacing human-assembled units adds a scoping constraint, though the purpose is still slightly reliant on domain knowledge.
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 no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical invocation contexts, or cases where a sibling tool like 'units_propose' would be more appropriate. The only hint is the action of writing units, which implies usage but leaves the decision to the agent without clear cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the rows a table would run over, without writing them.
Grouped tables assemble a family from a base document plus everything issued under it. Reports dependents whose base is absent or ambiguous: 00a warns that a family missing an amendment produces a confidently wrong row and nothing else detects it.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table number as the corpus defines it, e.g. '01' or '13'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses a key behavior: the tool does not write rows ('without writing them'), and it describes a specific warning mechanism (00a for ambiguous families). This is transparent about its side-effect-free nature and a notable edge-case behavior, though it does not mention permissions, performance, or return format (output schema exists).
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 two sentences. The first is a clear, front-loaded summary. The second provides useful context about grouped tables and the warning, which earns its place. It is not verbose, though the second sentence is long and could be split for readability, but overall it is efficient.
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 preview tool with an output schema, the description covers the essential behavior (dry-run, no writes) and a specific warning condition. It does not mention prerequisites or side effects beyond non-writing, but given the simplicity and existing output schema, it is reasonably complete.
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 schema already fully documents the 'table' parameter (100% coverage), including the format and examples. The description adds no extra semantic detail about the parameter itself; the grouped-table context is about the tool's behavior, not the parameter. Baseline 3 is appropriate when schema is sufficient.
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 clearly states a specific verb-resource pair: 'Show the rows a table would run over, without writing them.' This distinguishes it from writing tools, but it does not explicitly name sibling tools (e.g., run_table or units_assemble) or state why it is preferred for previewing. The grouped-table explanation adds context but does not name alternatives.
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 (preview before writing) and explains the behavior for grouped tables and the 00a warning, but it does not explicitly state when to use this tool over siblings, nor does it list exclusions. The context is present but not framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract, chunk, and store every supported file under a directory.
Idempotent by content hash: an unchanged file is skipped. A PDF page with no text layer is a scan, and is read by OCR — locally with tesseract by default, so nothing leaves the machine. A document read that way records that its text is a transcription rather than the document's own, reports the engine and its confidence, and any Verbatim cell drawn from it is flagged: the quotation was checked against a reading of the page, not the page.
vision sends page images to the model instead. It reads harder scans, but it
transcribes fluently, so a misreading looks like ordinary text — opt in deliberately.
| Name | Required | Description | Default |
|---|---|---|---|
| ocr | No | auto (default, local tesseract) | tesseract | vision | off. | |
| path | Yes | Directory holding the data room. | |
| force | No | Re-extract files whose content is unchanged. | |
| recursive | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does so thoroughly: idempotency by content hash, local tesseract OCR by default, no data leaving the machine, transcription provenance flags, and a candid caveat about vision mode's fluent-but-plausible misreadings. This is exactly the safety-relevant behavior an agent needs before invoking.
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 dense paragraphs with no filler: purpose first, then idempotency, then OCR behavior, then the critical vision caveat. Each sentence carries information an agent needs for correct and safe invocation.
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 moderate complexity and that an output schema exists, the description covers the behavioral decisions that matter: what gets skipped, how scans are handled, what happens to extracted text, and when vision should be opted into. Nothing material to calling the tool correctly is left unexplained.
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 schema documents three of four parameters; the description adds meaningful meaning beyond it, especially for ocr (local vs vision trade-offs, privacy, transcription flagging) and force (contextualized by the idempotency-by-hash behavior). Only recursive lacks any prose, but the phrase 'under a directory' and its default mitigate the 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?
The opening line uses a specific verb set — 'Extract, chunk, and store' — with a scoped resource ('every supported file under a directory'). This makes the batch-ingest role immediately clear and distinguishable from the read/search siblings like vault_search and table_read.
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 the use case (bulk ingestion of a directory into the vault) and explains key modes, but it never explicitly states when to choose this tool over an alternative or when not to use it. No sibling is named as a fallback, so the agent must infer routing from the tool name and opening verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the vault's text and return passages with their document, page, and offsets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What to look for, in the documents' own words. | |
| unit_id | No | Restrict to one review unit. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions that it returns passages with metadata, which is minimal. It does not disclose whether the operation is read-only, any side effects, authentication needs, rate limits, or other behavioral traits. Given the lack of annotations, the description should have provided more transparency but does not.
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 a single concise sentence that communicates the core function and output without any fluff or unnecessary detail. It is well-structured and easy to parse, making it ideal for quick agent comprehension.
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 and schema together provide enough for a basic call: the required query parameter and the output format are clear. However, it lacks context on when to use this tool, potential limitations (e.g., scope of search), or error conditions. Still, for a straightforward search operation, it is fairly complete, though not exhaustive.
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 schema describes 'query' and 'unit_id' with clear semantics, but 'limit' has no description, leaving only its integer type and default (10) to infer its meaning. The tool description also does not clarify the role of 'limit'. Thus, parameter semantics are only partially covered, and the agent must infer some details from 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 description clearly states the action (search), the resource (the vault's text), and the output (passages with document, page, and offsets). It is specific and distinct from the sibling tools such as vault_ingest (which adds content) or table_read (which reads tabular data), making it easy for an agent to identify the right tool.
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 the tool is used to search vault text, but it does not explicitly state when to use it versus alternatives or mention any exclusions. No sibling tools are referenced, and there is no guidance on contexts where this tool should not be used. The usage context is only implied by the tool's name and description.
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.0artifact_buildartifact_listcell_evidencecell_reviewclassification_recordcolumn_promptcolumns_findmatter_openmatter_parameters_setmatter_statusrun_estimaterun_statusrun_tabletable_describetable_readunits_assembleunits_proposevault_ingestvault_searchScored across 19 tools
Each tool has a distinct responsibility: opening a matter, describing tables, setting parameters, ingesting/searching documents, recording classifications, assembling units, running/estimating/monitoring table runs, reading/reviewing cells, and managing prompts/artifacts. There is no meaningful overlap or ambiguity between tool names and their purposes.
Most tools follow a clear `object_verb` pattern (table_describe, vault_ingest, units_propose, cell_review), but `run_table`, `run_estimate`, and `run_status` invert to `verb_object`, and a few names like `cell_evidence` and `artifact_list` are noun-noun. The pattern is predictable overall with minor deviations.
At 19 tools, the server is slightly above the typical well-scoped range, but the count is justified by the breadth of the due-diligence workflow: ingestion, classification, table execution, evidence review, and artifact building. Each tool addresses a real step with no obvious redundancy.
The tool set covers the full review lifecycle: ingest documents, classify them, assemble review units, run table prompts, inspect evidence, record human review decisions, and build derived artifacts. There are no obvious dead ends—every produced object can be read, checked, or acted upon by another tool.
AI transaction coordinator + legal-matters platform for real estate and law firms.
Turn sales-call transcripts into traced proposals, contracts, and NDAs.
Cross-model evidence pipeline for financial filings & contracts. x402 pay-per-call.
Pre-diligence AI for founders, investors, and firms — multi-agent pitch analysis and deal flow.
