Skip to main content
Glama
mfbaig35r
by mfbaig35r

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OPENAI_API_KEYNoYour OpenAI API key. Required when DILIGENCE_KERNEL_PROVIDER is 'openai'.
ANTHROPIC_API_KEYNoYour Anthropic API key. Required when DILIGENCE_KERNEL_PROVIDER is 'anthropic'.
DILIGENCE_KERNEL_DBYesPath to the SQLite database file for the matter. Required for every run.
DILIGENCE_KERNEL_OCRNoOCR engine for scanned PDFs: 'tesseract' (default), 'vision', or 'off'.tesseract
DILIGENCE_KERNEL_MODELNoThe model identifier to use. Defaults to 'gpt-5.4'.gpt-5.4
DILIGENCE_KERNEL_CORPUSYesPath to the review-table-prompts directory (the prompt corpus). Required for every run.
DILIGENCE_KERNEL_EFFORTNoReasoning effort level: 'low', 'medium', 'high', 'xhigh', or 'max'. Defaults to 'medium'.medium
DILIGENCE_KERNEL_PLAYBOOKNoAbsolute path to the firm playbook repository. Optional.
DILIGENCE_KERNEL_PRICE_INNoCustom USD price per million input tokens for cost modelling. Optional.
DILIGENCE_KERNEL_PROVIDERNoThe model provider to use. Defaults to 'openai'. Can be 'openai' or 'anthropic'.openai
DILIGENCE_KERNEL_PRICE_OUTNoCustom USD price per million output tokens for cost modelling. Optional.
DILIGENCE_KERNEL_CONCURRENCYNoNumber of model calls in flight within a stage. Defaults to '6'.6

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
matter_openA

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.

matter_parameters_setA

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.

matter_statusA

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.

vault_ingestA

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.

vault_searchA

Search the vault's text and return passages with their document, page, and offsets.

classification_recordA

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.

units_proposeA

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.

units_assembleB

Write the review units for a table. Units a human assembled are never replaced.

run_tableA

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.

run_estimateA

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.

run_statusA

Report a run's progress, token spend, and any error that stopped it.

table_readB

Read a filled table: one entry per row, with each cell's value, review status, and violations.

cell_evidenceA

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.

cell_reviewA

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.

table_describeB

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.

column_promptA

Return one column's full prompt text, with its upstream and downstream columns.

columns_findA

Find columns across all 24 tables by name, purpose, or prompt text.

artifact_listA

List the derived artifacts and what each is built from.

artifact_buildB

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 19 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues