CONNECTED THINKING
Knowledge atlas
Follow people, viewpoints and their original evidence.
1 people · 1 sources · 1 viewpoints
IN CONTEXT
MCP connector approval
Choose a viewpoint. Follow it back to the conversation.
MCP connectors require vendor-submitted tool specs and per-tool security review
Equal sectors are reading positions, not rankings.
Showing 1–1 of 1 viewpoints · Newest sources first
Selected viewpoint
MCP connectors require vendor-submitted tool specs and per-tool security review
For MCP connectors—where the vendor operates the server—Harvey requires the vendor to submit its full tool list, capability scope, hosting and auth details, data-processing regions, and test credentials; the security team then reviews each tool individually, approves or rejects it, assigns a risk level, and records decisions in a code-shipped registry.
These are individual perspectives, not a measure of consensus. Source material stays in its original language.
Supporting evidence
Original excerpt
An MCP member's server is operated by the vendor, so the review has to judge a system someone else runs, and it gets an extra layer of admission. The vendor submits its full tool list and capability scope, hosting and auth details, data-processing regions, and test credentials, and the security team reviews the tools one by one, deciding for each whether it is approved and assigning its risk level.
Context
A native member is a wrapper we wrote around the vendor's API, and it goes through the same security review: which of the vendor's APIs we call and which scopes we request are what the security team signs off on. This way, approval is a hard gate before engineering integration begins. Those decisions land in a registry that ships with the code: a structured URL matcher, the vendor's full advertised tool list, the subset that may be invoked, and a hand-written risk and capability annotation for each.
Publication dates describe the sources, not changes in belief.