Third-party risk work usually starts with a supplier name someone typed into a form; resolving a URL or domain to a known vendor first means the relationship, the assessment and the intelligence reports all hang off the right entity instead of a duplicate. The assessment configuration is where the real decisions live — follow-up type, the risk threshold that triggers it, the collection timeline, what happens when the vendor does not respond, and whether AI processing runs without human review. Those are set at creation, and two of them can be changed afterwards. The audit tools are read-only and capped, which is the right shape for a compliance question.
VISO TRUST's own server over its API, covering the third-party risk lifecycle — vendor relationships, assessments, intelligence reports, webhooks, users and audit logs. A managed instance is hosted, or you can run the same server yourself.
- Vendor relationships end to end: created in full or from just a domain, updated wholly or partially, searched by domain or vendor name, tagged, onboarded with approval and lifecycle settings, offboarded and archived (create_relationship, create_relationship_by_domain, update_relationship, partially_update_relationship, search_relationships, create_tags, onboard_relationship, offboard_relationship, archive_relationship).
- The relationship record read back with assessment status, risk levels and contacts — all of them, one by ID, its assessment history, or the third-party contact updated (get_all_relationships, get_relationship_by_id, get_relationship_assessment_history, update_third_party_contact).
- Assessments launched against an existing relationship with the recipient, public document URLs, requested audit types, collection timeline, follow-up type and risk threshold, and a choice of AI-only processing or human review — then read in detail or as a summary (create_assessment, get_assessment, get_assessment_summary).
- Assessment deadlines and follow-up rules changed after the fact, with the expiration date required to be in the future (update_assessment_expiration_date, update_assessment_followup).
- External intelligence pulled in from three sources — BitSight, SecurityScorecard and Recorded Future — with every report for a vendor listed, or the latest one from a named source (create_bitsight_intelligence_report, create_security_scorecard_intelligence_report, create_recorded_future_intelligence_report, get_intelligence_reports_by_vendor, get_latest_intelligence_report).
- A vendor looked up in the VISO TRUST directory by URL or domain, returning name, homepage, description, favicon and known domains — the fastest way to resolve a supplier before creating anything (search_vendor_directory).
- Audit log events over a date range, filtered by event type: the user-scoped feed capped at 500 records, and the wider feed covering user, organization, assessment and relationship events (get_user_audit_log_events, get_audit_log_events).
- Webhooks listed, read, created, updated and deleted, plus the organization's users, business cases and data types (get_all_webhooks, create_webhook_configuration, update_webhook_configuration, delete_webhook_configuration, get_all_users, get_user_by_email, create_user, get_all_business_cases, get_all_datatypes).
A VISO TRUST account and an API token generated from the platform. The hosted instance at https://mcp.visotrust.com/mcp takes any Streamable HTTP client with the token as a Bearer header and needs nothing installed. Running it yourself takes Java 21 or newer and Gradle, optionally in Docker; the remote profile serves the endpoint on port 3001 in stateless mode, so it scales behind a load balancer without session affinity. The legacy SSE endpoints are no longer served.
One command plus a key — npx -y mcp-remote https://mcp.visotrust.com/mcp, then supply credentials