Skip to main content
Glama

Lease predicate catalog

doc_predicates
Read-onlyIdempotent

Look up the lease predicates doc_verify_facts and doc_abstract_lease know (lease.expiration_date, lease.base_rent_schedule, lease.go_dark, ...) before extracting: for each, its value shape as JSON Schema, one valid example with a quote that states it (and whether that example verifies), which parts of the value are checked against the quote and how (number, ratio, date, verbatim name, as-written words, a worded enum, a number inside free text), which count as checked only when the quote writes them out (summaries, some enums), and which always need review (true/false values and enums no wording confirms, such as a CAM cap method or a kick-out party) unless a person confirms them. Generated from the same tables the checks use. Give predicate for one, prefix (e.g. lease.renewal) for a group, or neither for all. Also returns notes on statuses, paths, human confirmation and the generic rules for any other dotted predicate. Reads no document.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "doc_predicates"
  }
}

Input Schema

NameRequiredDescriptionDefault
prefixNoOnly predicates starting with this, e.g. "lease.renewal" or "lease.". Give predicate or prefix, not both.
predicateNoOne predicate to describe, e.g. lease.go_dark. Omit both predicate and prefix for every lease predicate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive behavior, and the description reinforces this with "Reads no document." It goes further by explaining what the catalog returns, how examples are checked against quotes, which values require human confirmation, and that the catalog is generated from the same tables used by the checks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is relevant and front-loaded with the tool's purpose, but it is delivered as a single dense run-on sentence with nested clauses. It is understandable but not concise or well structured; bullet points or separate sentences would improve scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return values, and it does so substantially: value shapes, examples, verification status, checked parts, review requirements, and notes. It could be more precise about the exact response structure, but it is complete enough for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents predicate, prefix, examples, and the mutual exclusion rule. The description restates the mode semantics (one predicate, prefix group, or all) but adds little beyond what the structured schema provides.

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 opens with a specific verb and resource: look up lease predicates. It names the sibling tools whose predicates are cataloged (doc_verify_facts, doc_abstract_lease), so an agent can distinguish this from extraction and verification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage context: call this before extracting so the agent knows the predicate shapes and review rules. It also explains the three query modes: one predicate, a prefix group, or neither for all. It does not explicitly state when not to use it or compare it to schema_get, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.