> ## Documentation Index > Fetch the complete documentation index at: https://docs.dataharbor.co/llms.txt > Use this file to discover all available pages before exploring further. # MCP Server Delivery > Turn any Virtual API into a governed MCP endpoint for AI agent consumption. # MCP Server Delivery **Governed AI data access. No separate security model.** Turn any Virtual API into a governed MCP (Model Context Protocol) endpoint for AI agent consumption. DataHarbor gives you two MCP entry points: one to connect directly to a specific Virtual API, and one to discover the broader DataHarbor catalog. ## How it works AI agents inherit the same controls as any other consumer: * Same privacy controls (redact, tokenize, anonymize) * Same access controls (geo, expiration, revocation) * Same audit trail No separate security model for AI. ## MCP endpoints ### Direct Virtual API MCP Every Virtual API with MCP delivery enabled gets a lease-scoped MCP URL: ```text theme={null} https://service.dataharbor.co/{leaseId}/mcp ``` Point any MCP client at this URL when you want to work inside one specific governed Virtual API. This is the lease-targeted MCP surface: you are already inside a single Virtual API, not browsing the wider platform. OAuth authentication is required. ### Platform discovery MCP DataHarbor also exposes a platform discovery endpoint: ```text theme={null} https://service.dataharbor.co/mcp ``` Use this endpoint when you want to discover available Virtual APIs across DataHarbor before connecting to a specific one. This is the platform lobby, not the lease-targeted working surface. * Anonymous sessions get a narrow, discovery-only tool surface. * Authenticated sessions can inspect richer platform metadata. * Once you choose a specific Virtual API, connect to its lease-scoped MCP URL for direct use. ### Current platform discovery tools The platform discovery surface is intentionally small. Today, `https://service.dataharbor.co/mcp` exposes: | Tool | Availability | What it does | | ---------------------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------- | | `search_registry` | Anonymous and authenticated sessions | Search the DataHarbor registry for listed Virtual APIs and discovery metadata | | `get_virtual_api_info` | Authenticated sessions | Retrieve richer information about a specific Virtual API after you know which one you want to inspect | This tool surface is product-defined and stable enough to document directly. ### Connect from Claude Desktop Add a specific Virtual API to your Claude Desktop configuration: ```json theme={null} { "mcpServers": { "dataharbor-customers": { "url": "https://service.dataharbor.co/9b745364-f019-4c57-a044-31860b0c12cf/mcp" } } } ``` To start with platform discovery instead, point your MCP client at: ```text theme={null} https://service.dataharbor.co/mcp ``` ## Lease-scoped tools When you connect to a specific Virtual API endpoint, DataHarbor exposes a small lease-scoped tool surface for that one governed Virtual API. Today, a direct lease session exposes: | Tool | Description | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `describe_schema` | Describe the effective governed contract for the current Virtual API, including route context, named visible fields, pass-through fields observed by DataHarbor, derived fields, and geofence restrictions | | Lease-specific data tool | Fetch governed data from the current Virtual API. The tool name is derived from the Virtual API title, so it varies by lease | The lease-specific data tool uses the current Virtual API's configured route template. If the backing route exposes path parameters, those parameters become MCP tool inputs. `describe_schema` is intentionally privacy-bounded: * It describes the lease-owned effective contract, not the full raw backing API schema. * Unchanged pass-through fields may appear when DataHarbor has observed them in the backing schema inventory. * Redacted field names may still appear when the lease explicitly exposes them. * Deleted fields are omitted. * It does not expose raw explored-model documents, hidden annotations, or fields removed by lease controls. ### Example conversation ``` User: Describe what this Virtual API exposes. Claude: I'll inspect the governed lease contract first. [Calling describe_schema] This Virtual API exposes customer records through `/v1/customers/{customerId}`. Visible fields include pass-through field `customer_id`, `email` (redacted), and `full_name` (derived, hashed). Requests are restricted to `US`. User: Pull customer 123. Claude: I'll use the lease-scoped data tool for that Virtual API. [Calling the lease-specific data tool with `customerId=123`] ``` The AI sees tokenized/redacted data — never the raw values. ## Governance in action | What AI sees | What's protected | | ------------ | ------------------ | | `tok_abc123` | Real email address | | `tok_def456` | Real phone number | | `""` (empty) | SSN, date of birth | The AI can still: * Count and aggregate * Filter and search * Correlate by tokens (within the same Virtual API) The AI cannot: * See raw PII * Reverse tokens * Access data after expiration/revocation ## Audit trail Every AI request is logged: ```json theme={null} { "timestamp": "2025-01-15T10:30:00Z", "virtual_api": "ai-customer-view", "delivery": "mcp", "tool": "search_customers", "filters": { "state": "CA", "balance": { "gt": 1000 } }, "records_returned": 23, "oauth_client": "dh_mcp_client_abc123" } ``` ## Next steps Sync governed data to your data platform Monitor what AI agents access