Lev

Permanently delete a free-text note from a contact, deal, placement, or company — or a comment from a checklist task. Use only when the user asks to remove a human-written note. To remove another resource, use that resource's delete/archive tool instead — this only deletes notes. parent_type: "contact", "deal", "placement", "company", or "checklist_task" — which kind of record owns the note parent_id: numeric ID of the contact, deal, placement, company, or checklist task note_id: numeric ID of the note to delete This is a permanent hard delete with no undo. You can only delete a note you created and still have parent write access to; another user's note or a note on another parent returns not found.

delete_note

Delete a term sheet. Soft delete — reversible by Lev support.

delete_term_sheet

Get the list of property asset type classifications used in Lev. Returns top-level types like Office, Apartment/Multifamily, Industrial, Retail, Hotel, Self-Storage, etc., with nested property_sub_types. The top-level asset type id identifies the broad category; the create_deal/update_deal property asset_type_id field expects a nested property_sub_types[].id value, not the top-level asset type id.

get_asset_types

Get current market base rates (SOFR, Prime, Treasury, etc.). Returns the latest reference rates used in CRE lending. Useful for understanding current market conditions and evaluating term sheet rates. Data is cached and updates approximately every 30 minutes.

get_base_rates

Get one company by its numeric ID. Use when you already have a company_id. To search by name, state, or city, use list_companies. Do not expect fields beyond the company records returned by list_companies.

get_company

Get one contact by its numeric ID. Use when you already have a contact_id. To search by name, email, or type, use list_contacts. Do not expect fields beyond the contact records returned by list_contacts. Returns an already-revealed or connected contact. A lender contact Lev matched to a placement but that has not been paid for is masked and cannot be read here — reveal it with unlock_contact (a paid action).

get_contact

The deal's stored CRM fields — loan amount, sponsor, status, close date, financials, properties, team, pipelines, and archived state. Use when the ask names specific stored fields, or to drill in after list_deals. Use a sibling instead when the ask is: where a number came from or what the documents say (search_deal_index); a written summary, memo, or email overview (summarize_deal); or "show me / pull up / open" the deal as a visual card (show_deal). The include parameter controls which sub-resources are embedded: financials — NOI, LTV, costs properties — addresses, asset types team — assigned users and roles pipelines — pipeline rows (pipeline_id, pipeline_name, pipeline_type, pipeline_status_id, status, status_name, updated_at), capped at 10; empty when the deal is on no pipeline. To narrow the response, pass a comma-separated subset (e.g. include="financials,pipelines"). The response also reports archived (true once the deal has been archived) and archived_at (its ISO 8601 timestamp, or null when active) — top-level fields, present regardless of include. Archiving does not rewrite pipeline status, so an archived deal can still show a live-looking stage; trust archived over the stage. Response also includes a `urls` object with direct Lev web-app links. Stay in MCP first — facts: search_deal_index; edits: update_deal_index_fact / update_deal / update_company / update_contact; quote comparison: list_term_sheets. Never fabricate a url (links come only from the `urls` field, never the retired `levcapital.com` domain). Surface one only on explicit navigation asks or when the task cannot be done through MCP (file upload → `urls.dataroom`). Full intent→key mapping in the server instructions.

get_deal

Read a deal's checklist — what still needs to be collected, reviewed, or completed, and what's done. Use when the user asks what's outstanding, missing, still needed, requested, or finished on a deal: open checklist items, document requests, diligence or closing checklist progress. Each of the deal's Deal Rooms (shared datarooms) can carry its own checklist; this returns one checklist per Deal Room — the deal's primary Deal Room first — each with its sections and the tasks inside, in display order. Tasks carry two completion signals: is_completed is the done flag, and status is the review state — a task can be approved but not yet marked complete. Tasks can also include document_types (the expected document categories for that request) and files (attachments already linked to that task, with document_id, vault_resource_id, name, and origin). The checklist is still the deal's to-do / request list, not the full file browser: use list_deal_documents or browse_deal_vaults for every file uploaded to a vault, and search_deal_index for facts extracted from them. Each task can include assignee (the individual person) and assigned_team (the account, lender, or borrower team responsible for the task). Treat assigned_team.name as nullable: stale or out-of-scope team references keep id/type but return name as null. status: each task's review state — "to_do", "requested", "reviewing", "updates_needed", "approved", or "cancelled". vault_id: optional Deal Room id from list_deal_vaults to read just that room's checklist. Omit to get every Deal Room's checklist. A deal's private Resources area has no checklist (returns an empty list).

get_deal_checklist

Get one uploaded deal document, including a clickable download link. Use after list_deal_documents when the user wants to inspect, open, or download a specific uploaded file. Returns the document metadata plus download_link, a Markdown link labeled with the file name and backed by Lev's short-lived signed download URL. Present download_link as the clickable link it already is; never reconstruct or display the raw underlying URL. Use get_deal_memo instead for generated memo / deal book PDFs.

get_deal_document

Get one memo for a deal, including a downloadable PDF preview link. Use after list_deal_memos when the user wants to preview, open, or download a specific memo's PDF. memo_id is the memo's uuid from list_deal_memos. Returns the memo's metadata — including, when the workspace has them, who created it, when it was last modified, and which Deal Room(s) or Resources area it lives in — plus a pdf_link (a ready-to-click Markdown link to the rendered PDF) and a pdf_versions array with one link per rendered quality. On MCP Apps hosts (Claude Desktop) the memo renders inline as a scrollable PDF viewer (the ``ui://memo-view`` widget); other hosts see the markdown pdf_link. Present pdf_link to the user as the clickable link it already is; never reconstruct or display the raw underlying URL — it is a short-lived signed link. When the memo is an unpublished draft that has not been rendered yet, there is no PDF: pdf_link is absent and pdf_versions is empty (pdf_ready will be false). Say the PDF isn't available yet rather than implying one exists. quality: which rendered variant the top-level pdf_link points at. One of "original" (default, full fidelity), "high", "medium", "low" (progressively more compressed / smaller files). pdf_versions always lists every rendered variant regardless of this choice.

get_deal_memo

Get one lender's directory profile by id: name, website, address, lender type, and description. Lending program data (loan products, amounts, terms) is not available here. For the lenders that best fit a specific deal, with their relevant programs, use recommend_lenders_for_deal, or get_lender_recommendations to read a match already run. To find a lender's id from its name, use search_lenders.

get_lender

Retrieve the ranked lenders from a deal's AI match — scores, match reasons, and programs. Use after recommend_lenders_for_deal to read the results: the lenders Lev ranked for the deal, each with an AI score, the reasoning behind the match, and the lender's relevant loan programs (loan types, amount range, property_states, sponsor_states, asset types). property_states is where the property can be located; sponsor_states is where the sponsor can be located. sponsor_coverage "unknown" means that sponsor list is an unsourced default, not nationwide coverage, and sponsor_states is omitted. For one specific lender's profile by id, use get_lender instead. On MCP Apps hosts the results also render as an interactive ranked-match card where the user can select lenders to add to the deal or unlock. If the match is still running, the response says so and carries no ranked lenders yet — wait briefly and retrieve again. If no match has been run for the deal, start one with recommend_lenders_for_deal first. limit: how many ranked lenders to list in the text summary, best first. Defaults to 10 and is capped at 25; page for more with offset. The card independently receives the top matches. offset: 0-based index of the first lender in the text summary. Defaults to 0. When the response indicates more remain, add limit to offset for the next page.

get_lender_recommendations

Get your Lev account's current subscription and credit balance. Returns two blocks: - subscription: the active plan's type, status, billing cycle, and end date - credits: whether the account is provisioned for credit-based billing, the current balance, and the unit (always "credits") Use this before suggesting work that consumes credits (e.g. AI actions, some placement flows) to confirm the user has headroom. An `enabled` value of false means the account is not provisioned for credits — balance will be null rather than 0 so you can distinguish "not provisioned for credits" from "provisioned with a zero balance". Cost-per-credit and transaction history are not currently returned — use the web app for those.

get_my_billing_summary

Get your Lev profile, currently-active account, subscription tier, and API capabilities. Returns your user details, active account, subscription status, granted scopes, rate limits, and API key quota. Call this first to confirm your connection and see what you have access to. To see all accounts you can switch into, use list_available_accounts. To switch, use switch_account. The `granted_scopes` field is internal context for your own reasoning — use it to decide which tools a workflow is allowed to call. Do not echo the raw scope list back to the user; summarize capabilities in plain language if they ask what access they have.

get_my_profile

Get one placement by its numeric ID. Use when you already have a placement_id (e.g. 'show me placement 300'). To find placements by deal, lender, or status, use list_placements. Returns the same fields as a list_placements row — no additional detail. Rows include lender_name / contact_name, with masked placements showing non-owner viewers a generic lender_name (e.g. Lender A) and a null contact_name. The contact_id is still present on a masked placement — pass that contact_id (not the placement id) to unlock_contact to reveal the name and details (a paid action). score / lev_score are frequently null (scoring may not have run for the placement); treat null as 'no score available', not zero.

get_placement

Get full term sheet details including rate structure, fees, recourse terms, and extensions. Contains all financial details of a lender's loan quote: rate type (fixed/floating), base rate, spread, origination fee, prepayment penalty, amortization, IO period, extension options, recourse terms, DSCR/debt yield requirements, and more. Same masked-label behavior as list_term_sheets.

get_term_sheet

List the Lev accounts you can switch into. Returns each account's name, slug, and type. Use this before switch_account when the user asks to switch accounts but you don't know the exact target — show the returned list and let them pick by name. If you need to know which account is currently active, call ``get_my_profile`` — the backend tracks the active account server-side.

list_available_accounts

Search private companies (lenders and sponsors) in your account by name, state, or city. Returns company records. Use get_company only with a known company_id. is_connected: true returns connected companies; false returns disconnected companies. Timestamp filters: min/max_created_at and min/max_updated_at are inclusive gte/lte bounds. Use ISO 8601 datetimes with timezone: trailing `Z` or `±HH:MM`, e.g. 2026-04-01T00:00:00Z. sort: pass a bare key for ascending; prefix with a minus sign for descending (e.g. -name). Defaults to descending created_at. Valid keys (exact): "name", "city", "state", "created_at", "updated_at" Pagination: - Default (sort set): offset mode. Walk pages with offset=N using the value surfaced in the previous response's hint. - Stable paging for bulk sync: pass sort=None; walk pages with cursor=<value> from the hint. cursor and sort cannot be combined — passing both returns a 400.

list_companies

Search contacts (lender contacts and sponsor contacts) by name, email, or type. contact_type: one of "lender_contact", "sponsor", "legal" (the filter accepts any backend ContactType value; these are the externally useful ones) Timestamp filters: min/max_created_at and min/max_updated_at are inclusive gte/lte bounds. Use ISO 8601 datetimes with timezone: trailing `Z` or `±HH:MM`, e.g. 2026-04-01T00:00:00Z. Returns contact records. Use get_contact only with a known contact_id. sort: pass a bare key for ascending; prefix with a minus sign for descending (e.g. -last_name). Defaults to descending created_at. Valid keys (exact): "first_name", "last_name", "email", "created_at", "updated_at" Pagination: - Default (sort set): offset mode. Walk pages with offset=N using the value surfaced in the previous response's hint. - Stable paging for bulk sync: pass sort=None; walk pages with cursor=<value> from the hint. cursor and sort cannot be combined — passing both returns a 400.

list_contacts

Find specific uploaded files on a deal — by name, type, folder, or vault. Use when the user wants particular uploaded documents: a named file, a rent roll, an appraisal, a budget, closing docs, files of one extension, or the contents of one folder or one vault. Returns file metadata only; no signed download links. Each file is tagged with the container it lives in (Resources, or a Deal Room / shared dataroom). When naming a container to the user, use its title, never the raw type value. For a broad "what documents are on this deal / what's in the dataroom" ask — where the user wants to see or browse everything rather than find one file — use browse_deal_vaults instead: it opens the deal's document workspace and shows uploaded files and generated deal books together (users don't distinguish Lev's uploaded-documents-vs-memos split). Stay on this tool when the user names a specific file or filter (a rent roll, an extension, one folder, "how many"). Example: find the rent roll PDF on deal 174124 -> this tool; show me the documents on deal 174124 -> browse_deal_vaults. Use list_deal_vaults to see the deal's vaults themselves, get_deal_document when the user wants to open or download a specific file, and search_deal_index when the user asks what facts came from the documents. search: optional file-name search text. extension: optional file extension filter, with or without the leading dot; case is normalized before calling Lev. folder_id: optional folder id to list only files in one vault folder. vault_id: optional vault id to list only the files in one of the deal's containers (a Deal Room or Resources); ids come from list_deal_vaults. Omit to list across every container. limit: maximum documents to return. Defaults to 20, clamped by Lev to 1-200. cursor: pagination cursor from the previous response hint.

list_deal_documents

Resolve a Deal Index sidebar ?node= from a search_deal_index fact. Use after search_deal_index when a citation URL should open the matching Index section, not Deal Metadata. Does NOT return facts — use search_deal_index for values and sources; use list_deal_index_metric_definitions for the recordable-metric catalog. Each node's id is the portal ?node= value. Pass nodes through. Do not invent a node if the walk misses. value_type is not part of the walk. How to pick node from a search fact: Need category_id from search_deal_index. Without it, omit node. If entity_ref is set, first try a scoped match: ENTITY_GROUP.ref_id equals entity_ref, then BFS that group's descendants for the category_id. That keeps two properties with the same category_id from sharing a node. If that misses (deal-level / market facts often have entity_ref=deal:N and no ENTITY_GROUP), fall back to the first node with that category_id. Do not ignore entity_ref on a last-write-wins category_id map — wrong for multi-property citations. On the landed node, valid node types are SUB_CATEGORY, ENTITY_GROUP, or a drilldown METRIC_GROUP. Never CATEGORY. Facts usually land on a subcategory under an entity group, not on the group id itself. Drilldown means a parent SUB_CATEGORY with dashboard_type=table and 2+ table METRIC_GROUP children, or a mixed-container key_values parent. Those METRIC_GROUP ids are valid node values. Non-drilldown METRIC_GROUP: use the parent SUB_CATEGORY id, not the group id. Still no valid type — omit node. Never invent one. accountSlug comes from existing account/deal tools. instanceId is the citation skill's unique mark — this tool does not invent it. include: optional repeatable node-type filter. Values: "CATEGORY", "SUB_CATEGORY", "METRIC_GROUP", "ENTITY_GROUP". Omit for the full tree. This is GraphQL's type filter, not deal include=financials.

list_deal_index_taxonomy

List the memos (generated CRE deal books) for a deal. Use when the user asks what memos or deal books exist for a deal, or as the first step before fetching one to preview. Returns both published memos and unpublished drafts so a user can find work in progress, most recently active first. Narrow the result server-side with the filters below — published memos first, then drafts — rather than pulling every memo and filtering client-side. On MCP Apps hosts (Claude Desktop) the list renders inline as a memo browser (the ``ui://memo-view`` widget) where each memo expands into a PDF preview; other hosts see this JSON list. Each row carries the memo's publish status (draft or published), when it was published (null for drafts), its type, and a pdf_ready flag telling you whether a downloadable PDF has been rendered yet; when the workspace has them, a row also carries when the memo was last modified, who created it, and which Deal Room or Resources area it lives in. The list does not include the PDF link itself — call get_deal_memo for the downloadable preview link. A row also carries a memo_url deep link into the Lev web app; surface it only when the user explicitly asks to open the memo in Lev, and never fabricate one — use only the value present in the response. Filters below are optional and combine; pagination reflects the narrowed set. There is no sort control — ordering is fixed (published first). status: return only memos in one publish state. Values (exact): "draft", "published". Omit to return both. search: case-insensitive substring match on the memo title. Pass a distinctive fragment of the title, not the user's whole sentence. Omit to match every title. memo_type: return only memos of one kind. Values (exact): "debt_financing_om", "credit_memo", "investment_sales", "debt_brokerage", "equity_raise", "broker_opinion_of_value", "investment_committee", "invoice", "other". Omit to return all types. pdf_ready: pass true for only memos whose downloadable PDF has finished rendering, false for only those without a rendered PDF yet. Omit to return both. vault_id: optional vault id to list only the memos in one of the deal's containers (a Deal Room or Resources); ids come from list_deal_vaults. Omit to list memos across every container. limit: maximum memos to return. Defaults to 20, clamped by Lev to 1-200. offset: 0-based index of the first memo to return. Defaults to 0. When the response has has_more=true, walk to the next page by passing the offset emitted in the response hint; keep limit constant across pages.

list_deal_memos

See a deal's vaults — its Deal Rooms (shared datarooms) and its private Resources area. Use when the user asks what vaults, datarooms, or Deal Rooms a deal has, how its documents are organized into rooms, or wants to pick one to look in. To customers "vaults" usually means the shared Deal Rooms; a deal also has one private Resources area for its own working files. Returns each one with its title, whether it is the deal's primary Deal Room, and how many documents it holds. When naming one to the user, use its title (the Resources area shows as Deal Resources; Deal Rooms carry names like Deal Room, Closing, or a per-lender room) — never the raw type value. This returns the rooms (the containers), not the files inside them — use list_deal_documents to browse the files, optionally passing a vault_id from here to list just one room's files.

list_deal_vaults

Find, filter, and list CRE financing deals in your account. The home for "find / show me / which deals…" requests: search by name, or filter by loan type, transaction type, business plan, loan-amount range, created/updated timestamp range, which pipeline / pipeline status a deal is currently in, or whether it has been archived. For the deals *in* a pipeline, filter here by pipeline_id — list_pipelines only describes the pipelines themselves, and summarize_pipeline gives a narrative book-level read. Returns deal summaries; use get_deal for one deal's full detail, or summarize_deal for a written snapshot. search: the canonical path for resolving a deal by name — find the deal called X, pull up 23 Spruce Street. Case-insensitive substring match across deal title, property city/state, and sponsor company name. Pass the distinctive fragment (Spruce Street), not the user's whole sentence. Results are unranked — if too many match, narrow the term or add filters; never page the full account list to match names client-side when this parameter can do it server-side. Enum values (exact): loan_type: "construction", "heavy_bridge", "light_bridge", "permanent", "land", "predevelopment", "tbd" transaction_type: "acquisition", "refinance", "new_construction", "tbd" business_plan: "stabilized", "value_add", "construction", "land" Synonyms: a plain 'bridge' request spans both heavy_bridge and light_bridge — list both, or leave loan_type unset, rather than declining for lack of an exact match. Caveat on transaction_type: deals commonly have a null transaction_type — it is not required at creation and is often filled in later. Filtering by transaction_type silently excludes every deal that hasn't been categorized yet, so prefer leaving it unset unless you specifically want the categorized subset. Timestamp filters: min/max_created_at and min/max_updated_at are inclusive gte/lte bounds. Use ISO 8601 datetimes with timezone: trailing `Z` or `±HH:MM`, e.g. 2026-04-01T00:00:00Z. Pipeline filters (exact match only — one value each, no range or "in" support): pipeline_id: numeric ID of a pipeline (from list_pipelines). Returns only deals currently on that pipeline. pipeline_status_id: numeric ID of a pipeline status (from list_pipelines, which embeds statuses with IDs). Returns only deals currently in that specific status. Use this for stage-specific filtering and stuck-deal audits. archived: filter by lifecycle state. Omit (the default) to return active and archived deals together; pass false for only active deals, true for only archived ones. Archiving is a separate action from setting pipeline stage — an archived deal keeps its last stage, so filter on this rather than inferring archived-ness from a stalled status. Each returned row reports archived (true/false) and archived_at (ISO 8601 timestamp, or null when active). sort: pass a bare key for ascending; prefix with a minus sign for descending (e.g. -loan_amount). Defaults to descending created_at. Valid keys (exact): "title", "loan_amount", "created_at", "updated_at" Pagination: - Default (sort set): offset mode. Walk pages with offset=N using the value surfaced in the previous response's hint. - Stable paging for bulk sync: pass sort=None; walk pages with cursor=<value> from the hint. cursor and sort cannot be combined — passing both returns a 400. Each row also carries a `urls` object for direct navigation into the Lev web app. Stay in MCP first; never fabricate a url (links come only from the `urls` field, never the retired `levcapital.com` domain); surface a URL only on explicit navigation asks or when MCP can't fulfill the task (file upload → urls.dataroom). Full URL rules live in the server instructions.

list_deals

Read the notes logged on a contact, deal, placement, or company — or the comment thread on a checklist task. Use for human-written notes like call logs or relationship context. For structured underwriting facts (NOI, loan amount, where a number came from) use search_deal_index instead — that is not what notes are. parent_type: "contact", "deal", "placement", "company", or "checklist_task" — which kind of record to read from. "checklist_task" returns the comment thread shown on that checklist item in the borrower portal. parent_id: numeric ID of the contact, deal, placement, company, or checklist task Returns each note's text, author, and timestamps in chronological order (oldest first). Internal or private notes are not returned. Pagination: uses cursor pagination. To walk beyond the first page, pass the cursor value surfaced in the previous response's hint; the most recent notes are on the last page.

list_notes

List the pipelines themselves — their names, ordered statuses, and IDs. Each pipeline has ordered statuses that deals can be moved through (e.g., "New Lead" → "Under Review" → "In Closing" → "Closed"). Use this to discover pipeline and status IDs before calling move_deal_to_pipeline_status. This does NOT return the deals in a pipeline — to list those, use list_deals with pipeline_id (or summarize_pipeline for a narrative overview). Each status carries both a raw `status` (wire form, e.g. under_review) and a `custom_status_name` (display form, e.g. "Under Review"). When speaking to the user about a status, use `custom_status_name`; the raw `status` is for filtering and for the move_deal_to_pipeline_status call.

list_pipelines

List lender placements (outreach) across your deals. Shows which lenders have been contacted for each deal and their response status. Filter by deal_id to see all placements for one deal, or by status to find placements in a specific stage. Filter by contact_id or private_company_id to see every outreach aimed at a specific lender contact or lender company. Use get_placement only with a known placement_id. Rows include lender_name / contact_name with private_company_id / contact_id, so no follow-up get_lender / get_contact call is needed. Masked placements show non-owner viewers a generic lender_name (e.g. Lender A) and null identity / contact fields. Enum values (exact): status: "new", "sent", "lender_reviewing", "terms_received", "term_sheet_received", "executed_ts_in_closing", "closed", "unresponsive", "willing_to_negotiate", "lender_passed", "archived" lender_status: "origination", "new", "lead_qualification", "quotation", "negotiation", "offer", "term_sheet", "good_faith_deposit", "diligence", "in_closing", "closed", "archived" visibility: "hidden", "masked", "shared" Identity filters (exact match, no range): contact_id: numeric ID of a lender contact (use list_contacts or get_contact to find it). private_company_id: numeric ID of a lender company (use list_companies to find it). Timestamp range filters (ISO 8601 datetime with explicit timezone — trailing `Z` or `±HH:MM` — e.g. 2026-04-01T00:00:00Z; date-only and naive local forms are not guaranteed to parse): min_created_at / max_created_at: inclusive bounds on created_at (gte / lte). min_updated_at / max_updated_at: inclusive bounds on updated_at (gte / lte). sort: pass a bare key for ascending; prefix with a minus sign for descending (e.g. -score). Defaults to descending created_at. Valid keys (exact): "status", "score", "created_at", "updated_at" Pagination: - Default (sort set): offset mode. Walk pages with offset=N using the value surfaced in the previous response's hint. - Stable paging for bulk sync: pass sort=None; walk pages with cursor=<value> from the hint. cursor and sort cannot be combined — passing both returns a 400.

list_placements

List the metrics that CAN be recorded on a deal, with a routing hint. The tool for 'what metrics can I record / track on this deal?' and for finding a metric's id before recording a brand-new fact — it tells you which metrics exist (e.g. NOI, occupancy, purchase price) and, for each, the recommended way to write it. To find or change a fact the deal ALREADY has, use search_deal_index (it returns the fact's identifier directly); reach for this catalog to discover what's recordable. Each metric carries a suggested_write_via routing hint: - index — record it with record_deal_facts (a measured / extracted underwriting fact: NOI, occupancy, expenses, or source-reported valuation). Pass this metric's id to that tool. - deal_record — write it on the deal's canonical record instead; the metric also carries write_via_tool naming which tool to use (update_deal, update_company, or update_contact). - clarify — the metric can live in BOTH places and the right one depends on what the user means. Ask them: are they setting the deal's official value (→ the named CRM tool), or logging what a source reported (→ record_deal_facts)? Loan amount and deal financials are common cases. Do not pick a door without asking. suggested_write_via is a best-effort hint, not a guarantee — confirm the intended change with the user in plain English before any write, and never surface the hint, the metric id, or write_via_tool to them. metric_label: optional case-insensitive search term to narrow the catalog to matching metrics (e.g. occupancy, loan). category_id: optional numeric category filter. limit: maximum metrics to return per page. Defaults to 100, clamped by Lev to 1-200. The catalog is usually small — narrowing with metric_label or category_id is often easier than paging. offset: 0-based index of the first metric to return. Defaults to 0. When the response has has_more=true, walk to the next page by passing the offset emitted in the response hint; keep limit constant across pages.

list_deal_index_metric_definitions

List active team members in your Lev account. Returns each member's name, email, role, and title. /account/team uses offset pagination — walk subsequent pages with the offset value from the returned hint.

list_team_members

List term sheets (loan quotes from lenders) for a specific deal. Shows each lender's quote summary: lender name, rate, loan amount, and status. Masked non-owner reads may show generic lender_name (e.g. Lender A) and org_id=null. Use get_term_sheet for the full breakdown including fees, recourse, extensions, and prepayment terms. Pagination: uses cursor pagination. To walk beyond the first page, pass the cursor value surfaced in the previous response's hint.

list_term_sheets

Move a deal to a specific status in a pipeline. Use list_pipelines first to see available pipelines and their statuses (with IDs). Example: move a deal to "Under Review" in the Financing pipeline.

move_deal_to_pipeline_status

Stream an uploaded document's bytes in chunks for the inline viewer widget. Internal plumbing for the vault-browser widget — the model should not call this directly. Given a document's identifiers, the server re-resolves its short-lived signed download link (re-applying the caller's authorization on every call) and returns the requested byte range. The widget loops this, advancing offset until has_more is false, then renders or downloads the assembled bytes. Identifiers (not a URL) are passed in so no signed link is ever exposed to the client and the fetch target can't be tampered with; streaming through the server keeps the browser off S3 (no CORS) and bounds each response. deal_id, document_id: identify the document (same as get_deal_document). offset: 0-based byte offset to start at. byte_count: bytes to read this call (clamped to 512KB). The response carries total_bytes and has_more so the widget knows when to stop.

read_deal_document_bytes

Stream a memo PDF's bytes in chunks for the inline viewer widget. Internal plumbing for the memo-view widget — the model should not call this directly. Given the same identifiers as get_deal_memo, the server re-resolves the memo's signed PDF link (re-applying the caller's authorization on every call) and returns the requested byte range. The widget loops this, advancing offset until has_more is false, then renders the assembled bytes with PDF.js. Identifiers (not a URL) are passed in so no signed link is ever exposed to the client and the fetch target can't be tampered with. Streaming through the server keeps the browser off S3 (no CORS) and bounds each response. deal_id, memo_id, quality: identify the memo (same as get_deal_memo). offset: 0-based byte offset to start at. byte_count: bytes to read this call (clamped to 512KB). The response carries total_bytes and has_more so the widget knows when to stop.

read_memo_pdf_bytes

Run Lev's AI lender match for a deal — the ranked lenders to take this deal to. The home for "which lenders should I approach for this deal", "find me lenders", "run lender matching". Triggers an AI-ranked search that scores the lenders most likely to finance the deal. To look up one lender you already know by id, use get_lender instead; this discovers and ranks lenders for a specific deal. Paid action — running the match costs about 2,000 credits. It runs in two steps so the cost is never charged without agreement: called without confirmation it charges nothing and returns the cost so you can tell the user and ask whether to proceed; once they agree, run it again with confirmation to start the match. State the credit cost in plain language and get the user's agreement first; never expose the confirmation parameter or ask the user to set it. Matching runs in the background, so this returns the search status, not the ranked lenders — retrieve those with get_lender_recommendations once ranking completes. Re-running for the same deal reuses a recent in-progress or completed match rather than charging again. confirm: leave unset to preview the cost; set only after the user has agreed in plain language to the credit charge.

recommend_lenders_for_deal

Add a metric value the deal doesn't have yet — record one or more user-supplied or sourced values. Use this to record a measured or extracted underwriting fact — NOI, occupancy, expenses, or source-reported valuation/purchase price — that the deal does not have yet, or to log an additional sourced observation for one it does. Discover the metric and its id with list_deal_index_metric_definitions. To change or correct a fact the deal already shows (e.g. 'fix the NOI to $1.25M'), don't use this tool — use search_deal_index to find it, then update_deal_index_fact, which sets the canonical value directly. Reach for this tool to add a value, not to edit one in place. Route by the catalog's suggested_write_via before recording here: index → this tool; deal_record → the named CRM tool (update_deal / update_company / update_contact), NOT this one; clarify (loan amount and deal financials are common cases) → ask whether the user is setting the deal's official value (CRM tool) or logging what a source reported (here). Don't guess. How recording behaves: think of the SOT as a fact slot keyed by metric_id + entity_ref (plus the year, for time-based metrics). This records an observation and can replace the slot's canonical value, including a previous user-entered value. A duplicate observation may be reused. Confirm the concrete change with the user first, then read back the fact to verify the displayed value. This does not create entities. To record a value for a property the deal doesn't have yet, add the property via update_deal (add_properties) first, then record against its entity_ref. values: a list of values to record, each an object with: metric_id: numeric id from list_deal_index_metric_definitions. value: the value to record, as text (e.g. 1250000, or 92%). entity_ref: optional. Target an existing entity, such as `property:702` or `sponsor_contact:55`, taken from the catalog or a search_deal_index result. Omit for deal-level facts; on a single-property deal Lev can infer it. group_ref: optional. Use only to group several values for the same entity when no entity_ref is available yet. period_type: "year", only with period_value, and only for metrics the catalog marks is_temporal; ignored on others, so several years of any other metric land in one slot. period_value: the 4-digit year the source states, e.g. 2024; if it doesn't say, ask. Each value is recorded independently: the response reports how many were recorded and surfaces any the backend rejected, so report the true outcome — never claim a value was saved if it appears under failed.

record_deal_facts

Where a deal's numbers come from and what its documents say — indexed facts, metrics, and their source documents. The tool for "what's the NOI / occupancy / DSCR", "where did this number come from", and the first step to correct a fact (find it here, then update_deal_index_fact). Broader than in-place NOI: loan terms, proceeds, LTV/LTC, DSCR, debt yield, occupancy, rent roll, revenue/expenses, valuation, capex, property facts, sponsor or borrower background, dates. For the deal's plain stored CRM fields (loan amount, sponsor, status, close date) use get_deal instead; for a written summary use summarize_deal. Finds facts the deal ALREADY has; to discover what metrics CAN be recorded, use list_deal_index_metric_definitions instead. sidebarNodeId on each result is the portal ?node=; the result already copies it to node when present. When sidebarNodeId is null, omit node — do not invent one. Prefer sidebarNodeId on the search hit. list_deal_index_taxonomy still returns the tree for callers that walk it. Do not conclude that source documents are unavailable just because get_deal does not list files — inspect this tool's source metadata first. To refresh cited slide values you already have ids for, pass sot_ids and skip context. That is an exact lookup for Check/Apply, not another semantic search. Do not re-embed. context: natural-language search phrase. Required when sot_ids is omitted. Be specific about the metric or topic you want. For broad discovery, use a context like: key underwriting facts, loan terms, property facts, financial metrics, sponsor, valuation, rent roll, occupancy, capex, and source documents. sot_ids: optional exact lookup. Prefixed ids from a prior search or from a citation URL sotId (d:123, a:17544:property:2561). The result id equals that URL sotId. Do not invent a context when you already have the ids. At least one of context or sot_ids is required. min_score: similarity threshold from 0 to 1. Defaults to 0.3; raise it for narrower matches, lower it only when recall matters more than precision. limit: maximum ranked facts to return. Defaults to 20 and is clamped by Lev to 1-200. Exact lookup is capped the same way. Set limit to the number of sot_ids (max 200) and batch any further ids into another call. Apply a citation only when its id is in the results. For broad fact-discovery (e.g. a complete editable picture), set min_score=0 and limit=200. This is high-recall, not exhaustive: Lev clamps at 200 per call (under the cap the result set is deterministic across differently-phrased contexts; over it, context-driven ranking picks which 200 you see). If ``total`` or ``has_more`` indicates more facts exist, treat the result as the top page, not the full inventory. High-recall responses can be large. For deeper inspection of one fact, follow up with list_deal_index_observations on its sot_id. include_signed_urls: default false. When true, document-backed source records may include short-lived signed attachment URLs; the response converts them into source.file_link Markdown hyperlinks (raw source.signed_url is omitted). Keep false when the user asks only what the source is (summarize file_name, pages, source.type, observation_count); set true only on links/downloads or open/inspect asks. Never show a bare signed URL in the final user answer; present only the file name as a hyperlink. If signing fails, source.file_link is absent and source.signed_url_error explains the typed reason. Results carry ranked metric/value fields, context and summary text, score, and source metadata (document id/type, file name, page range, observation count). source.type=user_input means user-entered data rather than an attachment; say no document-backed indexed facts were found when every relevant result is user_input. Each result also carries an editable hint (true / false / null) for whether update_deal_index_fact can change the fact. Hint only — the backend re-checks at update time and rejects non-editable facts with a clear message. Use it to decide whether to offer an edit, never as a security boundary. The ``sot_id`` field on each result is the fact identifier you pass back to list_deal_index_observations and update_deal_index_fact — internal, never surface it to the user. Scope of editable=false: the flag covers ONLY update_deal_index_fact — do NOT tell the user a fact is read-only based on it alone. Consider these alternative update paths before concluding anything is unsupported: - Deal-level fields (loan_amount, business_plan, transaction_type, loan_type, title, description, estimated_close_date, sponsor_private_company_id, purchase_price, estimated_value, total_cost, total_cost_basis, land_cost) → update_deal. - Sponsor profile facts → update_company on the linked company_id, resolved from deal.sponsor_private_company_id (get_deal returns it). - Broker profile facts → update_company on the broker's company. Resolve via list_contacts (filter by email, or first/last name from get_deal's team row — there is no generic name arg), then get_contact for the company_id if the summary lacks it. - Broker team / contact facts → update_contact. Resolve the contact_id the same list_contacts way; do not pass the team row's id or user_id directly to update_contact — those are different identifiers. - Property identity fields (address, city, state, zip) → update_deal property sub-ops (update_properties on the existing property_id, or add_properties) — a canonical CRM write path. A small set has no alternate standard CRM write path today: property-canonical fields without an update_deal sub-op (street, property type, legal description — still index-overridable via update_deal_index_fact when editable=true), sponsor financials, contact phone, and broker_profile Additional States. Reach that conclusion AFTER considering the alternatives. Before any write, confirm the concrete change with the user. Recording a fact the deal does NOT have yet (search returns nothing): use list_deal_index_metric_definitions to find the metric and its write path. Loan amount and deal financials are both-doors cases: official value → update_deal; source-reported value → the index. When intent is unclear, ask rather than guessing.

search_deal_index

Find a lender in Lev's directory by name — how you turn a name into a lender id. The home for look up Berkadia, what is Wells Fargo's lender id, or pull up that lender — any ask that names a lender instead of giving an id. Returns matching directory lenders with the id that get_lender and the placement tools take. Free and read-only. Whenever the user names a specific lender, come here rather than to recommend_lenders_for_deal — that one is a paid AI ranking for discovering which lenders suit a deal, and charges credits. Searches Lev's whole lender directory, not the companies in the user's own account. For the lenders and sponsors already in their book, or to filter by city or state, use list_companies. Returns the best matches, best first, with no paging. By default that is every match when fewer than 25 lenders match, otherwise only the top 20. If the lender you're after isn't listed, refine the name. name: matches partial names, case-insensitive. Required — the directory returns best matches for a name, not a browsable list. limit: how many matches to return, 1-25. Can only lower the count.

search_lenders

Show one deal visually — an interactive overview card of its headline terms, property, status, and key facts. Use when the user wants to see a deal: "show me the deal", "pull up deal X", "open the deal card / overview / dashboard". On MCP Apps hosts (Claude Desktop) this renders an inline card with the deal's headline (amount, loan type, transaction), property, pipeline stage, an Archived badge when the deal has been archived, key financials, deal team, and its indexed facts grouped by category with source-document tags. Other hosts get a compact text summary. Archiving is separate from pipeline stage, so an archived deal still shows its last stage. Use this ONLY for a visual look at one deal. For a written summary or narrative overview, use summarize_deal. For raw CRM fields, use get_deal. For one specific metric or where a number came from, use search_deal_index. Resolve a deal name to its deal_id with list_deals first.

show_deal

Show the per-document values our extractors pulled for a deal fact. Use when the user wants to know where a fact came from, see every value we extracted for it across documents (e.g. 'what NOIs do we have on file?', 'where did this loan amount come from?'), or pick among multiple extracted values during an edit. The user will describe the fact in plain English — they will not know its internal identifiers, and you should never ask for one. Resolve the right identifier from a prior search_deal_index result yourself. Prefer promoting an extracted value over a free-text override when the user is choosing among candidates — it preserves the source document, page range, and confidence score. Translate everything back to plain English when speaking to the user: never surface the word 'observation' or echo any internal identifier. Frame it as 'extracted values' or 'what we found in the documents'. sot_id: identifier carried by a prior search_deal_index result (e.g. d:5362, a:123:property:690). Preferred filter — returns only the extracted values tied to that specific fact. metric_id: numeric metric definition id. Use to fetch every extracted value for a metric across entities (broader than what the current canonical value picked). Combine with entity_ref to scope to a single property or group. entity_ref: optional entity scoping (e.g. property:690). Used alongside metric_id; ignored without one. limit: maximum results to return. Defaults to 20 and is clamped by Lev to 1-200. Most facts have only a handful of extracted values, so the default is usually plenty. offset: 0-based index of the first result to return. Defaults to 0 (first page). When the response has has_more=true, walk to the next page by passing the offset emitted in the response hint. Keep limit constant across pages; mixing limits mid-walk can skip or duplicate items. include_signed_urls: default false. When true, document-backed source records may include short-lived signed attachment URLs for inspection or download. The response converts returned signed URLs into source.file_link Markdown hyperlinks and omits raw source.signed_url. Keep false when the user asks only what the source is; set true only when the user asks to open or inspect the source document. Never show a bare signed URL in the final user answer; present only the file name as a hyperlink. At least one of sot_id or metric_id must be provided. Each result carries the extracted value, metric metadata, context and summary text, confidence, weight, and the same source metadata shape as search_deal_index. When the user is choosing among candidates to update a fact, pass the chosen result's ``observation_id`` back to update_deal_index_fact — silently, behind a plain-English confirmation. All identifiers here (sot_id, metric_id, entity_ref, observation_id) are internal — never surface to the user.

list_deal_index_observations

Write up one deal in prose: a narrative summary, briefing, memo, or shareable one-pager — including an overview to paste into an email. The tool for "tell me about deal X", "summarize this deal", "put together a memo / overview / write-up for an investment committee". Consolidates get_deal + search_deal_index + list_term_sheets + list_placements into one call and returns prose, at three detail levels. Use a sibling instead for: raw CRM fields (get_deal); a single metric or its source (search_deal_index); an interactive visual card (show_deal). detail: one of "brief" — 1-paragraph headline (~80 words) "standard" — ~200 words: title, property, financials, loan request, activity, open items (default) "memo" — ~600 words, lender-shareable 1-pager structure Every fact-derived quantitative claim cites its source via search_deal_index's source.file_name. Facts without a document-backed observation render as "(user input)". This tool's structuredContent intentionally omits term-sheet/placement lists so calls stay cheap. Resilient to partial backend failures: if term-sheet or placement data is unavailable, the summary still renders from deal + facts with a graceful degradation note. If the deal endpoint itself fails, returns a friendly error. Never fabricate URLs — only emit links present in structuredContent.urls.

summarize_deal