DS DevShelfHub Projects · AI tools
Tutorials / CrewAI / Reference / Classes / A2AServerConfig
Class a2a

A2AServerConfig: Reference Guide

By DevShelfHub

Configures exposing a CrewAI agent as an A2A server — agent card, auth, transports.

See the CrewAI API reference index, CrewAI introduction, and MCP & A2A tutorial for surrounding context.

What is A2AServerConfig?

A2AServerConfig is the inbound mirror of A2AClientConfig: it describes how your CrewAI agent should present itself on the network so other crews or platforms can discover it, authenticate, and invoke it over A2A. The object usually carries inbound auth (so only trusted callers reach your agent), bind metadata such as host and port for the HTTP stack, and hooks for publishing an agent card that downstream clients consume before the first real request.

Operationally you treat this config like any other server surface area: TLS termination may live in front of the bind address, auth should map cleanly onto your identity provider, and logging should record fingerprint-level identifiers rather than raw API keys. Because A2A is a contract between processes, document the URL you expose, the auth modes you support, and the CrewAI version that backs the server so remote A2AClientConfig instances can be configured without guesswork.

When to Use

Exposing a CrewAI agent or crew entrypoint to other systems via A2A, including partner integrations and internal service meshes.

Use Cases

  • • Multi-tenant SaaS agents
  • • Sharing agents across teams
  • • Inbound partner automation

Key Features

  • ✓ Agent card publishing
  • ✓ Pluggable inbound auth
  • ✓ Bind-oriented deployment knobs

When NOT to Use

Pure in-process Python orchestration where no external caller exists — Flows and Crew alone are simpler.

Notes

Trust boundaries

Inbound auth on A2AServerConfig is your first line of defense. Combine it with network policies — private listeners, allowlisted IPs, or mutual TLS at the edge — so a leaked API key alone cannot expose the whole agent surface.

Agent card accuracy

Remote clients cache agent cards. When you change tools, model tiers, or supported transports, bump a visible version or redeploy in a way that forces clients to refresh. Stale cards cause confusing 400-series errors that look like bugs in the client.

Logging without leaking secrets

Log connection outcomes and authenticated principal identifiers, never raw Authorization headers or API key values. Pair with SecurityConfig-style redaction if logs are centralized.

Install surface

Server-side A2A support also depends on the `crewai[a2a]` extra. Keep versions synchronized with any SDK or gateway that fronts this server so schema and error codes stay compatible.

Import

python 
from crewai.a2a import A2AServerConfig

Key Parameters

Parameter Type Default Purpose
auth AuthConfig — Inbound auth implementation.
host / port str / int — Bind address.

Code Examples

API key gate on a LAN bind

python 
import os
from crewai.a2a import A2AServerConfig
from crewai.a2a.auth import APIKeyAuth

cfg = A2AServerConfig(
    auth=APIKeyAuth(key=os.environ['INBOUND_A2A_KEY']),
    host='0.0.0.0',
    port=8080,
)

Bearer validation for OAuth-issued tokens

python 
import os
from crewai.a2a import A2AServerConfig
from crewai.a2a.auth import BearerTokenAuth

cfg = A2AServerConfig(
    auth=BearerTokenAuth(token=os.environ['STATIC_VALIDATION_TOKEN']),
    host='127.0.0.1',
    port=9000,
)

Behind TLS termination (reverse proxy)

python 
import os
# Bind locally; public URL and TLS live on nginx / Envoy in front.
from crewai.a2a import A2AServerConfig
from crewai.a2a.auth import APIKeyAuth

cfg = A2AServerConfig(
    auth=APIKeyAuth(key=os.environ['EDGE_SHARED_SECRET']),
    host='127.0.0.1',
    port=8765,
)
# Document externally: https://agents.mycompany.com/a2a/crew-support

Common Mistakes

❌ Binding `0.0.0.0` in development and shipping the same default to production without auth

✅ Always set strong inbound auth and restrict exposure; use localhost binds during local dev.

❌ Documenting only an internal Docker service name as the public A2A URL

✅ Publish the externally reachable HTTPS origin that matches TLS certificates and client A2AClientConfig.base_url.

A2AServerConfig FAQ

What is A2AServerConfig in CrewAI?

Configures exposing a CrewAI agent as an A2A server — agent card, auth, transports. A2AServerConfig is the inbound mirror of A2AClientConfig: it describes how your CrewAI agent should present itself on the network so other crews or platforms can discover it, authenticate, and invoke it over A2A. The object usually carries inbound auth (so only trusted callers reach your agent), bind metadata such as host and port for the HTTP stack, and hooks for publishing an agent card that downstream clients consume before the first real request. Operationally you treat …

Which package defines the CrewAI class A2AServerConfig?

DevShelfHub maps A2AServerConfig to Python module crewai.a2a (package path crewai.a2a in this reference). Pin your installed crewai version and match imports to the snippet on this page.

When should I use A2AServerConfig?

Exposing a CrewAI agent or crew entrypoint to other systems via A2A, including partner integrations and internal service meshes.

When should I avoid using A2AServerConfig?

Pure in-process Python orchestration where no external caller exists — Flows and Crew alone are simpler.

How do I import A2AServerConfig in Python?

from crewai.a2a import A2AServerConfig

Where can I explore more CrewAI API reference pages?

Open the CrewAI API reference index on DevShelfHub to search 58 classes, 30 methods, and 16 decorators, each with runnable examples, parameters, common mistakes, and cross-links.