> ## 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. # Agent/MCP Visibility > Control how your Virtual APIs are discovered and accessed by AI agents through the agent card system. # Agent/MCP Visibility **From private to publicly discoverable — one setting.** Every Virtual API can be exposed as an AI agent endpoint via the [Model Context Protocol (MCP)](../delivery/mcp-server). The **Visibility** setting controls who can discover your agent, whether authentication is required, and whether it appears in the DataHarbor catalog. ## Visibility levels Visibility is a single, escalating setting — each level opens access further: | Visibility | Agent Card | Catalog | Lease MCP Auth | Description | | ----------------- | ---------- | ------- | -------------- | ------------------------------------------------------------------------------------------------------------------ | | **Disabled** | Not served | No | N/A | Not an agent. Nobody can discover or connect to it. | | **Private** | Auth only | No | Required | Only authenticated clients can find and use it directly. Internal use only. | | **Unlisted Open** | Public | No | Required | Anyone with the link can discover it, but it won't appear in the catalog and direct lease MCP still requires auth. | | **Listed Open** | Public | Yes | Required | Publicly discoverable in the catalog and registry, while direct lease MCP still requires auth. | ### Disabled The default state. The Virtual API functions normally for REST delivery but does not serve an agent card. Requests to the agent card endpoint return 404. ### Private The agent serves a card only to authenticated clients. Anonymous requests receive a minimal stub card — enough to know the agent exists and how to authenticate, but no operational details. Authenticated clients see the full agent card including: * Security schemes and requirements * Extended card with skill details and parameters MCP sessions require OAuth authentication. ### Unlisted Open The agent card is fully public with no security schemes — anyone with the link can inspect the public discovery metadata. However, the agent does not appear in the DataHarbor catalog, and the lease-scoped MCP endpoint still requires authentication. This is ideal for: * Embedding agents in specific applications * Direct integrations where you share the URL * Testing before listing publicly ### Listed Open Like Unlisted Open, but the agent is indexed in the DataHarbor catalog and registry. This is the most open discovery setting — anyone can find it, inspect the public metadata, and begin from the platform discovery surface, while direct lease MCP still requires authentication. ## Agent cards An agent card is a machine-readable description of your agent's capabilities, following the [Model Context Protocol](https://modelcontextprotocol.io) spec. DataHarbor generates it automatically from your Virtual API configuration. Every Virtual API with a non-disabled visibility serves its agent card at: ```text theme={null} https://service.dataharbor.co/{virtualApiId}/.well-known/agent-card.json ``` For **Private** Virtual APIs, the public card includes a capability flag that directs A2A clients to fetch the extended card after authenticating: ```text theme={null} https://service.dataharbor.co/{virtualApiId}/extendedAgentCard ``` The extended card includes richer metadata such as skill-level field details, lease expiration, and filter configuration that is only appropriate for authenticated consumers. ### What's in an agent card | Field | Description | | ------------------------ | -------------------------------------------------------------------------- | | **Name and description** | From your Virtual API configuration | | **Skills** | Auto-generated from your API's endpoints and current control configuration | | **Security schemes** | OAuth requirements (Private only) | | **Extended card URL** | Link to full details (Private only) | Generated skill descriptions reflect the final governed shape of your Virtual API. For example, transform-only pipelines are described as transformed data rather than raw access, and cleanup controls like `delete` do not expose removed fields as public capabilities. ### Stub vs. full card For **Private** visibility, unauthenticated requests receive a stub card: ```json theme={null} { "name": "customer-data-agent", "description": "Customer data with PII controls", "securitySchemes": { "oauth2": { "type": "oauth2", "flows": { "..." } } } } ``` Authenticated requests receive the full card with skills, parameters, and the extended card URL. For **Unlisted Open** and **Listed Open**, all requests receive the full card — no security schemes are included, and the extended card endpoint is not served. ## Registry Virtual APIs with **Listed Open** visibility are indexed in the DataHarbor registry and discoverable by both humans and machines: * **Registry catalog**: [https://service.dataharbor.co/registry](https://service.dataharbor.co/registry) * **OpenAPI spec** (with query information): [https://service.dataharbor.co/openapi/v1.json](https://service.dataharbor.co/openapi/v1.json) For MCP-native discovery, clients can also start at `https://service.dataharbor.co/mcp`. The anonymous relay surface is intentionally limited to discovery-oriented tools. ## Choosing a visibility level | Scenario | Recommended | | ---------------------------------------- | ------------- | | Not using MCP delivery | Disabled | | Internal agents for your own AI tools | Private | | Sharing an agent with a specific partner | Unlisted Open | | Publishing an agent for public discovery | Listed Open | ## Next steps Configure the lease-scoped and discovery MCP endpoints Make listed Virtual APIs discoverable in the registry