> Source: https://wexa.ai/docs/agents/list-peer-agents

# list-peer-agents

List the peer agent connections this project holds. Each entry carries the `connection_id` an external agent node points at. Needs the `fabric:orchestrate.read` grant.

The shape of `result` for `list-peer-agents` is not recorded here: it was not captured against a live deployment. Call it once and read what comes back rather than assuming a shape.

**List peer agents**

**Wexa MCP server**

```bash
curl -sS -X POST https://fabric.wexa.ai/mcp/$FABRIC_PROJECT_ID \
  -H "authorization: Bearer $FABRIC_API_KEY" \
  -H "Mcp-Session-Id: $MCP_SESSION_ID" \
  -H "content-type: application/json" -H "accept: application/json" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"list-peer-agents","arguments":{}}}'
```

**REST API**

```bash
curl -sS https://fabric.wexa.ai/v1/list-peer-agents \
  -H "authorization: Bearer $FABRIC_API_KEY" \
  -H "content-type: application/json" \
  -d '{}'
```

**TypeScript SDK**

```ts
import { Fabric } from '@wexa-fabric/sdk'

const fabric = new Fabric()
const result = await fabric.listPeerAgents({})
```

**Python SDK**

```python
from wexa import Fabric

fabric = Fabric()
out = fabric.list_peer_agents()
```

## Parameters

| Parameter | Type | Required | Notes |
| --- | --- | --- | --- |
| none |  |  | This tool takes no parameters. Send an empty object. |

**More details**

A peer agent connection is the registered link to an external agent on another platform, one that a process flow can hand a whole goal to. The `connection_id` goes on an `interop_agent` node as `registration_id`, so call this before you build one. A stored credential is never returned, in any form, masked or otherwise. It is supplied once, to [register-peer-agent](/docs/agents/register-peer-agent), and no tool gives it back.

### Entry fields

| Field | What it is |
| --- | --- |
| `connection_id` | The id an `interop_agent` node takes as `registration_id`, and the id `delete-peer-agent` takes. |
| `name`, `description` | The name given at registration, unique within the project, and its description. |
| `platform` | The label for which platform the external agent runs on, as given at registration. |
| `protocol`, `endpoint` | `mcp` or `a2a`, and the external agent's URL. |
| `state` | `Draft` when registered, `Active` once a call to the external agent has gone through. |
| `external_agent_name`, `declared_capability` | The name and the description the external agent gave for itself. |
| `declared_abilities` | The abilities the external agent listed for itself. Absent when it listed none. |

`count` is how many connections there are. The last three fields are what the external agent said about itself when it answered the handshake, and they are absent when it said nothing. `declared_abilities` are not skill ids: a skill is only ever what provisioning a connector mints, and an `interop_agent` node carries no skills.

Every tool call works the same way: [How every tool call works](/docs/sdks-and-apis/how-every-tool-call-works).