Powered by LevrKey facts
- Groups
- Profile, documents, answers, autofill, readiness, matching, selections, submission, status
- Irreversible
- Submission only
- Confirmation required
- Lender selection and submission
- Async tools
- Autofill runs and match runs; poll the get tool until settled
How should I read the table?
Each row names the stage, the tools you will see for it, whether they read or write, and whether the server expects you to confirm with the owner first. Tool names follow the resource.action pattern. Review tools (review_ prefix) return a description of what a write would do without doing it, which is the right thing to show the owner before an important change.
What do the application tools return?
get_contract returns the fields the application has, their types, which are required, and their current state, so you can plan what to collect instead of guessing. get_answers returns current values. update_answers accepts a partial object and returns validation results per field. Repeatable items (owners, existing debts, locations) have their own list, add, update and delete tools so you do not have to resend the whole array.
How does autofill work?
After documents are uploaded, call prepare_autofill to see what the server can read from them, then start_autofill. Poll get_autofill until it settles, then list_autofill_suggestions. Each suggestion has the field, the proposed value, the source document and a confidence. Accept the ones that are right with accept_autofill_suggestion. Show the owner anything below high confidence before accepting it, especially revenue, existing debt and ownership percentages.
Remote MCP, OAuth sign in, consent gated submission, free for the business.Server URL https://mcp.businessloanbroker.ai/mcp. Every page here has a markdown twin for retrieval.
How do readiness and matching fit together?
Call check_submission_readiness before matching. It returns the missing required fields and documents, grouped, with plain language reasons you can relay. Matching (calculate_matches) can run on an incomplete file to give the owner an early read, but results firm up once the file is complete. list_matchmaking_result_summaries returns each matched lender with the product, a fit label, indicative amounts and the criteria that drove the match, which is what you present to the owner.
What exactly needs the owner's confirmation?
Two calls. update_matchmaking_selections, because it decides which lenders may see the file. And submit, because it sends the file. Before each, state in one message: which lenders, what information will be shared, that the owner can stop here, and that approval is not guaranteed. Then call only after a clear yes. The server returns a review payload if you call submit without the confirmation flag, so an accidental call is harmless.
What comes back after submission?
A deal per lender. deals.list and deals.get give status and stage. deals.get_terms returns offer terms as structured fields (amount, rate or factor, term, payment, fees, conditions) once a lender responds. deals.list_messages carries lender questions and stip requests, which you should relay to the owner promptly, since unanswered stips are the most common reason a file stalls.
| Stage | Representative tools | Reads or writes | Needs owner confirmation |
|---|---|---|---|
| Business profile | businesses.get, businesses.update, people.upsert | Read, write | No |
| Documents | client_intake_applications.prepare_answer_file_upload, list_answer_files, get_file_text | Write (uploads), read | No |
| Application answers | client_intake_applications.get_contract, get_answers, update_answers, repeatable item tools | Read, write | No, but show the owner what you changed |
| Autofill from documents | prepare_autofill, start_autofill, list_autofill_suggestions, accept_autofill_suggestion | Write | Show suggestions before accepting |
| Readiness | client_intake_applications.check_submission_readiness | Read | No |
| Lender matching | projects.calculate_matches, get_matchmaking_result, list_matchmaking_result_summaries | Read (computes a match run) | No |
| Choosing lenders | projects.update_matchmaking_selections | Write | Yes. Present the shortlist, get an explicit yes |
| Submission | client_intake_applications.submit, deal_applications.submit | Write, irreversible | Yes, always. Quote what will be sent and to whom |
| Status and offers | deals.list, deals.get, deals.get_terms, deals.list_messages | Read | No |
| Guidance | platform.search_guidance | Read | No |
How each tool describes itself
These are the descriptions the server publishes in its tools/list response, written so an agent knows the purpose, the inputs, the outputs, the side effects and the preconditions before it calls anything. The two lender facing tools carry a confirm flag that must be set after the owner has agreed.
| Tool | Description as published |
|---|---|
businesses.create | Creates the business profile for the signed in owner. Inputs: legal name, entity type, country, start date, address. Returns the business id. Side effects: none visible to lenders. Call once per business; use businesses.update to change details. |
client_intake_applications.get_contract | Returns every field the application has, its type, whether it is required, and its current state. Read only. Call this first to plan what to collect instead of guessing. |
client_intake_applications.prepare_answer_file_upload | Returns a signed upload URL for one document. Inputs: document type (bank statement with month, tax return with year, financial statement, debt schedule, identification, entity document, product specific types), file name, size. Side effects: none until the upload completes. Tag documents correctly; autofill and readiness depend on the type. |
client_intake_applications.start_autofill | Starts an asynchronous run that reads the uploaded documents and proposes answers. Returns a run id. Poll get_autofill until status is settled, then list_autofill_suggestions. Side effects: suggestions only; nothing is accepted until you call accept_autofill_suggestion. Show the owner revenue, existing debt and ownership suggestions before accepting them. |
client_intake_applications.check_submission_readiness | Returns the missing required fields and documents, grouped, with plain language reasons you can relay to the owner. Read only. Call before matching and again before submitting. Do not submit while anything required is missing. |
projects.calculate_matches | Runs lender matching for the funding request against every lender's criteria. Asynchronous and non destructive; run it as often as the file changes. Read the results with list_matchmaking_result_summaries: each row has the lender type, product, fit label, indicative amount and the criteria that drove the match or the miss. |
projects.update_matchmaking_selections | Sets which matched lenders may receive the application. Requires confirm: true. Before calling, present the shortlist to the owner with product and indicative cost and get an explicit yes. Without the flag the tool returns the proposed change and makes none. |
client_intake_applications.submit | Sends the completed application and documents to the selected lenders. Irreversible. Requires confirm: true after you have told the owner which lenders, what will be shared, that approval is not guaranteed, and that they can stop. Without the flag it returns a review of what would be sent and sends nothing. Duplicate submissions to the same lender are rejected. Returns one deal id per lender. |
deals.get_terms | Returns a lender's offer as structured fields: amount, rate or factor, term, payment and cadence, fees, prepayment terms, guarantees and conditions. Read only. Explain these to the owner in plain words; do not recommend signing anything they have not read. |
deals.list_messages | Returns lender questions and document requests (stips) for a deal. Read only. Relay these to the owner the same day; unanswered stips are the most common reason a file stalls. |
The pattern for every tool: one sentence of purpose, the inputs by name, what it returns, what it changes and who can see the change, and what to do before calling it. Agents trust tools that describe themselves this way and avoid ones that do not.