Skip to main content
Glama

Deal book

deal_book
Read-onlyIdempotent

The deal book of the one team the caller's key reads; every row names that team (team_id, team_name). Without deal_id this lists deals ordered by their ranking window first (financing open, early stage, not confirmed, financing closed, cancelled) and the score inside it unless sort names one column, filterable by stage, window, country_code (ISO country codes), sector, status, eca, eca_named (only deals naming an export credit agency), minimum contract value (min_value_usd), and free text (q); sort is priority (the default, the window order above) or one column that orders the whole filtered book, score, value (the USD value), last_activity, stage (the pipeline order), name or first_seen, with direction desc (the default) or asc and rows without a value last, or latest_update, which ignores the window and orders by the newest dated event, rows without one last, desc only; paged with limit (default 50, maximum 100) and offset, with the exact total. Dismissed deals are excluded unless status asks for them, and the portfolio rows a desk holds back by default (closed, cancelled, older than the stale window of 12 months by default, no movement within the movement hold, own bank, domestic, below the value floor, a market outside the mandate; score_hidden true) are off the page unless include_hidden is true, stale_months and movement_months naming the two age rules in months, and score_own_bank marks the rows where your own bank is a lender. A row carrying merged_into was found to be a duplicate and folded into the deal that field names: read that deal instead, and expect this one to be dismissed. Each row carries its window (score_window and its label), the band word and reason count behind its score (score_band, score_reason_count), the confirmed state over its linked findings (state, state_label), the newest quote backed event date (event_date, null when no source stated one), the lender names on the deal (lenders), and the two derived sentences a desk reads first: angle (why the row is on the list) and ask (what is still to be financed, read from the confirmed state, the window, the agencies and the lenders; a row whose state no source confirmed reads State not confirmed by a source yet), latest_update (the newest event a source dated and confirmed, with its date, a short label naming the confirmed state and the amount only where a quote states it, the state and the finding_id it rests on, null when there is none) and has_unseen_update (true when that event reached the deal after your last open of it in the dashboard, null for an API key, which records no opens). With deal_id (the deal_id field of list rows) it returns one deal in full, with score_reasons, one plain sentence per scoring component saying which fact it matched, alongside parties carrying entity_id and node_id where bound, the cited timeline with press quotes (each entry also carrying the state its quote confirmed, the confirming passage and the event date), lifecycle events, sources each carrying source_tier (1 a primary source, 2 trade press, 3 an aggregator, which is also where an unclassified publisher lands) and its tier_label, the deal summary (summary_lines, three lines generated from the cited findings by fixed rules, not by a model, each with the finding and quote behind every field it states), the briefing (null, or text, drafted_at, drafted_by, which reads model, and sources, a quick summary an AI model drafts from the text of the deal's cited sources with those sources listed by source_id, url, publisher and published_at, only its numbers written in digits checked against that text, null until it is drafted, whenever no sentence passes its check, and when nothing is left once a clause asking the reader to confirm, verify, check or review anything is removed), the analyst's own next_action, and economics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text filter over deal names and summaries.
ecaNoKeep only deals naming this export credit agency.
sortNoThe order, default priority (the ranking window first). latest_update orders by the newest dated event, whatever the window. Any other value orders the whole filtered book by that one column.
limitNoPage size, default 50, maximum 100.
stageNoKeep only these lifecycle stages.
offsetNoRows to skip, default 0.
sectorNoKeep only these sectors.
statusNoKeep only these statuses; dismissed deals appear only when asked for here.
windowNoKeep only these ranking windows: financing_open, early_stage, not_confirmed, financing_closed, cancelled.
deal_idNoA deal_id from the list; when present the other arguments are not used.
directionNodesc (the default) or asc. The priority and latest_update orders read desc only.
eca_namedNoKeep only deals naming an export credit agency.
country_codeNoKeep only deals in these ISO country codes.
min_value_usdNoKeep only deals at or above this contract value in USD.
include_hiddenNoAlso serve the rows a desk holds back by default (closed, cancelled, older than the stale window, own bank, domestic); off by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / offset / maximum
      Added value: +9223372036854776000
  2. Changed3 schema fields changed
    • addedInput schema / properties / direction
      Added value: +{
      +  "description": "desc (the default) or asc. The priority and latest_update orders read desc only.",
      +  "enum": [
      +    "desc",
      +    "asc"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / sort / description
      Previous value: -"Ranking, default score."New value: +"The order, default priority (the ranking window first). latest_update orders by the newest dated event, whatever the window. Any other value orders the whole filtered book by that one column."
    • changedInput schema / properties / sort / enum
      Previous value: -[
      -  "score",
      -  "last_activity",
      -  "value",
      -  "first_seen",
      -  "latest_update"
      -]New value: +[
      +  "priority",
      +  "score",
      +  "value",
      +  "last_activity",
      +  "stage",
      +  "name",
      +  "first_seen",
      +  "latest_update"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / sort / enum
      Previous value: -[
      -  "score",
      -  "last_activity",
      -  "value",
      -  "first_seen"
      -]New value: +[
      +  "score",
      +  "last_activity",
      +  "value",
      +  "first_seen",
      +  "latest_update"
      +]
  4. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Annotations already declare a safe read (readOnlyHint, idempotentHint, destructiveHint false), yet the description goes far beyond them: default exclusion of dismissed and desk-held rows, the stale/movement age rules, merged_into duplicate folding, null semantics for event_date and has_unseen_update (null for API keys), and the exact conditions under which briefing is null. This is unusually rich behavioral disclosure.

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

Conciseness2/5

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

The core purpose is front-loaded, but the remainder is a single enormous multi-clause run-on that packs exclusions, sort semantics, row fields, detail-mode contents and briefing null-rules into one paragraph. Much of the return-field detail is arguably schema/output territory, and the lack of structure makes it hard to scan.

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?

For a 15-parameter, no-output-schema tool in a complex domain, the description is thorough about returned row fields, ordering, exclusions and the detail payload, so an agent can call it correctly. The phantom parameters it names (stale_months, movement_months, score_own_bank) introduce a small inconsistency that keeps it from a 5.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks: the priority window ordering versus single-column ordering, that latest_update bypasses the window and is desc-only, and rows without a value sorting last. It loses a point because it references stale_months, movement_months and score_own_bank, which do not exist in the input schema and could mislead the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the resource and its scope precisely ('the deal book of the one team the caller's key reads'), and the description clearly distinguishes the two modes: a filtered list without deal_id and a full single-deal view with deal_id. It never names or contrasts with the obvious siblings (portfolio_book, deal_binding_queue, portfolio_overview), so an agent must infer which book to open.

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

Usage Guidelines3/5

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

It gives conditional guidance within the tool (deal_id switches to detail mode, include_hidden turns on held-back rows, latest_update ignores the window), which is genuinely useful. However there is no when-to-use vs. when-not-to-use relative to the sibling book tools, and no stated prerequisites or authorization context beyond 'the caller's key'.

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.

Resources