Finero runs a Model Context Protocol server, so an AI assistant can read a Finero workspace and act inside it without anyone pasting a key into a chat window.
It is a different thing from the HTTP API rather than a wrapper around it. A session authenticates as the person who approved it, exposes a smaller, read-mostly capability set, and can be revoked for one person without touching anyone else. If you are writing software rather than connecting an assistant, the HTTP API is the right surface.
Canonical location
api.getfinero.com/functions/v1/mcp
Streamable HTTP transport, OAuth 2.1 authorisation. The short path redirects with a 307, which preserves the POST method and body that JSON-RPC requires. Also resolvable by name from the MCP Registry, below.
Connecting an assistant
Two steps, and the first is easy to miss because most MCP servers do not need it: an administrator creates the client inside Finero, and only then does the browser flow have anything to run.
- In Finero. An administrator opens Settings, then API & agents, and chooses “Connect an agent”. They are shown a server URL, a client ID and a client secret. The secret is displayed once and Finero does not store it.
- In the assistant. Add the endpoint as a custom connector and put the ID and secret in its advanced settings. In Claude that is Settings, then Connectors, then Add custom connector.
Skipping the first step is the one way this fails confusingly: the handshake succeeds, the tool list appears, and the connection then stops at authorisation rather than at connection. From here the rest needs nothing but a browser:
- The client calls the endpoint and is refused with 401. The refusal names the authorisation metadata rather than just saying no.
- The client follows that to the protected-resource metadata, finds the authorization server, and starts an OAuth 2.1 flow.
- You approve the connection in a browser, on a consent screen naming what the assistant will be able to reach. The client then holds a session bound to you personally, not to the workspace: what it can do is what you can do.
Finero does not offer dynamic client registration, and that is a decision rather than an omission. An anonymous registration endpoint would let anyone choose the client name and redirect URI that Finero’s own consent screen displays — a client calling itself something official, pointing anywhere — and it would make revoking a client meaningless, since another is one request away. The MCP specification anticipates exactly this and allows a client to be registered by hand. The cost is one paste, once, by someone who already administers the workspace.
The full chain, including what each document contains, is on Finero API authentication.
One header matters. Requests carry MCP-Protocol-Version. An unsupported value is refused with a body listing the versions the server does accept, so a client pinned to an older revision fails loudly rather than behaving oddly, and learns the right value from the refusal itself. That list is generated by the server, which is why it is not repeated here. Most MCP clients set the header for you.
Finding the server without a URL
The endpoint above is the direct route, and it works. There is a second one worth knowing about: Finero is published to the official MCP Registry as com.getfinero/finero. A client that understands the registry can resolve the server from that name alone, with nobody pasting a URL anywhere.
The listing is backed by a manifest the server generates, which declares the transport and entry point. Read the transport details from the manifest rather than from this page: it is produced by the server, so it stays right when the deployment moves, and a copy here would not.
What a session can reach
Read-mostly, and deliberately narrower than the HTTP API. An assistant can look at receivables state, invoices, payments and payment links, inspect how an ERP or payment integration is behaving, and start a sync. It is not a route to bulk mutation.
Payment links are where a session can write, so the constraints are worth stating plainly. Creating a link and deactivating one both require an admin credential: a read-only session can list and read links but not change them. When it creates one, the assistant names an installment rather than choosing a customer or proposing a figure, and the amount is bounded by what is actually outstanding on that installment. A confused model can raise a link for money already owed. It cannot invent a charge.
The reason is the caller. The HTTP API is used by software you wrote, reviewed and tested. An MCP session is driven by a language model interpreting a person's request, and the appropriate surface for that is smaller.
Where the granularity lives is worth being precise about, because it is easy to assume wrongly. It is the consent screen, not OAuth scopes. The authorization server accepts the standard OpenID set, so the protected-resource metadata advertises scopes_supported: ["openid"] and nothing product-specific. What a session may actually reach is decided by what the person approved when they connected it, and asking for a Finero-shaped scope string is refused rather than honoured.
Security worth thinking about before you connect it
A session carries the authority of whoever approved it. Approving Finero inside an assistant that other people can prompt effectively lends them that person's access for as long as the session lives. That is not a flaw in MCP, it is what delegated access means, but it is worth deciding deliberately rather than discovering. The upside of the OAuth model is the other half of the same property: revoking one person changes nothing for anyone else, where a shared API key would have to be rotated everywhere.