> ## Documentation Index
> Fetch the complete documentation index at: https://docs.budecosystem.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Create Your First MCP Server

> Compose tools, resources, prompts, and skills into a virtual MCP server.

# 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.

<img src="https://mintcdn.com/budecosystem-b7b14df4/rK1OcGUP-NeFiAXo/images/image-143.png?fit=max&auto=format&n=rK1OcGUP-NeFiAXo&q=85&s=ba88125a0eab39581cb94c08d0763049" alt="Image" width="1920" height="874" data-path="images/image-143.png" />

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:

| Capability | Example                   | Why it is included                               |
| ---------- | ------------------------- | ------------------------------------------------ |
| Tool       | `get_ticket`              | Retrieves the ticket needed to answer a request. |
| Resource   | `support-policy`          | Supplies current policy context.                 |
| Prompt     | `draft_support_reply`     | Standardizes the response format.                |
| Skill      | `resolve-support-request` | Guides the agent through the complete procedure. |

Do not attach tools merely because they are related. A virtual server should expose the smallest useful set of actions and context.

```mermaid theme={null}
flowchart LR
    A[Define permitted job] --> B[Choose minimum capabilities]
    B --> C[Create virtual server]
    C --> D[Configure connection and visibility]
    D --> E[Attach capabilities]
    E --> F[Publish and test]
    F --> G[Monitor and iterate]
```

## 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:

```md theme={null}
## Objective
Resolve a customer-support request using the approved ticket data and policy.

## Procedure
1. Retrieve the ticket using `get_ticket`.
2. Consult the support-policy resource before recommending an action.
3. Escalate when the policy requires approval.

## Response format
Return a concise summary, the recommended action, and any escalation required.
```

## 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.

```mermaid theme={null}
flowchart LR
    A[customer-support virtual server] --> B[get_ticket tool]
    A --> C[support-policy resource]
    A --> D[draft_support_reply prompt]
    A --> E[resolve-support-request skill]
    B --> F[Read-only ticket system]
    C --> G[Approved policy content]
```

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.