Skip to main content
Glama
mfbaig35r
by mfbaig35r

matter_open

Open a matter database and load its review-table prompt corpus for due diligence. Skips unchanged inventories; call before any other tool.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe matter's name, as the deal team calls it.
sideNo'buy' or 'sell'.
objectiveNoWhat the deal team is trying to learn.
as_of_dateNoThe diligence as-of date, YYYY-MM-DD. Prompts compare dates to it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.