Capabilities

Both MCP endpoints expose twelve tools, resources, and two prompts. 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, including the G/L monitoring operator namespace.

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
vrt_report_feedback	Report a bug, an unclear error, a documentation gap or a question to VRPlatform support.	Both

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.

vrt_report_feedback sends one report through POST /feedback. The model uses it when something is unclear, an error does not explain the fix, the docs contradict the API, or a call looks like a bug. It then tells the user the report was filed and gives the returned id. The user does not need to open a support case.

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
/feedback	POST
/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/GET

Prompts

Prompt	Use
vrt-trust-accounting-help	Starter prompt for accounting questions.
vrt-accounting-integrity-monitoring	G/L monitoring operator flow: health, queue, case, evidence, review, repair. Requires the custom root endpoint and OAuth.

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.