ComputeSphereLearn
Console
Learning paths / Vibe coding to production / Give your agent context

Skills and MCP

Reading · 6 min · Module 7, lesson 2 of 311 min left in this module

Module 7 · Give your agent contextLesson 2 of 3

Goal: Explain what skills and MCP servers add to an agent, connect ComputeSphere's MCP server knowing what it can do, and write a small skill of your own.

3:54 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know two ways to extend what your agent can do. A skill, and an MCP server. And the one question to ask of both.

[00:11] Skills

Start with skills. You've met instruction files. They apply to every session. A skill is instructions for one task. It's loaded only when that task comes up. In Claude Code, a skill is a folder with a markdown file in it. Other tools call the same idea custom commands, prompt files, or rules.

[00:33] A skill, step by step

Here's a small one, for the checks you'd want before any deploy. The shape is similar everywhere. First, a name. Then a one-line description. Your agent reads it to decide when the skill applies. Then the steps. Run the tests, and stop if anything fails, is skipped, or is to-do. Stop if there are uncommitted changes. Show the commits since the last deploy, and the exact deploy command. And the last step tells it to wait for your explicit OK, and never deploy on its own. Keep a skill to one job, with steps you'd follow yourself. ComputeSphere's own skills for agents are coming. Until then, write the ones you need.

[01:18] MCP

Now MCP, the Model Context Protocol. It's an open standard for connecting agents to tools. An MCP server publishes a list of tools. Each one has a name, a description, and its inputs. Your agent reads the list, picks a tool, and calls it. And depending on its approval settings, it asks you first.

[01:42] ComputeSphere's MCP server

ComputeSphere runs one. You add it as a remote MCP server, in your agent's settings. The first time it's used, your browser opens, so you can sign in to ComputeSphere. Its tools mirror the ComputeSphere API.

So what can your agent do with it? It can read. Projects, services and deployments, their status, and their build, deploy and runtime logs. And it can change things. Redeploy, roll back, scale, and set variables. For deletions, and for replacing a whole set of variables or secrets, the server adds its own confirmation step. You approve the exact action.

[02:26] It acts as you

Here's the part to keep in mind. It acts as you, with everything your account can reach. That's handy for reading logs while you debug. It's also why you keep your agent asking before every call that changes something. Unattended work uses a token limited to one project instead. That's the next module. And to cut it off, remove the connection in your agent's settings.

[02:51] Adding it by hand

Some agents take a JSON file instead of a settings screen. It usually looks like this. Check your agent's documentation for the file's name and location. And if you open the URL directly, you get a four oh one. It answers only signed-in agents.

[03:09] Recap

To recap. A skill is instructions for one job. It can only use tools your agent already has. An MCP server adds new tools, to act on another system. So ask the same question of each. What can it do now, and who approves it?

Here's a question to check yourself. Your agent, connected to ComputeSphere's MCP server, proposes to delete a service. What happens? You're asked to confirm that exact deletion before it runs. So read what it names before you approve. Next, check what you've learned. I'll see you there.

Key idea

A skill teaches your agent how to do one kind of job, in steps you wrote. An MCP server gives it tools to act on another system, such as your ComputeSphere account. Both extend what the agent can do, so ask the same question of each: what can it do now, and who approves it?

Skills: a job, written down once

An instruction file applies to every session. A skill is a set of instructions for one task, loaded only when that task comes up. In Claude Code, for example, a skill is a folder with a SKILL.md file; other tools call the same idea custom commands, prompt files or rules. The shape is similar everywhere: a name, a one-line description the agent uses to decide when it applies, and the steps.

Here's a small one for the checks you'd want before any deploy:

---
name: pre-deploy-check
description: Use before anything is deployed, redeployed or rolled back.
---

1. Run `npm test`. Stop and report if anything fails, is skipped or is todo.
2. Run `git status`. Stop if there are uncommitted changes.
3. Show the commits since the last deploy with `git log --oneline`.
4. Show the exact deploy command you intend to run.
5. Wait for my explicit OK. Never deploy on your own.

Keep a skill to one job, with steps you'd follow yourself. ComputeSphere's own skills for agents are coming; until then, write the ones you need.

MCP: tools from other systems

The Model Context Protocol (MCP) is an open standard for connecting agents to tools. An MCP server publishes a list of tools, each with a name, a description and its inputs. Your agent reads the list, picks tools, and calls them; your agent asks you first, depending on its approval settings.

ComputeSphere's MCP server

ComputeSphere runs one at https://mcp.computesphere.com/mcp. Add it as a remote MCP server in your agent's settings. The first time it's used, your browser opens to sign in to ComputeSphere.

Its tools mirror the ComputeSphere API. Your agent can list projects, services and deployments, read their status and their build, deploy and runtime logs, and change things: redeploy, roll back, scale, set variables. For deletions, and for replacing a whole set of variables or secrets, the server adds its own confirmation step, and you approve the exact action.

It acts as you, with everything your account can reach. That's convenient for reading logs while you debug. It's also why you keep your agent asking before every call that changes something, and why unattended work uses a token limited to one project instead (next module). To cut it off, remove the connection in your agent's settings.

Adding it by hand

Most agents with MCP support have a settings screen for remote servers: give it the URL above. Those configured with a JSON file usually take this shape; check your agent's documentation for the file's name and location:

{
  "mcpServers": {
    "computesphere": { "url": "https://mcp.computesphere.com/mcp" }
  }
}

The server uses streamable HTTP. Opening the URL directly returns 401: it answers only signed-in agents.

Check yourself

Your agent, connected to ComputeSphere's MCP server, proposes to delete a service. What happens?
Which one gives your agent a new ability to act on another system?

In the docs