A202 MCP Server

A202: o Protocolo de Acordo Verificável para Comércio Conduzido por Agentes

Status: Informativo na íntegra.

A202 é comércio verificável para transações agente-a-agente ou conduzidas por agentes: uma especificação aberta de autoridade comercial, estado de negociação e conformidade verificável para transações entre organizações independentes, incluindo transações realizadas em seu nome por agentes de software.

Define objetos tipados para autoridade comercial delegada, uma máquina de estados para a transação e para cada sessão bilateral dentro dela, regras sobre o que pode ser divulgado a quem, e uma suíte de conformidade executável que transforma cada um desses em uma verificação que uma implementação passa ou falha.

A declaração completa de propósito, escopo e não-objetivos está em CHARTER.md.

Criado e desenvolvido por A. A. Musse. Consulte MAINTAINERS.md.

Status

Lançado, pré-1.0.

• v0.1.0 é o primeiro lançamento com tag do conjunto: uma tag, um digest para cada arquivo de esquema, o manifesto de conformidade e notas de lançamento, publicados juntos. Consulte RELEASES.md e CHANGELOG.md. Antes da 1.0, um incremento MINOR pode quebrar compatibilidade, e qualquer quebra traz notas de migração.
• O nome é A202, pronunciado "A dois-zero-dois", e por extenso A202, o Protocolo de Acordo Verificável para Comércio Conduzido por Agentes. A forma longa é um descritor e não uma expansão: as letras não a representam. O 202 é HTTP 202 Accepted, que A202-0017 torna o status que uma submissão aceita retorna, porque aceitação é o primitivo sobre o qual o restante da especificação é construído. O prefixo de código de motivo A202-, os identificadores de proposta A202-NNNN e a string de versão da especificação a202-commercial/0.1 todos derivam do nome.
• A202™ é uma marca registrada da Plural Worlds. O uso permitido do nome está declarado em TRADEMARK.md.
• Os valores de $id do esquema resolvem sob https://schemas.a202.org. Os hosts de fixtures usam nomes reservados de .invalid, porque dados de teste nunca devem resolver.
• Licenciado sob a Apache License, Versão 2.0. Uma licença cobre todo o repositório: texto da especificação, esquemas, fixtures, manifesto, executor e documentos informativos. A licença inclui uma concessão expressa de patente de cada contribuidor. Consulte LICENSE e CONTRIBUTING.md.
• Contribuições externas são aceitas nos termos de CONTRIBUTING.md: contribuições recebidas sob a mesma licença, com assinatura de certificado de origem do desenvolvedor.

Layout

Caminho	Conteúdo
CHARTER.md	Propósito, escopo, não-objetivos, princípios de design
GOVERNANCE.md	Como o projeto é administrado, e o que o patrocinador controla e não controla
MAINTAINERS.md	Quem mantém este repositório
CONTRIBUTING.md	Status de contribuição e os termos sob os quais uma contribuição é aceita
SECURITY.md	Divulgação coordenada privada
THREAT-MODEL.md	Adversários assumidos, propriedades defendidas e o que deliberadamente não é defendido
CODE_OF_CONDUCT.md	Conduta esperada
TRADEMARK.md	O nome A202 e o que é e não é permitido em seu uso
RELEASES.md	Versionamento, em que consiste um lançamento, política de compatibilidade
CHANGELOG.md	O que mudou e onde as notas de lançamento exigidas por RELEASES.md se acumulam
.github/	Roteamento de revisão, formulários de pull request e issue, e o workflow que executa a suíte em cada mudança
proposals/	O processo de proposta de mudança A202
schemas/	Modelo comercial canônico, modelo de extensão de perfil de transação e os esquemas JSON
authority/	Mandato comercial: autoridade delegada, restrições, delegação, aprovação, revogação
discovery/	Convite de contraparte: como uma parte não registrada entra em uma transação nomeada
negotiation/	Máquinas de estado de transação e sessão, e semântica de eventos de leilão
conformance/	Fixtures, manifesto, executor normativo e definições de graus de conformidade

Cada documento de especificação traz um cabeçalho de status declarando quais de suas seções são normativas e quais são informativas.

Executando a suíte de conformidade

O executor valida cada fixture nomeado no manifesto contra os esquemas e, em seguida, aplica os invariantes que o JSON Schema não consegue expressar. Validade de esquema não é conformidade, e é por isso que o executor existe.

Ele precisa de jsonschema>=4.18. Se isso não estiver no interpretador do sistema, um ambiente virtual é suficiente:

python3 -m venv .venv && .venv/bin/pip install "jsonschema>=4.18"

Execute-o a partir da raiz do repositório:

python3 conformance/run-conformance.py --verbose

O resultado esperado é que cada fixture passe e nenhum falhe, com os totais que o manifesto carrega: o manifesto é a fonte única para a contagem, e o executor a imprime a cada execução. O executor também verifica que cada fixture negativo é recusado pelo código de motivo que o manifesto declara para ele, sempre que a camada normativa levanta códigos. Execute-o antes e depois de qualquer mudança de esquema.

Cada fixture negativo é mínimo: remover o único elemento ofensor deve deixar um documento que valida limpo. Um fixture negativo que falha por um motivo incidental não testa nada, então verifique isso ao adicionar um.

A suíte não depende de ninguém lembrar de executá-la. Ela roda, junto com os testes da implementação de referência e os testes do servidor MCP, em cada pull request e em cada push para o branch padrão, sob .github/workflows/checks.yml. GOVERNANCE.md seção 3.4 exige que a suíte passe para qualquer mudança em esquemas, fixtures, manifesto ou executor, e esse workflow é o que transforma o requisito em um portão.

Por onde começar a ler

1. CHARTER.md para o que isto é e o que deliberadamente não é.
2. schemas/canonical-commercial-model-v0.1.md para o modelo de objetos, o envelope e os invariantes que a validação de esquema não consegue expressar.
3. negotiation/pilot-transaction-state-machine-v0.1.md para o que move o estado e o que não move.
4. conformance/manifest-v0.1.json para os fixtures que decidem se uma implementação concorda com qualquer um dos itens acima.