Skip to main content

Create your first MCP server

A virtual server is the publishable MCP endpoint that an agent connects to. It lets you create an agent-specific surface from approved capabilities without modifying the underlying tools, resources, prompts, or connected servers. This guide builds a customer-support virtual server that can retrieve a ticket, use a support policy, and follow a standardized response procedure.

Plan the server boundary

Before creating the server, write down the job it is allowed to perform and the minimum capabilities it needs. For this example: Do not attach tools merely because they are related. A virtual server should expose the smallest useful set of actions and context.

1. Prepare the capabilities

Create or identify the following catalog entries first:
  1. In Tools, create get_ticket with a schema that requires a ticket identifier and backend credentials limited to read access.
  2. In Resources, add support-policy from an approved source or inline content.
  3. In Prompts, create draft_support_reply with declared inputs such as ticket_summary and policy_excerpt.
  4. In Skills Hub, create resolve-support-request, select get_ticket, and provide markdown instructions covering checks, escalation conditions, and the expected answer format.
A skill instruction can be structured like this:

2. Create the virtual server

  1. Open Virtual Servers and select Create Server.
  2. Enter a distinct name, display name, and description. Explain the server’s intended job in the description.
  3. Configure the MCP client connection details and choose the server visibility.
  4. Select the appropriate team or ownership boundary when available.
  5. Continue to the capability-selection step.

3. Attach and review capabilities

Attach only the prepared tool, resource, prompt, and skill. Confirm the selection carefully: what is attached becomes discoverable by clients authorized to use this virtual server. Before publishing, verify:
  • Tool schemas reject undeclared or unsafe inputs where appropriate.
  • Backend credentials are valid and least-privileged.
  • Resource content is current and appropriate for the selected visibility.
  • Prompt arguments match the template variables.
  • Skill instructions name only tools that are attached and describe escalation paths.
  • The server visibility and ownership match the intended audience.

4. Publish and validate

Create the server, then open Playground and select it from the available MCP servers.
  1. Confirm that the catalog contains the expected tool, resource, prompt, and skill—not unrelated items.
  2. Call get_ticket with a test ticket.
  3. Read the policy resource and render or invoke the prompt with safe test inputs.
  4. Exercise the skill workflow using a scenario that should succeed and one that should escalate.
  5. Review logs, latency, and error details before granting broader access.

5. Operate the server

Server composition is not permanent. When an API changes, a policy is superseded, or a skill needs improvement, update the underlying catalog entry or the server attachment deliberately, retest it in Playground, and review the resulting operational data. For larger environments, use a sandbox virtual server first, then reproduce the reviewed configuration in a production server with production-specific credentials and visibility.