Documentation

The MCP endpoint is https://mcp.mcf.fund/mcp. It speaks streamable HTTP and is stateless, so it works with hosted clients such as Claude and ChatGPT as well as local ones such as Cursor.

Authorization is OAuth 2.1: a client discovers the authorization server from /.well-known/oauth-protected-resource, registers itself, and takes the user through a PKCE authorization code flow. Nobody pastes an API key into a client, and access can be revoked centrally.

Every request we make to your FactorSoft host leaves from a single static IP address, so you can restrict access at your firewall instead of exposing the API broadly. The current address is shown on your connection page and will not change without notice.

We only ever call your host in response to a tool call from someone holding a seat in your workspace. There is no background crawling and we keep no copy of your FactorSoft data.

The FactorSoft API exposes over a hundred operations. Presenting all of them as individual tools would make a model worse at choosing between them, so they are collapsed into a focused set:

• Purpose-built tools for the things people actually ask about: clients, debtors, invoices, payments, transactions, advances, relationships, credit requests and collection notes.
• fs_lookup folds every reference table behind one tool with a kind argument.
• fs_get_sync_token and fs_get_deltas cover incremental sync for each entity.
• fs_describe_api and fs_request reach the long tail: search the operation catalogue, then call an endpoint directly.
• fs_ping proves the connection works.

Read tools return a curated field projection by default, and accept a fields argument for more (or ["*"] for everything). Lists return 25 records at a time with a nextOffset to page with. Both defaults exist because tool results are paid for by the token.

These FactorSoft feature areas are reachable, either through a purpose-built tool or through fs_request:

• Advances
• Brokers
• CalcClient
• CarrierPayments
• Carriers
• CarrierTerms
• Clients
• CollectionNotes
• CreditRequests
• Debtors
• FundingAmounts
• ImportHistory
• InvoiceDisputes
• Invoices
• Lookups
• MiscDataElements
• Payments
• PmtChecks
• Relationships
• SecurityRoles
• System
• Transactions
• Uploads
• VendorDelivery

Two things are deliberately out of scope. Document and image uploads are multipart file transfers that suit an HTTP integration rather than a tool call. Purchase batch posting is reachable only through fs_request, because posting a batch moves real money and should take deliberate intent rather than a plausible-looking tool name.

Workspaces are read-only by default, and mutating tools are not registered at all until an administrator enables them. That is stronger than a permission check: a model cannot be talked into using a tool it was never shown.

With writes enabled, a client can create credit requests, add collection and dispute notes, and update notice-of-assignment and credit-insurance details. Each of those tools is annotated so clients know to confirm before calling, and each invocation is recorded in the workspace audit log.

Each plan includes a pooled monthly allowance of tool calls. Connecting and listing tools never count, so a client can always establish a connection and see what it can do.

When something is wrong, the endpoint says so through the protocol rather than failing the connection: an exhausted quota, a missing seat, a lapsed subscription or an unverified FactorSoft connection all come back as a tool error a model can read aloud to you.

FactorSoft secrets are encrypted with a per-record data key that is itself wrapped by a Cloud KMS key, so the plaintext never leaves the process that needs it. Secrets are write-only in the dashboard: once saved they are never displayed or returned by any API or tool, and they are excluded from logs by name.

Credential creation, rotation and deletion, seat changes and every write-tool invocation are recorded in an audit log scoped to your workspace.