Finero MCP server

Connecting an assistant

One prerequisite, and it is easy to miss because most MCP servers do not have one: an administrator has to open the workspace to agents at all. After that the flow is ordinary, and there is no credential to obtain.

• In Finero, once. An administrator opens Settings, then API & agents, and switches agent connections on. It is off by default, and while it is off nothing binds to the workspace, an administrator included. Nothing is created and nothing is handed out.
• In the assistant. Add the endpoint as a custom connector. In Claude that is Settings, then Connectors, then Add custom connector. There is no client ID or secret field to fill in: the client registers itself.

Leaving the switch off 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 supports dynamic client registration (RFC 7591). It did not until 4 September 2026, and the reversal is worth explaining, because the original objection was sound and has not gone away. An anonymous registration endpoint means the client name shown on Finero’s own consent screen is a string the registrant chose: someone registers “Finero Official Sync” and sends a customer a link.

What changed is the recognition that hand registration answered that at the cost of a model that never matched reality. Mainstream MCP clients, Claude included, register a new client for every installation, so “an administrator registers the agent once and the team reuses it” was never going to describe real use; it meant minting a secret per person. The boundary moved instead of disappearing: one workspace switch, off by default, and the binding is created at consent rather than in advance.

So judge a request by the redirect host, which is where the authorization server will send the browser with the code and which a registrant cannot fake. The consent screen shows the client name too, labelled unverified, because it is only the client’s claim about itself. Both are recorded on the connection for an administrator to review later, and revoking one deletes that client at the authorization server: a re-registration is a new client needing a new approval.

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, and the scheduling of the workspace’s own payment-link email, are where a session can write, so the constraints are worth stating plainly. All four writes require the person who approved the connection to be an administrator: a session belonging to a member can list and read but not change. When it creates a link, 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, and it cannot write a word of the email that carries it.

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.