# Skills

Una **skill** es una capacidad empaquetada que un Met puede usar: hablar con un
sistema externo, ejecutar un procedimiento, leer una fuente de datos. En vez de
cablear cada integración a mano, activas la skill y el Met ya sabe usarla.

Usa los scopes `skills:read` y `skills:manage`.

## El modelo en tres piezas

| pieza | qué es |
|---|---|
| **Catálogo** | las skills disponibles para tu workspace — las del sistema y las del marketplace |
| **Activación** | la skill instalada en tu workspace, con sus credenciales y su estado |
| **Vínculo** | qué Mets pueden usarla. Activarla no se la da a todos: se vincula por Met |

Esa tercera pieza es la que más se pasa por alto. **Activar una skill no hace que
tus Mets la usen** — hay que vincularla. Es a propósito: así un Met de soporte no
hereda las capacidades del de facturación.

## Ver qué hay

```ts
const catalogo = await met.skills.marketplace();  // las del marketplace
const sistema  = await met.skills.system();       // las que trae Meteor
const activas  = await met.skills.active();       // las que ya tienes activas
const todas    = await met.skills.all();
```

Para saber en qué estado está cada una:

```ts
const estados = await met.skills.status();
// → [{ skill_id, active, configured, missing_credentials: [...] }, …]

const una = await met.skills.skillStatus('crm-hubspot');
```

`configured` es la que importa antes de vincular: una skill puede estar **activa y
sin credenciales**, y en ese caso el Met la ve y falla al usarla.

## Activar y configurar

```ts
await met.skills.activate('crm-hubspot');

await met.skills.setCredentials('crm-hubspot', {
  api_key: process.env.HUBSPOT_KEY,
});
```

Las credenciales son **write-only**: se guardan cifradas y ninguna respuesta de la
API las devuelve, ni completas ni enmascaradas. Para saber si están puestas usas
`configured` del estado; para cambiarlas, las vuelves a mandar enteras.

Antes de dárselas a un Met, pruébalas:

```ts
const prueba = await met.skills.test('crm-hubspot', { /* payload de ejemplo */ });
```

`test` ejecuta la skill de verdad contra el sistema externo, así que gasta lo que
gaste esa llamada. Con una key `met_test_` no puedes ejecutar skills que tengan
efectos externos — ver [Autenticación](autenticacion.html).

## Vincularla a un Met

```ts
await met.skills.linkToAgent(agentId, 'crm-hubspot');

const delMet = await met.skills.forAgent(agentId);   // qué ve ese Met

await met.skills.unlinkFromAgent(agentId, 'crm-hubspot');
```

Desvincular **no** desactiva la skill ni borra sus credenciales: solo se la quita a
ese Met. Para sacarla del workspace:

```ts
await met.skills.deactivate('crm-hubspot');   // conserva credenciales
await met.skills.remove('crm-hubspot');       // la saca del workspace
```

Las ejecuciones en curso que ya estaban usando la skill terminan; las siguientes
dejan de verla.

## Skills con sus propios MCPs

Una skill puede traer servidores MCP propios, y puedes controlar cuáles quedan
expuestos:

```ts
const servidores = await met.skills.mcps('crm-hubspot');

await met.skills.setMcps('crm-hubspot', { /* configuración */ });
await met.skills.updateMcp('crm-hubspot', mcpId, { /* cambios */ });
await met.skills.removeMcp('crm-hubspot', mcpId);
```

No confundir con [Integraciones MCP](integraciones-mcp.html), que son conectores que
tú registras a nivel de workspace: los de aquí vienen dentro de la skill y viven y
mueren con ella.

## Cuándo una skill y cuándo una tool suelta

- **Skill** — si la capacidad tiene credenciales, varias operaciones y quieres
  prenderla o apagarla como una unidad.
- **[Integración MCP](integraciones-mcp.html)** — si ya tienes un servidor MCP y
  solo quieres que Meteor lo use.
- **[Función](funciones-y-flujos.html)** — si es tu propio código y quieres que el
  Met lo llame como un endpoint.

> El orden que casi siempre quieres: `status` → `activate` → `setCredentials` →
> `test` → `linkToAgent`. Saltarse `test` es la causa más común de un Met que
> "tiene la skill" y falla al primer uso.