tamag0
FR
Documentation

Agent access

View Markdown llms.txt llms-full.txt

How an external AI agent discovers tamag0, requests invite-only access on behalf of its human, and what happens next.

tamag0 is invite-only. This guide is the human-readable companion to the machine-readable discovery documents published on api.tamag0.ai and tamag0.ai — it explains the same contract in prose.

Discovery

An agent can find tamag0's capabilities through any of these entry points:

  • Agent Skills index — https://tamag0.ai/.well-known/agent-skills/index.json, listing the join-tamag0-waitlist skill.
  • MCP Server Card — https://api.tamag0.ai/api/v1/public/mcp/server-card (also mirrored at https://tamag0.ai/.well-known/mcp/server-card.json).
  • API Catalog — https://api.tamag0.ai/.well-known/api-catalog, an RFC 9727 linkset pointing at the public OpenAPI document and this page.
  • /auth.md — https://api.tamag0.ai/auth.md, a pre-access guide covering the same facts below.

None of these documents enumerate authenticated tools, tenant data, or administrative operations. They describe exactly one anonymous capability: requesting access.

Requesting access

  1. The agent's human explicitly consents to sharing their email address with tamag0.
  2. The agent connects to the public MCP server at https://api.tamag0.ai/api/v1/public/mcp (Streamable HTTP) and invokes the request_access tool once, with the human's email and an explicit consent_attested: true. A plain HTTP equivalent exists at POST https://api.tamag0.ai/api/v1/public/request-access for agents without MCP transport.
  3. tamag0 returns the same generic, localized acknowledgement whether the address is new or already on the waitlist — the response never reveals which.
  4. The agent relays that acknowledgement to its human and stops. There is no status check, polling operation, or tracking identifier to retain.
  5. The human watches their inbox. An administrator reviews the request through the existing waitlist workflow, exactly as for a request submitted through the website.

What this is not

  • Not mailbox verification. consent_attested records that the agent's human authorized the transmission — it does not prove the human controls the mailbox.
  • Not account creation. Requesting access creates a pending waitlist entry, nothing else: no token, no session, no tenant.
  • Not a bypass of administrator approval. Every request — agent-submitted or website-submitted — waits for the same human review before an invitation is sent.
  • Not authenticated MCP access. The public signup server exposes exactly one tool. It shares no code path with the authenticated MCP server behind /mcp, which remains reachable only after activation.

After an invitation arrives

Once an administrator approves the request and the human activates their account, authenticated access follows the existing OAuth flow. Its metadata is canonical on the API origin and is not duplicated here:

  • Authorization Server metadata (RFC 8414): https://api.tamag0.ai/.well-known/oauth-authorization-server
  • Protected Resource metadata (RFC 9728): https://api.tamag0.ai/.well-known/oauth-protected-resource

Privacy

Agent-submitted requests are covered by the Privacy Policy, including the source and framework recorded with the request, the consent attestation, retention, and how to ask for deletion.