A2a Client

Discover and send tasks to A2A agents via the A2A API Gateway. Use when: (1) finding available agents or LLM providers, (2) delegating tasks to other agents,...

Security Scan

The skill's scripts largely match its described purpose (discover/send A2A tasks), but there are mismatches between declared requirements and what the runtime actually uses (undeclared required gateway URL, an API key variable that is never used, and automatic admin JWT retrieval) that warrant caution.

Purpose & Capability

Name/description align with the included scripts: the three bash scripts implement discovery, sending, and status checking against an A2A API Gateway. However registry metadata declared no required env vars while SKILL.md and the scripts require A2A_GATEWAY_URL (and mention A2A_GATEWAY_API_KEY). The API key is accepted as a CLI/env/config override in the docs but the scripts do not include the API key in their HTTP headers — they always request an admin JWT from /v0/admin/bootstrap and use that token. This mismatch (undeclared required env var + unused API_KEY) is inconsistent and likely a bug or sloppy packaging.

Instruction Scope

The SKILL.md and scripts constrain actions to contacting the configured gateway endpoints and reading a local a2a.conf in the skill directory (or env vars / CLI flags). They do not attempt to read arbitrary host files or other system-wide config. One notable runtime behavior: the scripts automatically call the gateway's admin bootstrap endpoint and use whatever accessToken it returns as a bearer token for subsequent admin routes. That is consistent with the stated purpose (interact with the gateway) but elevates the script's authority depending on the gateway's configuration (a misconfigured gateway could yield an admin JWT without auth).

Install Mechanism

This is instruction-only / script-based: there is no install spec, no downloads, and no system modifications. Risk from install mechanism is low because nothing external is pulled during install. The scripts themselves are included in the package and run at invocation time.

Credentials

The skill requires network access to a gateway and expects A2A_GATEWAY_URL (documented in SKILL.md) but the registry lists no required env vars — a mismatch that could confuse users. The docs mention A2A_GATEWAY_API_KEY but the scripts never use it in HTTP requests (they rely solely on the admin JWT from bootstrap). Asking for an API key in config or docs without using it is disproportionate/misleading. The scripts do not request unrelated credentials or read system-wide secrets, but they will send whatever task content you provide to the configured gateway (so any sensitive data sent as a task will be transmitted).

Persistence & Privilege

The skill is not always-enabled and does not request special platform privileges. It does not modify other skills or agent-wide configuration. Autonomous invocation is permitted (default), which is normal for skills; there is no 'always: true' privilege.

What to consider before installing

This skill appears to implement what it claims (discover/send A2A tasks) but has a few inconsistencies you should address before installing or using it: - Verify and supply A2A_GATEWAY_URL in the skill's a2a.conf or via env var/CLI; the scripts will exit if it's missing. The registry metadata does not declare this, so the UI may not prompt you. - Understand that the scripts automatically call <gateway>/v0/admin/bootstrap and use the returned accessToken as an admin bearer token for subsequent calls. Confirm you trust the gateway endpoint — if the gateway is misconfigured this could grant elevated access. - The docs mention A2A_GATEWAY_API_KEY, but the scripts do not include that API key in request headers. Ask the author whether the API key should be used and why it is declared if unused (possible bug). - Be careful what you send as a task: task contents will be transmitted to the configured gateway and routed to other agents/providers. Do not send sensitive credentials or private data unless you control and trust the gateway and recipients. - If you need tighter assurance, request the author update the package to: (1) declare required env vars in registry metadata, (2) either use or remove the API_KEY field consistently, and (3) optionally add an explicit check/option for gateways that require API keys rather than assuming bootstrap returns an admin token. If you do not control the gateway or cannot verify its configuration, treat this skill as higher-risk and avoid sending sensitive information through it.

A2A Client — Agent-to-Agent Task Routing

Discover and interact with other agents through the A2A API Gateway's A2A (Agent-to-Agent) API. Send tasks, check results, and route work to the right agent.

Sidecar Principle

This skill is strictly an OpenClaw sidecar — it talks TO the A2A API Gateway using the gateway's existing API format. The gateway's endpoints are the contract; OpenClaw is just a participant. Never assume what the other end looks like — it could be MC2, another OpenClaw, or anything else that speaks A2A. These scripts consume the gateway's API as-is.

Configuration

All scripts read from a shared a2a.conf file (located in this skill directory). The gateway URL must be configured before use — there are no hardcoded defaults.

Priority order: CLI flags → env vars → a2a.conf → auto-detected defaults

Run a2a-register/a2a-setup.sh to create your config interactively, or manually create a2a-client/a2a.conf:

A2A_GATEWAY_URL="http://YOUR_GATEWAY_IP:8090"
A2A_GATEWAY_API_KEY="your-key-here"
AGENT_SLUG="your-hostname"

If A2A_GATEWAY_URL is not set anywhere, scripts will exit with an error message.

When to Use

• Discover agents/providers — Before sending tasks, or when the user asks about available agents or LLM providers
• Send tasks — When delegating work to another agent via the gateway, or when another agent's capabilities are better suited
• Check task results — When tracking a previously sent task or retrieving completed results
• Route to specific agents — When a task should be handled by a particular A2A agent (use --target-agent)

Authentication

All scripts automatically obtain an admin JWT from the gateway (GET /v0/admin/bootstrap). The gateway uses this JWT for API authentication. No manual auth handling needed.

Tools

a2a-discover.sh — List Agents & Providers

./a2a-discover.sh [--gateway-url URL] [--api-key KEY]

Lists registered A2A agents and all configured LLM providers with their models. Use provider slugs as --agent values when sending tasks.

Always discover before sending a task to confirm the target exists and is online.

# List all agents and providers (uses a2a.conf)
./a2a-discover.sh

# Override gateway URL
./a2a-discover.sh --gateway-url http://GATEWAY_LAN_IP:8090

a2a-send-task.sh — Send a Task

./a2a-send-task.sh --agent <slug> --message "task description" \
  [--model auto] [--target-agent <slug>] [--session-id <id>] \
  [--gateway-url URL] [--api-key KEY]

Flag	Required	Default	Description
--agent	✅	—	Provider/agent slug (e.g., groq, ozore, mistral)
--message	✅	—	Task instruction/message body
--model	❌	auto	Model preference (e.g., groq/llama-3.3-70b-versatile)
--target-agent	❌	—	A2A agent routing hint (directs task to a specific registered agent)
--session-id	❌	auto	Custom session ID (auto-generated if omitted)
--gateway-url	❌	from config	Override gateway URL
--api-key	❌	from config	Override API key

# Send a task with auto model selection
./a2a-send-task.sh --agent groq --message "Analyze the Q3 sales data"

# Specific model
./a2a-send-task.sh --agent mistral --message "Draft a blog post" --model mistral/mistral-small-latest

# Route to a specific A2A agent
./a2a-send-task.sh --agent ozore --message "Refactor the auth module" --target-agent coder

# Custom session ID
./a2a-send-task.sh --agent groq --message "Check logs" --session-id my-session-001

a2a-get-task.sh — Check Task Status

./a2a-get-task.sh --task-id <id> [--gateway-url URL] [--api-key KEY]

Retrieves the current status and any results of a previously sent task. Shows task metadata, model used, token usage, and the LLM response.

./a2a-get-task.sh --task-id 0566802a3e6931629df5a7baaba2d797

Typical Workflow

1. Configure → Create a2a.conf or set A2A_GATEWAY_URL env var
2. Discover → ./a2a-discover.sh to find available providers and models
3. Send → ./a2a-send-task.sh --agent <slug> --message "..." to delegate work
4. Poll → ./a2a-get-task.sh --task-id <id> to check progress (tasks often complete synchronously)
5. Retrieve → Same get-task call returns results when completed

Environment Variables

Variable	Description
A2A_GATEWAY_URL	Gateway URL (required if not in a2a.conf)
A2A_GATEWAY_API_KEY	API key for task auth