Overview
The Scispot Model Context Protocol (MCP) Server enables AI clients — such as Claude, Cursor, and compatible MCP hosts — to interact directly with your Scispot workspace: querying sample records, retrieving protocols, accessing experiment data, and performing other lab operations through natural language. Because MCP bridges AI systems to live laboratory data, it introduces elevated security and compliance responsibilities that every organization must understand and enforce.
This policy governs how the Scispot MCP Server may be used, who may enable and access it, and how authentication credentials must be managed. It applies to all Scispot customers participating in the MCP Beta program and all users within their organizations.
Eligibility and Access
Access to the Scispot MCP Server is restricted exclusively to Super Admins or Dry Lab folks. Standard users, lab members, and workspace members — regardless of their role — may not connect, configure, or use the MCP Server without Super Admin authorization.
This restriction mirrors how leading SaaS platforms manage MCP enablement. Salesforce requires an admin user with the Customize Application permission to enable its hosted MCP servers, and Notion mandates that a workspace admin enable MCP connections under Settings before any user can proceed. HubSpot similarly requires that the account admin connect first before other users are permitted to authenticate. The principle is consistent: MCP access touches your most sensitive system data, and only the most privileged role should control the on/off switch.
In Scispot, Super Admins are the designated stewards of platform security. Extending MCP access beyond that tier introduces unnecessary risk to laboratory records, sample data, ELN entries, and regulated results — data that may be subject to FDA 21 CFR Part 11, GxP, or SOC 2 requirements.
How to Enable MCP Access
Fill this form to request MCP access
Token Policy
One Token Per User — No Exceptions
Every individual who connects to the Scispot MCP Server must use their own unique, personally issued API token. Sharing tokens between users, agents, or systems is strictly prohibited.
This is one of the most critical rules in this policy. Token sharing is a well-documented security anti-pattern across the industry:
Shared tokens eliminate individual accountability — there is no way to attribute specific actions to a specific person.
If a shared token is compromised, all users and workflows that depend on it are immediately exposed.
Shared credentials violate FDA 21 CFR Part 11's requirement for unique user identification and attributable audit trails — a critical compliance gap for any biotech lab running regulated workflows.