Capabilities
Tools, resources, prompts, and when to use each one
Both MCP endpoints expose eleven tools, resources, and one prompt. The directory
endpoint https://mcp.vrplatform.app/directory restricts API tools to reviewed
accounting operations. The custom endpoint https://mcp.vrplatform.app/
provides full API access.
Tools
Tools are prefixed vrt_ (VRT is the current VRPlatform product generation).
| Tool | Use | Endpoint |
|---|---|---|
vrt_server_status | Check server status, upstreams, and auth state. | Both |
vrt_product_help_search | Search product docs by literal text. | Both |
vrt_team_lookup | Find accessible teams by name across all data regions. | Both |
vrt_listings_lookup | Read a page of listings. | Both |
vrt_reservations_lookup | Read a page of reservations. | Both |
vrt_transactions_lookup | Read a page of transactions. | Both |
vrt_accounts_lookup | Read a page of accounts. | Both |
vrt_statements_lookup | Read a page of owner statements. | Both |
vrt_journal_entries_lookup | Read a page of journal entries. | Both |
vrt_api_read | Run freeform GET requests against the API. | Both; directory routes below |
vrt_api_mutation | Run confirmed POST, PATCH, PUT, or DELETE. | Both; directory routes below |
The six accounting lookup tools return up to 25 records per page (10 by default).
Team lookup returns up to 100 teams per page. Pass page to continue reading.
Statement lookup requires a month, year, date range, or statement IDs.
Directory API Operations
vrt_api_read and vrt_api_mutation accept only these method and path pairs on
/directory. Replace each {id} with its record UUID.
| Paths | Methods |
|---|---|
/me/teams, /partner/teams | GET |
/listings, /contacts, /accounts, /reservations, /transactions, /statements | GET, POST |
/listings/{id}, /contacts/{id}, /accounts/{id}, /reservations/{id}, /transactions/{id}, /statements/{id} | GET, PUT, DELETE |
/accounts/categories, /statements/by-period, /reports/journal-entries | GET |
/reservations/{id}/adjustments | POST |
/reservations/{id}/adjustments/{id} | PUT, DELETE |
/transactions/{id}/lines/{id} | PUT |
Use the API resources below for each route's input schema. Directory calls accept
these routes' documented top-level fields and query filters, with payment.lock
excluded because the API derives accounting locks. Nested payment accepts only
status, date, and bankRecordIds; banking accepts only category, type,
last4, and currency; emailDelivery accepts only message and immediate.
dryRun and onLocked work only where the API documents them. New fields and
routes require review before directory clients can use them.
Pass query parameters in query, never in path. Paths must use canonical
spelling without encoding, dot segments, fragments, extra slashes, or full URLs.
The API tools reject upstream redirects. No URL parameter, header, or tool argument
expands the directory scope.
Every mutation requires confirm=true after the user requests that change, plus a
team and the API's required permissions. Existing accounting locks and validation
still apply. Deletes are destructive. Directory writes can record transfers,
payouts, and prior payments, reconcile bank records, correct reservation/transaction
lines, and prepare or publish owner statements. They cannot dispatch funds.
payoutAccountId on a contact selects an accounting account; bank-account metadata
does not link a payment provider or change credentials.
Owner creation with invite=true sends an invitation. Publishing with
emailDelivery sends statement notifications. Use those fields only when the user
explicitly requests those messages. Existing configured integrations can receive
reference-data updates and resource webhooks from ordinary record changes.
Payment execution, provider retry/recovery/cancellation, bank credential management,
batch/operations routes, integration callbacks, and exports are unavailable through
/directory. PATCH and all unlisted method/path pairs are rejected.
Use vrt_product_help_search for product and operational guidance, not API
schema discovery. It is literal text search and rejects API-shape queries.
vrt_team_lookup uses the global user team catalog for OAuth and the global
Partner team catalog for API tokens. Once lookup returns a team id, pass that
id as teamId on team-scoped reads and mutations; the API gateway resolves the
team's placement.
Resources
| Resource | Use |
|---|---|
vrplatform://service/info | Server metadata and authentication summary. |
vrplatform://api/openapi-context | Compact API path and method catalog. |
vrplatform://api/path/%2Freservations | Path details for /reservations. |
vrplatform://api/path/%2Freservations/GET | Method parameters and response shape. |
Use OpenAPI resources for endpoint, parameter, schema, and response-field questions. These resources describe the full API; directory clients can execute only the reviewed operations listed above. API documentation is also available at /api.
Path resources use URL-encoded paths. For example:
vrplatform://api/path/%2Fstatements
vrplatform://api/path/%2Fstatements/GETPrompts
| Prompt | Use |
|---|---|
vrt-trust-accounting-help | Starter prompt for accounting questions. |
Example Prompts
Use VRT MCP to find the team named Example PM and show its listings.Read vrplatform://api/openapi-context, then inspect the GET shape for /reservations.
Summarize the available query filters.Using the configured team scope, call vrt_server_status and explain whether API
access is configured.