These recommendations complement the existing Netvisor integration instructions:
Access control and authorisation
If the MCP server is intended for use by external third-party integrators or agent service providers (Visma is the 1st party, you are the 2nd party), it is strongly recommended to use an additional authorisation layer. This prevents accidental or unauthorised modifications to business data.
Read-only by default
MCP servers should primarily expose read, search, and metadata lookup capabilities. On the current API surface, write actions should be treated as higher risk because automated tool use can create inconsistent or unintended data. Until validation, permissions, and API contracts are stronger, write actions should only be enabled for narrowly scoped use cases and with explicit safeguards.
Human validation for write actions
If the MCP server allows creating, updating, or deleting business data, a human review step is recommended before execution. This is especially important for financial data (for example sales invoices, customer details, payment terms, dimensions, and status transitions). The MCP server must make the side effects of the action clear before approval.
Validate before Netvisor API calls
The MCP server must validate all required fields, enum values, identifiers, company context, and business preconditions before sending a request to Netvisor. Invalid requests should fail fast with clear, machine-readable error messages rather than relying on downstream correction. This reduces unnecessary processing and repeated corrective retries.
Respect company and environment boundaries
Every MCP tool call must run in the correct company context. MCP servers must not allow cross-company data access, credential mixing, or implicit privilege expansion.
Rate limiting is mandatory
MCP servers must be designed to operate within current and future Netvisor API rate limits. This includes any endpoint-specific, partner-specific, or company-specific limits that may be introduced.
Minimise polling
Partners should avoid continuous polling. Where polling is unavoidable, use caching, backoff, and sensible intervals. MCP integrations must not repeatedly query the same resources at high frequency solely to detect changes. Netvisor APIs are expected to evolve to provide stronger data contracts and better support for change notifications.
Use idempotent write actions whenever possible
MCP servers must protect against duplicate writes caused by retries, model loops, or user resubmissions. This is critical especially for invoice creation and other financial transactions. Repeated tool execution must not silently create multiple identical objects.
Use MCP server only through official APIs
MCP servers should only use supported Netvisor APIs. They must not bypass official APIs through database access, internal UI paths, hidden endpoints, or backend classes.
Auditability and traceability
Each MCP call must be logged. The log must store the tool name, company context, caller identity, correlation ID, called API, result, and latency. For write actions, the approval chain must also be traceable.
Clear tool descriptions
MCP tool descriptions must clearly state the tool’s purpose, required inputs, side effects, company scope, and situations where the tool must not be used. This reduces errors made by AI agents and improves implementation quality. Where possible, descriptions should be complemented with documentation suitable for language models that explains domain concepts, workflow intent, constraints, and recommended usage patterns (for example Stripe’s documentation).
Did you find it helpful? Yes No
Send feedback