Vertalo MCP Server

Model Context Protocol · Vertalo Platform

A curated interface to the Vertalo Platform

api.vertalo.com is where the Vertalo GraphQL API is introduced — an onboarding primer, not an exhaustive treatment of the schema. The schema underneath is the real surface: every asset-management and RWA tokenization type, field, and edge case a platform team could touch. Most integrations only need a fraction of it. The Vertalo MCP Server distills that surface down to the queries and mutations issuers, custodians, and trading platforms actually use, and exposes them as tools any MCP client can call directly — no schema archaeology, no hand-rolled GraphQL.

50+
curated operations
30+
read queries
20+
write mutations
10+
object domains

Why an MCP layer

The same platform, a much shorter path to it

01

Curated, not comprehensive

Every operation here maps to something issuers, custodians, and trading platforms actually do day to day — onboard an investor, open a round, issue a distribution, mint a token. The rest of the schema stays out of your way.

02

Built for agents

Each tool ships with a plain-language description, its associated reference lookups, and notes on how it behaves — the context an MCP client (or the person prompting it) needs to use it correctly on the first try.

03

No new platform underneath

This isn't a parallel API. It's a Streamable HTTP front door onto the same GraphQL backend behind api.vertalo.com, so behavior, permissions, and data are identical to calling the API directly.

Connecting

Four calls between you and a live tool call

Access is machine-to-machine, and you provision your own application stack. Vertalo issues credentials and serves the MCP endpoint; you build, host, and run the backend service that holds those credentials, exchanges them for access tokens, and calls the server. That backend authenticates as an application, not a person, and trades its identity for scoped, short-lived tool access — allowing you to create an end-to-end user experience that precisely fits your needs and branding, with Vertalo running underneath it rather than in front of your users.

Authenticate

Basic Auth

Present your issued client ID and secret as Basic Auth credentials to the Access Token endpoint. You get back a bearer access token scoped to vrt/api/api.mcp. Tokens expire after 15 minutes — regenerate on any HTTP 401.

Discover accounts

Bearer token

Present the access token to the Account Discovery endpoint. It returns the accounts and roles your credentials are delegated to — a client can be authorized against more than one.

Select an account

X-Vertalo-Users-Account-Id

Pick one account by its users_accounts_id and send it as a header on every subsequent call. This is what scopes each operation to a specific issuer, custodian, or trading-platform account.

Call operations

Streamable HTTP

Point any MCP client at the server endpoint and call the curated tools directly by name — list_assets, setup_customer, mint_security_tokens, and the rest of the catalog below.

These are application credentials, not user credentials. They authenticate your backend, not an individual — never embed them in browser code or a mobile binary. Keep the client ID and secret in a secrets manager, confine the token exchange to a service you control, and mint access tokens on demand rather than persisting them. Your application still owns user authentication and authorization at its own layer.

Data model

One hierarchy runs through most of the catalog

An asset is the top-level object everything else flows from, and an investor is the other half of the equation. Map your own use case onto this chain and most of the catalog below reads itself.

Basic scaffolding
asset
round
allocation
Investor onboarding and issuance
investor
distribution/subscription
funding
holding
Transfer Agency
trade/transfer
redemption
clawback
off round

security

A 1:1 companion to each round — created alongside it, tracked separately for unit value and holdings.

alternate to round

tranche

The same shape as a round, extended with coupon and term — for debt instruments rather than equity rounds.

Tokenization runs as a parallel track off the security, once holdings exist to mint:

Blockchain Synchronization
token deployment
minting
movement
governance

token deployment

A contract is prepared, then deployed to the target chain — once per security. Consult Vertalo before either step; skipping that consultation will fail.

minting

Every holding is minted individually, to its own on-chain account.

movement

Minted tokens move between on-chain accounts as holdings change hands — the on-chain side of the trade/transfer, redemption, and clawback events above.

governance

Ongoing contract control after minting: key rotation, account freezes, and pausing the contract.

Reference

The operations catalog

Update mutations take a partial patch. updateAsset, updateRound, updateSecurity, updateTranche, and updateDistribution each accept an object with only the fields you're changing — a null or blank value erases that field, so omit anything you don't intend to touch.

No operations match that filter.