Yasin-MCP

Standalone, KI-/Agenten-orientierte MCP-Zugriffs- und Integrationsschicht (Model Context Protocol) für das Yasin-Ökosystem.

Mission

Yasin-MCP bietet über das MCP-Protokoll schreibgeschützten, strukturierten Zugriff auf Informationen des Yasin-Ökosystems (Projektregister, Dokumentation, GitHub-Repository-Zustand, Laufzeitdiagnose), sodass KI-Agenten und MCP-Clients den Zustand des Ökosystems abfragen können, ohne direkten, uneingeschränkten Zugriff auf ein einzelnes Repository oder einen Dienst zu benötigen.

Related MCP server: conda-meta-mcp

Status

Nur Phase 0, Issue #1 (Repository-Bootstrap und technische Grundlage). Es existiert noch keine MCP-Server-Laufzeit. Es existiert noch kein Domänenadapter (YASIN-DOCS, GitHub, Yasin-Operations). Dieses Issue legt lediglich die Paketstruktur, die Werkzeuge und die Sicherheitsprimitive (Fehlermodell, Deny-by-default-Richtlinie, Geheimnisbehandlung) fest, auf denen alles Weitere aufbauen wird.

Ein Hinweis zur Herkunft der Architektur

Die ursprüngliche Aufgabenbeschreibung für dieses Projekt besagt, dass YASIN-DOCS „die kanonische Architektur und Grenze“ für Yasin-MCP ist. Eine direkte Überprüfung des Repositorys yusi20006-max/YASIN-DOCS (sowohl eine Codesuche nach „Yasin-MCP“/„MCP“ als auch eine direkte Prüfung von PROJECT_REGISTRY.yaml und ECOSYSTEM.md) ergab keinerlei Erwähnung von Yasin-MCP in diesem Repository zum Zeitpunkt dieses Issues.

Das bedeutet, dass die hier implementierte Architektur direkt aus den Beschreibungen der Issues #1–#10 dieses Projekts abgeleitet ist (die detailliert und in sich konsistent sind), nicht aus einem YASIN-DOCS-Dokument, das derzeit nicht existiert. Falls/wenn YASIN-DOCS aktualisiert wird, um Yasin-MCP aufzunehmen, sollte dies zur Quelle der Wahrheit werden, und dieser Hinweis sollte entfernt oder aktualisiert werden, um den neuen Ort widerzuspiegeln.

Architekturgrenze

• Yasin-MCP ersetzt nicht YASIN-DOCS, Yasin-Core, Yasin-Agent, Yasin-AI, YasinHub, YasinCLI oder Yasin-Operations.

• Phase 1 ist strikt schreibgeschützt: keine Repository-Mutation, keine Bereitstellung, keine Lebenszyklus-Mutation (Start/Stopp/Neustart), keine Speicher-Mutation, keine beliebige Shell-/Befehlsausführung.

• Keine privaten repositoryübergreifenden Importe. Integrationen nutzen öffentliche APIs, SDKs, Verträge oder explizite schreibgeschützte Adapter.

• Bestehende Yasin-Projekte dürfen nicht von Yasin-MCP abhängig werden.

• Eine Deny-by-default-Richtliniengrenze (policies/policy.py) lehnt jede Fähigkeit ab, deren Name einem verbotenen Muster entspricht (exec, shell, command, request, arbitrary, filesystem, deploy, delete, start_/stop_/restart_) oder die sich selbst als mutierend deklariert, während Phase 1 in Kraft ist – durchgesetzt zur Konstruktionszeit, nicht erst bei der Registrierung.

Paketstruktur

src/yasin_mcp/
    server/        MCP server runtime (Issue #4)
    protocol/       MCP protocol types/boundary (Issue #2)
    capabilities/   capability descriptor + discovery (Issue #2)
    tools/          MCP tool implementations (Issue #4+)
    resources/      MCP resource implementations (Issue #4+)
    adapters/       domain adapters: YASIN-DOCS, GitHub, Yasin-Operations (Issue #5-7)
    policies/       deny-by-default policy boundary
    errors/         structured error model (McpError + ErrorCategory)
    audit/          structured logging, correlation IDs
    config/         configuration model, secret handling
    version.py      package version, EvidenceStatus enum

Evidenzmodell

Antworten, die den Zustand des Ökosystems melden, sollten Informationen mit einem der folgenden Werte kennzeichnen:

• CONFIRMED — direkt von einer live, autoritativen Quelle beobachtet

• TARGET — dokumentierte Absicht/Architektur, nicht gegen ein laufendes System verifiziert

• PROPOSED — ein Vorschlag oder Plan, noch nirgendwo implementiert

• UNRESOLVED — konnte nicht ermittelt werden; darf nicht als Tatsache dargestellt werden

Entwicklung

pip install -e ".[dev]"
pytest
ruff check .
ruff format --check .
mypy src
bandit -q -r src