Screen M&A deal documents for red flags across 15 risk categories; findings checked against source.
Scored across 4 tools
The four tools map to distinct operations: single screening (screen_document), batch screening (bulk_screen), job polling (get_bulk_status), and result retrieval (get_analysis). The only mild overlap is that bulk_screen can screen a single document, but the descriptions clearly delineate batch vs single-document use.
Mostly consistent verb_noun pattern (get_analysis, get_bulk_status, screen_document) with the 'get_' prefix for reads. bulk_screen inverts the order (adjective_verb) relative to screen_document, a minor deviation but still readable and predictable.
Four tools is a lean but sensible surface for an upload/score/retrieve service, with each tool earning its place. It is slightly thin—no query/list or account tool—but not under-scoped for the core screening workflow.
The core lifecycle is covered: upload+score (single and bulk), poll status, and fetch stored analysis. Minor gaps exist—no tool to list previously screened documents, check account quota (referenced but not exposed), or delete/re-screen results.
Upload up to 25 documents and screen them as one batch. Waits for text extraction, then starts scoring and returns job ids; poll get_bulk_status until the batch is finished. Each item is {title, content_base64 | text, filename?}. The 25-document limit is not the binding one for large files: the whole call must stay under 32 MB including base64 overhead, so send fewer, larger documents per batch rather than filling all 25 slots. Exceeding it is a bare HTTP 413 from the transport, before this tool runs. To RESUME a batch that was uploaded but not scored — this tool timed out waiting for extraction, or scoring failed to start — call it again with 'bulk_job_id' instead of 'documents'. That re-uses the existing upload and does NOT spend the account's quota a second time. If the batch is rejected because one or more documents are too large for the plan's scan engine, retry with force_precision=true to scan those documents truncated to the recall window (coverage beyond it is excluded).
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | ||
| industry | No | ||
| documents | No | ||
| bulk_job_id | No | ||
| deal_room_id | No | ||
| document_type | No | Report | |
| force_precision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the 32 MB cap including base64 overhead, that the limit surfaces as a bare HTTP 413 from the transport before the tool runs, that it blocks on text extraction before returning, that resuming does not spend quota twice, and that force_precision truncates to the recall window and excludes coverage beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and operationally dense throughout, with every sentence carrying distinct information. The 25-document versus 32 MB nuance and the 413 note take several sentences to make a single point, which is the only mild bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotation set, so the description must explain returns and failure paths; it covers job ids, the polling sibling, the 413, quota-safe resume, and the plan-limit retry. The only real gap is that the four unexplained optional parameters leave configuration ambiguity for an 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 0%, so the description must compensate. It defines the documents item shape ({title, content_base64 | text, filename?}), the resume semantics of bulk_job_id, and the effect of force_precision, but leaves engine, industry, deal_room_id, and document_type entirely unmentioned, so the agent must guess at four optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with explicit scope: 'Upload up to 25 documents and screen them as one batch.' It also distinguishes itself from siblings by naming get_bulk_status for polling and by framing itself against the implicit single-document case handled by screen_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions plus alternatives: poll get_bulk_status for progress, re-invoke with bulk_job_id to resume an unscored batch, and retry with force_precision=true when documents exceed the plan's scan engine. Each branch names the trigger and the correct action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the stored risk analysis for a document already screened by this account. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
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 does disclose 'Read-only', which is the key safety trait. It also implies account-scoped lookups of previously stored results, but says nothing about auth requirements, error behavior for unscreened documents, or staleness of the stored analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero padding, and the core action is front-loaded before the scoping qualifier and the read-only note.
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 read tool with no annotations and no output schema, the description covers the essentials: what is returned, the precondition, and the side-effect profile. A brief note on the return shape or behavior when no analysis exists would make it fully 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 coverage is 0%, but there is only one required parameter (document_id) and the description's 'for a document' makes its meaning fairly self-evident. It adds no format/origin detail (e.g., that the ID comes from screen_document), so it only partially compensates for the coverage 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?
Clear specific verb+resource: 'Retrieve the stored risk analysis for a document'. The qualifier 'already screened by this account' scopes it away from the screening siblings, but it never names screen_document or bulk_screen, so sibling differentiation is implicit rather than stated.
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?
'for a document already screened by this account' implies the precondition that screening must have happened first, which is useful context. However, it does not explicitly say when to use this versus screen_document or get_bulk_status, nor what to do if the document was never screened.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check progress of a batch started by bulk_screen. Pass the upload_job_id, the analyze_job_id, or both.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_job_id | No | ||
| analyze_job_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that this is a read-only progress check and that either or both IDs may be supplied, but says nothing about polling behavior, rate limits, terminal/error states, or what happens when neither ID is given (both are nullable with default null).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the purpose front-loaded and the parameter instruction second. Every clause 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?
No output schema and no annotations exist, so the description should ideally describe what 'progress' returns (status values, completion state). It covers the call mechanics adequately but leaves the return semantics entirely unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names both parameters and adds the important constraint 'or both', implying at least one is required despite the schema marking both optional with null defaults. It does not explain ID format or source beyond the implicit bulk_screen link.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check progress) and resource (a batch started by bulk_screen), and explicitly ties the tool to the originating sibling bulk_screen, so an agent can distinguish it from get_analysis and screen_document. The operation is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to use it: after starting a batch with bulk_screen. It does not name when-not to use it or an alternative for single-document status (get_analysis), so it falls short of explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a deal document and score it for risk across 15 categories. Returns the overall score, rating, whether the deal is flagged as blocked, and per-category findings. Provide the file either as 'content_base64' (PDF, DOCX, TXT or CSV) or as plain 'text'. The whole call must stay under 32 MB, and base64 adds about a third, so the document itself should be under roughly 24 MB — a larger one is rejected by the transport before this tool runs, which surfaces as a bare HTTP 413 rather than a normal tool error. Use the REST upload endpoint for anything bigger.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| title | Yes | ||
| engine | No | ||
| filename | No | ||
| industry | No | ||
| deal_room_id | No | ||
| document_type | No | Report | |
| content_base64 | No | ||
| force_precision | No |
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 well: it discloses the return shape (overall score, rating, blocked flag, per-category findings), the 32 MB call limit, the ~24 MB practical document limit, and the non-obvious failure mode (a bare HTTP 413 from the transport rather than a normal tool error). It omits auth/permission requirements, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then return values, then input mechanics and limits. Sentences are dense but each earns its place; the size-limit sentence is long and slightly tangled but conveys a genuinely useful constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-annotation, no-output-schema tool with 9 parameters, the description covers returns and limits well but leaves most parameters undocumented and says nothing about permissions or how engine/industry/document_type affect scoring. Adequate at the top level, incomplete at the parameter level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% across 9 parameters. The description documents only two inputs well (content_base64 with accepted file types, and text), leaving engine, filename, industry, deal_room_id, document_type, and force_precision entirely unexplained in both schema and description. Six of nine parameters are opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('upload ... and score') and resource (a deal document), and states the risk-scoring scope (15 categories). It does not explicitly contrast itself with the sibling bulk_screen, but the singular 'a deal document' implicitly distinguishes it from a bulk operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use guidance for input format ('content_base64' vs 'text') and names an explicit alternative for oversized documents (the REST upload endpoint). It does not contrast itself with sibling tools like bulk_screen, so it stops short of full when/when-not coverage.
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.
bulk_screenget_analysisget_bulk_statusscreen_documentReview contracts for risks: summary, severity-rated flags, key terms, and clause coverage.
Vendor checks: sanctions lists, SEC filings, domain age and a due-diligence report with sources.
Distressed-SMB diligence: bankruptcy, lawsuits, recalls, exclusions, WARN layoffs, liens (sourced).
Contract review that keeps your contracts: cited answers, Word redlines, key-date alerts.
Add one secure layer between your agents and this server.
