SpecterSystems.io

For non-merchant Specter broker/operator users only. Merchant applicant accounts must not use this tool. Creates a new lender-board/capital-source record in the authenticated user's Specter tenant after the user clearly asks to add the lender. Use for lender details extracted from chat, files, PDFs, or product guides. Do not pass tenant_id, user_id, API keys, portal credentials, bank account data, tax IDs, SSNs, or other secrets. Backend tenant scope, RBAC, duplicate-name checks, validation, and audit events remain authoritative.

create_capital_source

Creates the communication channel for an entity that does not have one yet. Use ONLY after get_communication_channel_for_entity returns channel: null — a lead or counterparty nobody has messaged has no channel, and send_channel_message requires a channel_id it cannot invent. Provide entity_type, entity_id, and a display_name (the business or person's name, which is what the thread is labelled with). Creating the channel does not message anyone: it opens the thread so a later send has somewhere to land. Tenant-scoped and RBAC-enforced; if a channel already exists, read it with get_communication_channel_for_entity instead of creating a second one.

create_communication_channel

Tenant-admin-only setup helper. Creates a deal/facility status definition in the authenticated tenant only. Use for admin setup assistance when a required deal status is missing.

create_fos_setup_deal_status

For non-merchant Specter broker/operator users only. Creates a new lead (prospect) in the authenticated user's Specter tenant. Use when the user explicitly asks to add or create a lead. Only 'name' is required; include contact and business details when the user provides them. This writes live CRM/FOS data.

create_lead

For non-merchant Specter broker/operator users only. Merchant applicant accounts must not use this tool; they are limited by backend enforcement to signed-form submission, public document upload, and merchant-portal/applicant-facing updates. Creates an authenticated lender submission for a specific facility/application. Use only when the user explicitly asks to submit or prepare a facility for a lender. This writes live submission pipeline data.

create_lender_submission

For non-merchant Specter broker/operator users only. Creates a new merchant / counterparty (business) in the authenticated user's Specter tenant. Use when the user asks to add a merchant or business. 'name' and 'type' are required; default 'type' to "business" for a company. Optional business contact and profile fields are only for populating the CRM record when the user provides them. Do not request tax IDs or other government identifiers in chat; enter those through the secure Specter portal. This writes a business record, not a login account, and does not grant merchant access.

create_merchant

For non-merchant Specter broker/operator users only. Creates a financing offer, optionally linked to a facility/deal or submission. Use when the user asks to add or record an offer. 'funded_amount' is required; link it with facility_id when known. This writes live CRM/FOS data.

create_offer

For non-merchant Specter broker/operator users only. Creates a task attached to a CRM record (lead, merchant, deal, or submission). Use when the user asks to add a task, follow-up, or to-do. 'entity_type', 'entity_id', 'task_type', and 'title' are required; use task_type "custom" for a general task. This writes live CRM/FOS data.

create_task

Creates a new Workflow V3 draft for the authenticated tenant. Use only after the user asks to create a workflow and the graph has been validated or intentionally saved as an incomplete draft. This operation only persists workflow configuration; it does not dispatch the configured node actions or register new model-callable tools. The MCP server forces is_draft=true; publish_workflow is required before the draft runs live automation.

create_workflow_draft

Tenant-admin-only setup helper. Creates a manual group for Deals, Leads, or Merchants in the authenticated tenant only. Use for admin setup assistance when a required board/list group is missing. Never invent cross-tenant IDs and do not use inside Workflow Builder automation design.

create_fos_setup_group

For non-merchant Specter broker/operator users only. ONE-CALL decline: transitions the facility to outcome, optionally sets the tenant declined status slug, sends a merchant-facing decline message (skipped when no message body is given), and records an internal note with the decline reason — with per-step results. PREFER THIS over separate transition + update_facility + send_channel_message + add_note calls when the user asks to decline or kill a deal. Steps stop on the first failure.

decline_and_notify

Writes a proposed reply to a conversation and stores it for a human to review. It does NOT send anything: the draft waits until a person approves it. Use this whenever you want to suggest a response — for example after an inbound reply to an outreach message. Read the thread first with list_conversation_messages so the draft answers what was actually said. A conversation can hold only one pending draft; if one already exists this returns a conflict.

create_message_draft

Files a platform support ticket as the authenticated user — the same reporter-side ticket system as the in-app "report a problem" flow. USE THIS whenever the platform itself misbehaves during a conversation: an endpoint returns wrong or oversized data, a filter is ignored, a tool result truncates so a task cannot be completed, or the user reports something broken. Include what was attempted, the exact call that misbehaved, and what came back wrong in the body. The ticket lands with the Specter system admins; identity (tenant, reporter) is stamped server-side. Tell the user the ticket reference from the response. This creates a record but sends nothing to any customer.

file_support_ticket

For non-merchant Specter broker/operator users only. The signed-in user's OPEN windows — their working hours in their own time zone minus what their calendar (Google or Outlook) already holds — for a day or a span of days. Answers "when am I free tomorrow?", "find me 45 minutes with the merchant this week", and is what to call BEFORE proposing a meeting time (propose_meeting) so the time is one the person can take. Give day (today / tomorrow / a weekday name / YYYY-MM-DD) and optionally days=N (up to 14), duration (minutes; default: their default meeting length) and limit. Each slot is a start, an end and its length; the answer also carries the working day it was cut from. When connected is false, repeat the reason to the user verbatim. Read-only.

find_my_free_slots

For non-merchant Specter broker/operator users only. Merchant applicant accounts must not use this tool; they are limited by backend enforcement to signed-form submission, public document upload, and merchant-portal/applicant-facing updates. Gets one authenticated facility/application by ID, including currently available related entities and pipeline status. For entity-specific questions about one known facility/application, call this first with the known facility_id instead of doing a broad search. Use before submission-list tools when the user asks for that facility's status, approval posture, offers, lender outcomes, or history. Requires account authorization and does not mutate data.

get_application_details

Reads timeline/history for a facility/application visible to the authenticated user, including related activity/events the backend exposes. Use when the user asks what happened on an application or wants recent changes. It is read-only.

get_application_history

Gets one bank statement visible to the authenticated user. Use when the user asks for statement details, analysis, linked facility, risk signals, or included periods. It is read-only.

get_bank_statement

Reads timeline/history for a bank statement visible to the authenticated user. Use when the user asks how a statement or its analysis changed. It is read-only.

get_bank_statement_history

Gets one bank statement period visible to the authenticated user. Use for period-level revenue, balances, NSF, DSR, fraud, and MCA-position analysis. It is read-only.

get_bank_statement_period

Gets one business research record by its own ID. Prefer get_facility_business_research when you have an application or facility; use this only when you already hold a research record ID. It is read-only.

get_business_research

Gets the stored business research for one application/facility: owner name, registration state, initial filing date, Secretary of State active status and good standing, court records and legal actions (business and owner), research notes, source URLs, and AI-synthesized risk signals. Use for '/research', 'what do we know about this business', 'is this business legitimate', 'any liens or court records'. Reads stored research only — it does not run a new search. It is read-only.

get_facility_business_research

Gets one stored credit report, optionally with its tradelines in the same call. Use when the user asks about a specific credit pull, its scores, or the individual tradelines behind it. Reads a stored pull only — it does not order a new one. It is read-only.

get_credit_report

Lists the stored credit reports for one application/facility. Use when the user asks about credit, scores, or the owner's credit profile on a deal. Reads stored pulls only — it does not order a new credit report. It is read-only.

get_facility_credit_reports

For non-merchant Specter broker/operator users only. Reads one email blast in full: what was sent, to how many, and how each recipient landed. Read-only.

get_email_blast

Gets the communication channel for a specific entity visible to the authenticated user. Use before reading or sending messages tied to a facility, submission, lead, counterparty, or lender. A successful result exposes channel.id/channel_id in the model-visible response; pass that exact value to send_channel_message. If channel is null, no channel exists yet — open one with create_communication_channel and use the id it returns; do not guess REST paths. It is read-only.

get_communication_channel_for_entity

ONE-CALL deep briefing for a single facility/application: everything in get_underwriting_packet (enriched deal, submissions, offers, bank statements, timeline) PLUS statement periods, tax years, the offer comparison, and a communications snapshot (latest channel + recent messages). PREFER THIS over get_underwriting_packet followed by separate period/tax/offer/comms reads when preparing a full underwrite or /analyze. Read-only. Sections may carry a section_errors entry instead of failing the whole workup.

get_full_workup

For non-merchant Specter broker/operator users only. Returns one lead's full record — contact details, business information, status and tags. The free-text notes field is NOT shown to you, and no tool reads a lead's notes back — never claim to have read them or to know what they say. Use this after search_records has resolved a name to an id, and ALWAYS before update_lead or set_lead_status: those change a live record, and this is how you see the current values so you do not overwrite something a person entered. It is read-only.

get_lead

Gets one lender submission visible to the authenticated user. Use when the user asks for lender submission details, current status, requested terms, offered terms, approved terms, or lender response context. It is read-only and tenant/user scope is enforced by the backend.

get_lender_submission

Returns the merchant application link and signed form ID for ChatGPT applicants. Use this first when a new merchant wants to apply through the Specter Systems ChatGPT app. This does not require an account and does not submit data. Do not describe internal workspace routing or tenant configuration.

get_chatgpt_merchant_application_link

For non-merchant Specter broker/operator users only. Which calendar the signed-in user's meetings and follow-ups land on: their preference (auto | google | outlook), what it resolves to right now, and whether Google Calendar and their Outlook mailbox are connected — outlook.needs_reconnect means the mailbox was connected before calendar access was part of the grant. Use it to explain why a calendar read or booking was refused, and to tell the user which setting to change (Settings → Calendar; Outlook connects under Settings → Integrations → Outlook). Read-only; the preferences are changed by the user on the page, not through this tool.

get_my_calendar_settings

For non-merchant Specter broker/operator users only. The signed-in user's DAY in one read: the meetings still ahead, tasks due today, anything overdue, leads whose follow-up date is today, how many Heartbeat actions are waiting, and the open windows left to book into — with a one-sentence summary. This is what /digest should answer from: one call, instead of stitching together list_tasks, list_leads and list_heartbeat_actions. Pass day (today / tomorrow / a weekday name / YYYY-MM-DD, in the user's own time zone) to brief a different day; default today. When calendar_connected is false, repeat calendar_reason to the user verbatim — the rest of the brief is still real. Read-only.

get_my_daily_brief

Reads the authenticated user profile and safe active account context. Use this first to identify whether the connected user is a merchant applicant or a regular Specter broker/operator user. Do not expose tenant configuration, processing flags, access policy, internal permissions, tokens, backend URLs, or operational setup details.

get_my_specter_profile

For non-merchant Specter broker/operator users only. Gets one offer by ID: full terms, fees, commission, counter values, conditions, and the presented/accepted/declined/expired timestamps. Use after list_offers or compare_application_offers has identified which offer matters. Read-only.

get_offer

ONE-CALL pipeline briefing scoped to the authenticated user's data access: deal counts per lifecycle stage, SLA-at-risk deals, closing-soon deals (decision/funding), and stalled deals with no stage movement in stale_days days. Lists are capped (top 10 per bucket) — it is a briefing, not a report. PREFER THIS over multiple search_records calls when the user asks how the pipeline looks, what needs attention today, or for a digest. Read-only.

get_pipeline_snapshot

For non-merchant Specter broker/operator users only. Reads ONE Heartbeat action in full — its payload (for a meeting: title, start, end, and the complete guest list with each guest's email), its status, and its acceptance preview. Use this to answer questions about a specific proposed action, such as who is invited to a meeting or what a field change would set, before or after accepting it. This operation only reads one stored proposal record; it never executes its payload or registers additional tools.

get_heartbeat_action

Fetches the public signed merchant intake form. Use for merchant applicants and public signed-form flows. For ChatGPT merchant applicants, call get_chatgpt_merchant_application_link first and use its signed_id. Use returned schema only to collect non-sensitive business and contact answers; government identifiers and credentials must be entered directly in the secure web form, never in chat; do not display backend configuration, bank-login configuration, internal routing, tenant setup, or operational settings to the merchant.

get_public_application_form

For non-merchant Specter broker/operator users only. Reads who is currently assigned to one record, across every role, with each assignee's name and email resolved. Call this BEFORE set_assignments_for_entity: that tool REPLACES a role's whole assignee list, so adding a person means sending the existing ones back alongside them, and this is where you read them. Read-only.

get_assignments_for_entity

For non-merchant Specter broker/operator users only. Reads one SMS blast in full: what was sent, to how many, and how each recipient landed. Use to answer "how did that blast do" before deciding whether to retarget it. Read-only.

get_sms_blast

Reports which phone numbers the authenticated user may send SMS from. Use before sending SMS through MCP: send_channel_message and send_conversation_message accept sender_phone, and the backend rejects a number the user has no access to. This returns an ACCESS MAP, not a complete list of numbers — read it as an exclusion list. blocked_numbers are the numbers this user may NOT send from (assigned to another user, or a Zoom line with no assignee). allowed_numbers are numbers explicitly assigned to this user. A number restricted to nobody in particular is unrestricted and appears in NEITHER list, and when is_admin is true both lists come back empty because the whole tenant pool is available. So an empty allowed_numbers never means the user cannot send — do not refuse on that basis. To name a specific number, take one from allowed_numbers; otherwise send without sender_phone and let the backend choose, and only warn the user if the number you intended appears in blocked_numbers. It is read-only.

get_sms_sender_access

Reads timeline/history for a lender submission visible to the authenticated user. Use when the user asks for submission history, status changes, lender events, or related activity. It is read-only.

get_submission_history