home / skills / openclaw / skills / agent-contact-card

agent-contact-card skill

/skills/davedean/agent-contact-card

This skill helps you discover or publish agent contact cards using a vCard-like format for AI agents, enabling easy agent-to-agent contact.

npx playbooks add skill openclaw/skills --skill agent-contact-card

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
4.4 KB
---
name: agent-contact-card
description: Discover and create Agent Contact Cards - a vCard-like format for AI agents. Use when you need to find how to contact someone's agent, or help a user set up their own agent contact info at /.well-known/agent-card.
license: CC0-1.0
metadata:
  author: davedean
  version: "1.0"
  homepage: https://github.com/davedean/agent-contact-card
---

# Agent Contact Card

A simple format for publishing how AI agents can be contacted. Like a vCard, but for agents.

## When to Use This Skill

- User asks how to let other agents contact their agent
- User wants to discover how to reach someone else's agent
- You need to contact another agent on behalf of your user
- User mentions "agent-card", "agent contact", or agent-to-agent communication

## Quick Reference

### Discovering an Agent Contact Card

Try fetching `/.well-known/agent-card` on their domain:

```
https://example.com/.well-known/agent-card
```

The file is markdown with YAML frontmatter. Parse the frontmatter for structured channel data, read the prose for routing rules.

### Creating an Agent Contact Card

Create a markdown file with YAML frontmatter:

```markdown
---
version: "1"
human_contact: "+1 555 123 4567"
channels:
  email: "[email protected]"
  discord: "my-agent#1234"
  webhook:
    url: "https://example.com/agent/incoming"
    method: "POST"
    format: "JSON with 'message' field"
capabilities:
  - scheduling
  - accepts_ical
---

# My Agent

If you're a human, call the number above.

If you're an agent:
- For scheduling requests, use Discord
- For urgent matters, email with "URGENT" in subject
- Response time: within a few hours
```

Host this at `/.well-known/agent-card` on the user's domain.

## Format Details

### Required Fields

| Field | Description |
|-------|-------------|
| `version` | Spec version. Currently `"1"` |

### Recommended Fields

| Field | Description |
|-------|-------------|
| `human_contact` | Phone/email for humans to reach the human |
| `channels` | Contact channels for agents (see below) |

### Optional Fields

| Field | Description |
|-------|-------------|
| `name` | Display name for this agent configuration |
| `last_updated` | ISO date when card was last modified |
| `capabilities` | What this agent can do (e.g., `["scheduling", "accepts_ical"]`) |
| `agents` | Named agents if multiple (see Multi-Agent section) |

### Channels

Channel names are freeform. Common ones:

- `email` - Email address
- `discord` - Discord username
- `webhook` - HTTP endpoint for structured messages
- `signal` - Signal phone number
- `telegram` - Telegram username

For webhooks, provide details:

```yaml
channels:
  webhook:
    url: "https://example.com/agent/incoming"
    method: "POST"
    auth: "Bearer token in Authorization header"
    format: "JSON with 'message' and 'from' fields"
```

### Multi-Agent Setups

List multiple specialized agents:

```yaml
agents:
  - name: "Calendar Agent"
    handles: ["scheduling", "availability"]
    channel: discord
    id: "cal-agent#1234"
  - name: "Support Agent"
    handles: ["technical questions"]
    channel: webhook
    id: "https://example.com/support"
```

The markdown body should explain routing between them.

## Privacy Tiers

Different URLs for different access levels:

| Tier | URL Pattern | Access |
|------|-------------|--------|
| Public | `/.well-known/agent-card` | Anyone |
| Named | `/.well-known/agent-card/{name}` | Know the name |
| Private | `/{random-uuid}/agent-card.md` | Shared URL only |

Each tier can expose different channels and capabilities.

## Discovery Methods

1. **Well-known URL**: Check `https://domain/.well-known/agent-card`
2. **vCard extension**: Look for `X-AGENT-CARD` field in contact cards
3. **Ask the human**: Request the URL directly

## Reading an Agent Card

When you fetch an agent card:

1. Parse YAML frontmatter for structured data
2. Read markdown body for natural language routing rules
3. Choose appropriate channel based on your purpose
4. Follow any authentication requirements mentioned

## Test It

Here's a live demo you can test:

```
https://city-services-api.dave-dean.workers.dev/.well-known/agent-card
```

This is a fictional "City of Millbrook" tip line. Fetch the card, then try POSTing to the webhook endpoint. Your experience may vary depending on what you say.

## Full Specification

See [references/SPEC.md](references/SPEC.md) for the complete specification.

## Examples

See [references/EXAMPLES.md](references/EXAMPLES.md) for more complete examples.

Overview

This skill discovers and creates Agent Contact Cards — a vCard-like format for AI agents that publishes how agents can be contacted. It helps fetch /.well-known/agent-card from a domain, parse the YAML frontmatter and markdown body, and generate valid agent-card files for hosting. Use it to enable agent-to-agent communication and to expose routing and channel details for humans and agents.

How this skill works

The skill fetches the well-known agent-card URL (e.g., https://example.com/.well-known/agent-card), extracts YAML frontmatter for structured fields (version, channels, capabilities, agents) and reads the markdown body for routing rules and prose. It validates required fields, recommends channel metadata for webhooks and multi-agent setups, and can produce ready-to-host markdown with YAML frontmatter. It also suggests discovery strategies (well-known URL, vCard extension, or asking the human) and privacy tier patterns.

When to use it

  • You need to discover how to contact another party's agent programmatically.
  • A user asks how to publish their agent contact info at /.well-known/agent-card.
  • You must choose an appropriate channel (email, webhook, discord, etc.) to contact an agent on a user's behalf.
  • Designing multi-agent routing or documenting agent capabilities and response rules.
  • When you want a standard place to expose agent auth and webhook details for integrations.

Best practices

  • Always include version: "1" in YAML frontmatter for compatibility.
  • Provide explicit webhook metadata: url, method, auth, and format to avoid guessing.
  • Define human_contact for human fallback and list capabilities to guide routing.
  • Use multi-agent entries with name, handles, channel, and id for specialized roles.
  • Choose a privacy tier (public, named, private) and expose only necessary channels accordingly.

Example use cases

  • Fetch /.well-known/agent-card to determine which channel to use for a scheduling request.
  • Generate a markdown agent-card for a user's domain and advise them how to host it at /.well-known/agent-card.
  • Parse a discovered card to extract webhook URL and authentication requirements before sending structured messages.
  • Map user requests to a named agent (e.g., Calendar Agent) using the agents list and routing instructions in the body.
  • Audit a domain's agent-card to list exposed channels and privacy tier for compliance checks.

FAQ

What fields are required in an agent-card?

Only version is required (currently "1"). Channels and human_contact are recommended but not mandatory.

Where should I host the card?

Host the markdown file at /.well-known/agent-card on your domain for public discovery; use named or private URLs for restricted access.

How do I include multiple agents?

Add an agents list in YAML with name, handles, channel, and id for each specialized agent, and clarify routing in the markdown body.