Discovery Endpoints
AIsa exposes the following public URLs for agent and documentation discovery. They require no authentication to read.How Agent Discovery Works
The discovery flow follows four steps: discover, connect, inspect, and invoke. An autonomous agent starts by reading the agent setup guide and the agent card to learn what AIsa can do, connects over MCP, inspects the exact tool contracts, and invokes quoted calls. Direct HTTP with an API key is the documented fallback for code that cannot speak MCP.1
Discover
The agent reads the agent setup guide and fetches
/.well-known/agent-card.json from aisa.one. The card contains a list of skills, each with an id, name, description, tags, and examples. The agent uses this metadata to determine whether AIsa can fulfill the current task.2
Connect (MCP + OAuth, the primary flow)
The agent adds
https://mcp.aisa.one/mcp as a remote MCP server and signs in with browser OAuth; there is no key to paste. Clients without a browser send Authorization: Bearer $AISA_API_KEY in the MCP config instead. It then verifies the connection with one free protected call: the account operation (or use with {"operation_id": "account"}). A tool list or a 401 does not count. See Connect via MCP.3
Inspect
Over MCP,
search returns candidate tools with their exact name, arguments schema, and list price, and batch_get_schema (also served as get_details) returns the full contract for up to 20 tools. The HTTP fallback fetches /openapi.yaml instead: parameter types, required fields, authentication requirements, and declared pricing.4
Invoke
Over MCP, the agent prices the exact calls with
batch_quote and runs them with batch_use, following the spending rule in the agent setup guide (auto-run when the quote reports auto_execute_eligible: true, otherwise one approval message with the quoted total). The HTTP fallback sends the request to api.aisa.one with Authorization: Bearer $AISA_API_KEY and follows the stricter direct HTTP rule; selected read-only endpoints also accept MPP payment instead of a key.The A2A Agent Card
The Agent2Agent (A2A) Protocol defines a standard format for agents to advertise capabilities and interoperate. AIsa’s agent card lives at the well-known URL and describes the platform, authentication requirements, and public capability catalog.Fetching the Agent Card
Agent Card Structure
The top-level fields describe the agent identity, authentication, and capabilities:Skill Objects
Each entry in theskills array describes a single capability:
Available capabilities
The Agent Card is generated from the public catalog. Fetch the live card instead of relying on a fixed capability list in documentation:description, tags, and examples for matching. Confirm the underlying Skill or API documentation before invocation.
The OpenAI Plugin Manifest
For backward compatibility with agent frameworks that implement the original ChatGPT plugin protocol, AIsa also publishes anai-plugin.json manifest at /.well-known/ai-plugin.json. The manifest references the same OpenAPI spec. For current OpenAI tool integration guidance, see Actions.
description_for_model field that lists key API endpoints, helping LLM-based agents understand which tools are available without parsing the full OpenAPI spec.
The OpenAPI 3.1 Specification
The consolidated OpenAPI spec at/openapi.yaml is the authoritative machine-readable contract for constructing API requests. Parse the live specification instead of relying on a fixed path or schema count.
Fetching and Parsing the Spec
API Categories
The spec organizes endpoints into the following tag groups:End-to-End Integration Example (HTTP fallback)
Agents that can speak MCP follow the connect, inspect, and invoke steps above with thesearch, batch_get_schema, batch_quote, and batch_use tools. The following Python example is the HTTP fallback for code that cannot: the agent discovers AIsa’s capabilities, identifies the chat-completions skill, and makes an authenticated API call. Before a paid call, apply the approval rule in the agent setup guide and the direct HTTP rule.
Authentication
Agents connected through MCP authenticate with browser OAuth, so there is no key to handle; clients without a browser setAuthorization: Bearer $AISA_API_KEY in the MCP config. The HTTP fallback uses the same Bearer token on every request to api.aisa.one:
GET /v1/models is only a transport check; it does not prove authenticated business access. Verify with a free protected call (account over MCP, aisa balance with the CLI).
Generate an API key from the AIsa console. For detailed key management guidance — scoping, rotation, and secure storage — see the Authentication guide.
Integration Patterns
Pattern 1: Tag-Based Skill Matching
Agents can match tasks to skills using thetags array. This is the recommended approach for agents that need to dynamically select capabilities at runtime.
Pattern 2: Example-Based Intent Matching
For LLM-powered agents, theexamples field provides natural-language queries that can be used for semantic similarity matching against the user’s intent.
Interactive Explorer
AIsa provides two browser-based tools for exploring the discovery surface:- API Explorer — Interactive API reference for browsing documented endpoints and request/response examples.
- Agent Discovery — Visual skill explorer with search and tag filtering, plus integration code examples.
CORS Support
The discovery endpoints include permissive CORS headers (Access-Control-Allow-Origin: *) so that browser-based agents and web applications can fetch them directly without a proxy server. This applies to:
/.well-known/agent-card.json/.well-known/ai-plugin.json/openapi.yaml
Related
Authentication
API key generation, scoping, rotation, and secure storage.
Agent Skills
Browse and install composable skills for Claude Code, Cursor, and OpenClaw.
Getting Started
Make your first authenticated API request in minutes.