Skip to main content
Glama

📖 Schreibgeschützter Spiegel. argus wird aus dem kanonischen AI-Factory-Monorepo veröffentlicht. Pull Requests werden nicht akzeptiert — jeder hier gepushte Commit wird beim nächsten Sync von scripts/mirror_satellites.sh überschrieben. 🐞 Einen Fehler gefunden oder einen Wunsch? Bitte ein Issue eröffnen.

ARGUS-3 — MCP-Server

🌐 English · Русский · Español · Français · 中文 · Glossar

Ein MCP-Server. WARDEN-gehärteter Agent. Wallet optional.

Transport: stdio (argus mcp). Gebaut mit dem offiziellen Model Context Protocol TypeScript SDK (@modelcontextprotocol/sdk). Kompatible Hosts: Claude Desktop, Cursor, Glama und jeder MCP-Client, der stdio-Server unterstützt.

Element

Ort

MCP-Einstiegspunkt

argus mcp → src/channels/mcp_server.ts

Tools

argus_ask, argus_status, argus_capabilities

WARDEN-Firewall

docs/security-warden.md

Glama / Docker (stdio)

Dockerfile.glama, glama.json

Teil der AICOM Open Agent Economy. Live-Demo: magic-ai-factory.com/argus/ · Community: Discord · Pollux · Telegram · Castor

MCP-Firewall zuerst — Wallet optional. ARGUS-3 prüft jeden Drittanbieter-MCP-Server durch WARDEN (statischer Scan → Threat-Feed → Herkunft → Def-Pinning), bevor auch nur ein einziges Tool läuft. Crypto, Wallet und On-Chain-Ökonomie sind standardmäßig deaktiviert. (Kurzname ARGUS · CLI: argus · npm: argus-warden · scoped: @alexar76/argus3)

Warum „ARGUS-3"? Im Mythos war Argus Panoptes — der hundertäugige Wächter — unschlagbar, bis Hermes ihn in den Schlaf redete und erschlug. ARGUS-3 ist der Wächter, der nicht auf Hermes hereinfällt: hundert offene Augen (WARDEN), bis zur Pedanterie sparsam, immun gegen schönredende Konkurrenz.

Beim dritten Mal ist es der Wächter. 👁️

ARGUS ist der nachfrageseitige Referenz-Client, der der Agenten-Ökonomie gefehlt hat. Das Ökosystem hat bereits Produzenten (die Factory 🏭), einen Broker (den Hub 🛒), Preise (ACEX 📈), Vertrauensmathematik (das LUMEN-Orakel 🔮) und Observability (den Monitor 👽). Was fehlte, war ein erstklassiger Agent, den ein normaler Mensch betreibt — einer, der Fähigkeiten entdeckt, bezahlt, konsumiert und verkauft. Das ist ARGUS.

Er basiert auf zwei Stack-Ebenen, die generischen MCP-Clients typischerweise fehlen:

  1. 🛡️ WARDEN — eine MCP-Sicherheits-Firewall, die Drittanbieter-Server prüft, bevor deren Tool-Definitionen das Modell überhaupt erreichen: ein gestufter statischer Scan, ein signierter Threat-Feed, eine Herkunftsprüfung und Tool-Def-Pinning gegen Rug-Pulls. Jedes Gate entscheidet auf Basis dessen, was ARGUS bereits lokal vorliegen hat. Funktioniert ohne Wallet und ohne Chain.

  2. 💸 Native Abwicklung (optional) — pro Aufruf zahlen und in USDC auf Base über AIMarket-Escrow bezahlt werden, wenn du Crypto aktivierst und ein Wallet verbindest.

…und er bleibt sparsam (ein harter Budget-Governor + Live-Token-Zähler — keine Selbstreflexion auf deine Kosten), spricht mit jedem Modell (Anthropic, OpenAI-kompatibel, chinesisch, lokal) und — entscheidend — läuft vollständig autonom, wenn die Ökonomie nicht verfügbar ist. Kein Wallet, kein Netzwerk zu AICOM? Er ist trotzdem ein erstklassiger lokaler, MCP-gesicherter Assistent.

🔒 Crypto ist standardmäßig AUS

Eine Blockchain ist nicht erforderlich, um ARGUS-3 zu betreiben. Wallet, Lotterie, ACEX, bezahlte Aufrufe und On-Chain-Abwicklung sind standardmäßig deaktiviert und werden nur aktiviert, wenn du ARGUS_CRYPTO_ENABLED=1 setzt (plus ein Wallet). Out of the Box erhältst du den vollständigen Agenten — WARDEN, jedes Modell, Speicher, Kanäle und kostenlose Off-Chain-Orakel- Abfragen — ohne Chain, ohne Token, ohne Wallet, ohne Verwahrung. Crypto ist Opt-in.


Warum ARGUS anders ist

Was es tut

Warum es wichtig ist

🛡️ WARDEN-Firewall

Jeder MCP-Server wird von einer Gate-Kette geprüft — statischer Tool-Def-Scan → Threat-Feed → Herkunft → Def-Pinning — bevor ein einziges Tool läuft.

Tool-Vergiftung, Rug-Pulls (Def-Drift), Exfiltration und Credential-Harvesting werden standardmäßig blockiert. Jedes Gate entscheidet auf Basis von Daten, die ARGUS bereits lokal vorliegen hat — die Prüfung braucht also kein Netzwerk, und nichts kann das Urteil aushebeln.

💸 Native + autonome Ökonomie

Entdecken → USDC-Kanal öffnen → aufrufen → abwickeln (Konsument); im Mesh registrieren → listen → verdienen (Anbieter). Lädt nur mit einem Wallet.

Macht AICOM zu einem echten zweiseitigen Markt. Ohne Wallet wird das Modul nie geladen — null Abhängigkeiten, null Fehlerfläche.

⚖️ Von Natur aus token-sparsam

Begrenzter Reasoning-Budget-Governor mit harten $-/Token-Obergrenzen, Modell-Tiering, cache_control, kuratierter Übergabe, Kompaktierung und einem Live-Zähler.

Die „günstiger"-Behauptung ist prüfbar, kein Marketing. Das Überschreiten einer Obergrenze stoppt die Aufgabe — es gibt nie stille Budgetüberschreitungen.

🌐 Jeder Anbieter

Eine Provider-Schnittstelle für Anthropic-nativ, jeden OpenAI-kompatiblen Endpunkt (inkl. DeepSeek, Qwen, GLM, Kimi…) und lokales Ollama.

Deine Schlüssel, deine Modelle, deine Kosten. Triage auf einem günstigen/lokalen Modell, nur bei Bedarf eskalieren.


🧭 Kernfunktionen — Designabsicht und Stack-Abhängigkeiten für jede Hauptfunktion — docs/killer-features.md · ru · es.

Related MCP server: re-angr

Schnellstart

Ein Befehl (interaktiver Assistent, ~2 Minuten):

curl -fsSL https://magic-ai-factory.com/install | bash

Oder von npm installieren (gleiche CLI, kein curl-Skript):

npm install -g argus-warden@latest
mkdir -p ~/.argus/agent && cd ~/.argus/agent
argus setup && argus doctor

Paket: argus-warden auf npm · scoped: @alexar76/argus3 · CLI: argus · npx argus-warden --help

Danach argus chat oder argus serve.

Als MCP-Server ausführen (stdio)

npm install -g @alexar76/argus3
# or: npm install && npm run build && node dist/index.js mcp
argus mcp

Claude Desktop / Cursor (mcpServers-Eintrag):

{
  "mcpServers": {
    "argus": {
      "command": "argus",
      "args": ["mcp"]
    }
  }
}

Tools (2)

Tool

Wann verwenden

Rückgabe

Beispiel

argus_ask

Begrenzte NL-Arbeit über den Agent-Kern. Optional response_format / focus. Sensible Tools verweigern standardmäßig; budgetgemessenes LLM.

Klartext-Antwort (isError bei Fehler/Budget-Stopp)

argus_ask({ task: "Summarise https://example.com in three bullets", response_format: "bullets" })

argus_status

Liveness-Check vor schwerem argus_ask (detail: basic|full)

JSON-Status

argus_status({ detail: "basic" })

argus_capabilities

Discovery / WARDEN-Posture ohne LLM-Token auszugeben

JSON-Tool-Katalog

argus_capabilities({ include_schemas: false })

Glama TDQS: MCP-annotations (readOnly / destructive / idempotent / openWorld), Verhaltens- und Nutzungsrichtlinien in jeder Beschreibung, strukturierte Parameter mit Beispielen — kalibriert auf die Score-Rubrik (nicht den alten Einzeiler).

Auf Glama veröffentlichen

Listing: glama.ai/mcp/servers/alexar76/argus

Gleiches Muster wie aimarket-oracle-gateway: Repo-Wurzel glama.json + Dockerfile.glama + node dist/index.js mcp.

Wenn magic-ai-factory.com/install 404 zurückgibt, verwende den Spiegel: curl -fsSL https://modeldev.modelmarket.dev/install | bash

Dokumentation: Wiki · Benutzerhandbuch (20 Sprachen) · Entwicklerhandbuch — eine Fähigkeit in 15 Minuten veröffentlichen (20 Sprachen) · Anwendungsfall — dein ARGUS auf AICOM (EN / RU) · Das überprüfbare Gewissen (Blockdiagramme) · Wann ARGUS dir nicht hilft 😈 · Ökosystem-Whitepaper

cd argus
npm install
npm run build

# 1) Configure (safe to commit — NO secrets live here)
cp argus.config.example.json argus.config.json

# 2) Add keys to .env (all optional; with none, ARGUS uses a local Ollama model)
cp .env.example .env      # then edit

# 3) Check what's wired up
node dist/index.js doctor

# 4) Ask something
node dist/index.js ask "summarise https://example.com in three bullets"

# 5) Interactive
node dist/index.js chat

Während der Entwicklung kannst du den Build-Schritt mit npm run dev -- ask "…" überspringen.

Die Autonomie-Garantie

ARGUS braucht nichts von AICOM, um zu funktionieren:

# No ANTHROPIC_API_KEY, no wallet — just a local model:
ARGUS_LOCAL_BASE_URL=http://127.0.0.1:11434/v1 node dist/index.js ask "hello"

Ohne ARGUS_WALLET_KEY meldet doctor economy: OFF (autonomous) und die gesamte Economy-Schicht wird nie konstruiert. Siehe docs/autonomy.md.


Architektur

Fünf Schichten. Alles oberhalb der Autonomie-Linie läuft offline; die Economy wird darunter angedockt, gesteuert allein durch das Vorhandensein einer Wallet.

flowchart TB
  subgraph OFF["Runs offline — no AICOM, no wallet"]
    L1["Layer 1 · Providers — Anthropic · OpenAI-compatible · local"]
    L2["Layer 2 · Bounded agent core — plan→execute→observe + budget governor"]
    L3["Layer 3 · Memory / self-learning — episodes · lessons · pins"]
    L4["🛡️ Layer 4 · MCP host + WARDEN — static · threat · origin · pinning"]
    L1 --- L2 --- L3 --- L4
  end
  GATE{{"— autonomy line — needs ARGUS_WALLET_KEY"}}
  L5["🛒 Layer 5 · Economy — discover · pay · invoke · settle · sell"]
  L4 -.-> GATE -.-> L5
  L5 -.->|wraps| SDK["@aimarket/agent SDK"]

Vollständige Diagramme und die Modulübersicht: docs/architecture.md.


🛡️ WARDEN — die MCP-Firewall

WARDEN wird separat als @aimarket/warden ausgeliefert — eine Bibliothek ohne Abhängigkeiten, die du vor deinen eigenen MCP-Host setzen kannst, ohne ARGUS zu übernehmen. ARGUS hängt von diesem Paket ab; dieser Abschnitt beschreibt, was es im Agenten tut.

Die Tool-Beschreibungen eines MCP-Servers sind angreiferkontrollierter Text, den das Modell als Anweisungen liest. WARDEN behandelt jeden Server als standardmäßig feindlich und führt jede Verbindung durch Gates, bevor ein Tool exponiert wird:

flowchart LR
  S[MCP server] --> A[1 · static scan] --> B[2 · threat feed] --> C[3 · origin] --> D[4 · def-pinning] --> V{allow?}
  V -->|yes| OK[bridge tools<br/>pin defs]
  V -->|no| NO[block + report]
  • Statischer Scan — Signaturen für Injection / Exfiltration / Secret-Harvesting / versteckte Unicode-Zeichen in Tool-Definitionen. Die Regeln sind gestuft: blockierende Regeln decken Formulierungen ohne harmlose Lesart ab; beratende Regeln (ein api_key-Parameter, eine .env-Erwähnung, ein „du musst") werden gemeldet, blockieren aber nie und beeinflussen nie den Score — das lässt ehrliche Server durch. Jedes Urteil nennt die Regelsatz-Version + den Digest, der es erzeugt hat.

  • Threat-Feed — eingebaute Deny-Liste + optionaler signierter Remote-Feed.

  • Herkunft — woher die Server-Deklaration stammt: du hast sie in mcp.servers aufgelistet, oder sie wurde aus einem entfernten mcp.catalogs-Eintrag entdeckt. Mit allowUnknownServers: false wird ein katalogentdeckter Server blockiert (SERVER_UNDECLARED); deine eigenen Deklarationen passieren immer, sodass Fail-Closed trotzdem einen Weg zum Verbinden lässt.

  • Pinning — hasht die genehmigte Tool-Menge; spätere Drift = Rug-Pull, erzwingt erneute Genehmigung.

Sensible Tools (write/delete/exec/payment/…) erfordern zusätzlich eine explizite Benutzer- Genehmigung zum Aufrufzeitpunkt. Details: docs/security-warden.md.

node dist/index.js warden scan      # vet your configured MCP servers

💸 Economy-Integration

ARGUS nutzt das bestehende AI Market Protocol v2 und das @aimarket/agent-SDK — keine neuen Endpunkte.

export ARGUS_WALLET_KEY=0x...                       # enables the economy layer
node dist/index.js economy status
node dist/index.js economy discover "translate to 5 languages" --budget 1
node dist/index.js economy register                 # list ARGUS in the AI Service Mesh

Consumer-Flow: discover → openChannel (USDC/Base) → invoke (X-Payment-Channel) → settle. Provider-Flow: Identität + Wallet im Mesh registrieren, Fähigkeiten auflisten, verdienen (und für die Agenten-Lotterie / Machine-UBI berechtigt werden). Siehe docs/economy-integration.md · docs/mcp-oracles-capabilities.md (17 Orakel, MCP, Verkauf).


Multi-Provider

Adapter

Abdeckung

Anthropic-nativ

Claude Opus/Sonnet/Haiku/Fable — erstklassiges cache_control; Standard für die Kernschleife

OpenAI-kompatibel

OpenAI, DeepSeek, Qwen/DashScope, Zhipu GLM, Moonshot/Kimi, MiniMax, Mistral, Groq, Together, OpenRouter, vLLM

Lokal

Ollama / llama.cpp — offline + die günstige Triage-Stufe

Modelle werden in argus.config.json Stufen zugeordnet (triage / core / heavy); das Routing fällt auf andere Stufen zurück, wenn ein Schlüssel fehlt.


🎮 Agent Arena — Level aufsteigen, Streaks halten, Karte zeigen

Einen Agenten zu betreiben sollte Spaß machen. Agent Arena verwandelt echte Ökosystem-Aktivität in die Spielmechaniken, die ein junges, globales Publikum bereits liebt — Duolingo-artige Streaks, Wrapped-artige teilbare Karten, Gaming-Rang-Karten:

  • XP & Level — verdiene XP für das Abschließen von Aufgaben, den Verkauf von Fähigkeiten, das Spielen der Orakel-Lotterie, den Handel auf ACEX und für Sparsamkeit (niedrige $/Aufgabe).

  • Tägliche Streaks 🔥 — halte deinen Agenten Tag für Tag aktiv.

  • Quests & Abzeichen — First Blood (erster Lotteriegewinn), Rainmaker (erste $1 durch den Verkauf von Fähigkeiten), Frugal (eine Aufgabe unter $0.001), Trusted (obere Hälfte der LUMEN-Reputation), Warden (einen bösartigen MCP-Server blockiert), Polyglot, Whale, Lucky… Trusted und der Reputationsrang sind heute nicht verdienbar: Ein LUMEN-Score braucht einen Vertrauensgraphen, und keine Bereitstellung veröffentlicht die Vertrauenskanten, nach denen ARGUS bewertet würde.

  • Flex-Karte — argus flex (oder /flex in Telegram) rendert eine schicke, teilbare Karte: Handle, Level, Streak, verdiente $, Gewinnrate, Top-Abzeichen, Reputationsrang (leer, bis ein Vertrauensgraph existiert). Zahlen + Emoji = keine Sprachbarriere → überall teilen.

  • Globales Leaderboard (Opt-in) — Rangliste gegen Agenten weltweit nach XP, Verdienst oder Sparsamkeit.

Jede Statistik ist echt — es ist deine tatsächliche Economy- und Sparsamkeits- Leistung, lokal berechnet aus dem eigenen Speicher deines Agenten + signierten Economy-Belegen, also schwer zu fälschen und keine Eitelkeitspunkte. Teilen und das Leaderboard sind standardmäßig aus und besitzerkontrolliert — deine Daten bleiben deine. Vollständiges Design: docs/arena.md.

Live-Demo (diese Flotte):

Nutze den TEST · LIVE · UNI-Schalter auf der Arena-Seite, um zwischen Demo-Metriken und jedem bereitgestellten Knoten zu wechseln.


Konfiguration

  • argus.config.json — nicht-geheime Konfiguration (Provider, Modelle, Stufenpreise für den Meter, Budget-Obergrenzen, WARDEN-Richtlinie, MCP-Server/Kataloge, Economy-Endpunkte). Sicher zu committen. Beginne mit argus.config.example.json.

  • .env — nur Geheimnisse: API-Schlüssel (ANTHROPIC_API_KEY, DEEPSEEK_API_KEY, …), ARGUS_WALLET_KEY und optional ALIEN_API_TOKEN für den Alien-Monitor-Run-Feed. Nie committen. Beginne mit .env.example.

economy.enabled wird abgeleitet — es ist genau dann wahr, wenn ARGUS_WALLET_KEY gesetzt ist.


Wo es im Ökosystem steht

aicom Factory baut Agenten → gelistet und aufgerufen über AIMarket (Hub + Protokoll) → Oracles (LUMEN-Vertrauen, Zufall, VDF, Konsens) bepreisen und sichern sie → finanziert auf ACEX → visualisiert von Alien Monitor.

ARGUS ist die Nachfrageseite: der Agent, der in diesem Markt ausgibt, verkauft und den Benutzer gegen die MCP-Lieferkette verteidigt — mit einer Firewall, die keines der oben genannten benötigt, um zu funktionieren.


Kanäle

Ein begrenzter Agentenkern, viele Kanäle — jeder mit dem für ihn natürlichen Auth-Modell. Vollständige Matrix + Design: docs/channels.md.

Kanal

Ausführen

Auth

CLI

argus ask / argus chat

lokal (interaktive Genehmigung)

Telegram

argus telegram

besitzer-gesperrt (erster /start beansprucht)

HTTP-API

argus serve

/health offen · POST /ask Bearer ARGUS_HTTP_TOKEN

MCP-Server

argus mcp

lokales stdio — exponiert argus_ask / argus_status / argus_capabilities

argus serve führt Telegram + den HTTP-Server zusammen aus (das ist es, was der Container ausführt). GET /health ist auch der Hook, der ARGUS als live Knoten in Alien Monitor erscheinen lässt. Setze ALIEN_MONITOR_URL + ALIEN_API_TOKEN, um jeden abgeschlossenen Run an das verifizierbare Run-Panel des Knotens zu pushen (Orakel-Aufrufe, WARDEN- Blöcke, Einstellungen, versiegelter Beleg). Discord, Slack, Email, Matrix, WhatsApp und Sprache sind sofort hinzufügbare Adapter (siehe Dokumentation).

Bereitstellung (Docker)

ARGUS startet nicht vertrauenswürdige MCP-Server als Kindprozesse, daher ist der Container auch eine Sicherheitsgrenze um sie — nicht nur Verpackung.

cp argus.config.example.json argus.config.json   # edit
cp .env.example .env                              # add secrets
docker compose up -d --build                      # serve: Telegram + HTTP /health

Geheimnisse kommen aus .env (nie ins Image eingebacken); argus.config.json wird schreibgeschützt gemountet; der Zustand bleibt im argus-state-Volume; ein HEALTHCHECK prüft /health. Economy ist im Container standardmäßig AUS (autonom).

Entwicklung

npm run typecheck     # tsc --noEmit (strict)
npm test              # vitest (budget governor, MCP host + WARDEN wiring, provider mapping)
npm run build         # emit dist/

Status

v0.1 — begrenzte Agentenschleife, Multi-Provider-Routing, WARDEN-Gate-Kette (statisch + Threat + Herkunft + Pinning), Speicher/Lektionen, MCP-Host, Economy-Consumer/Provider- Wrapper und vier Kanäle (CLI, Telegram, HTTP, MCP-Server) + Docker — alles implementiert und getestet. OS-Level-MCP-Sandboxing (seccomp/Landlock/sandbox-exec), der signierte Threat-Feed-Publisher und die restlichen Kanal-Adapter sind die v2- Spur — siehe die Dokumentation.

Demo

Verwandte Repos

Repo

Rolle

aicom

AI-Factory — liefert Fähigkeiten, die ARGUS konsumiert

aimarket-hub

Föderations-Hub — entdecken, aufrufen, abwickeln

oracles

LUMEN-Reputation + verifizierbare Mathematik

alien-monitor

ARGUS erscheint als live Graph-Knoten

dioscuri

Zwillings-Community-Agenten — MNEMOSYNE Q&A

Community

Die DIOSCURI-Zwillinge beantworten Fragen aus synchronisierten GitHub-Dokumenten.

Kanal

Zwilling

Am besten für

Discord

Pollux

Hilfe, Ideen, Show-and-Tell

Telegram

Castor

Veröffentlichungen, Digests, kurze Neuigkeiten

Ökosystem-Karte: Alien Monitor · AICOM

Lizenz

MIT — deine Schlüssel, deine Infrastruktur, deine Daten. Teil der AICOM offenen Agenten-Ökonomie.

Available Tools

3 tools
argus_askA

Run one bounded natural-language task through the ARGUS-3 agent and return the final answer text.

When to use: research, summarise, debug, or draft when you want a WARDEN-hardened agent (not a raw model completion). Prefer argus_status first if you only need liveness; prefer argus_capabilities for the tool/WARDEN catalog without spending LLM tokens.

When NOT to use: interactive multi-turn chat (use Telegram/HTTP channels); tasks that need human approval for sensitive tools (stdio denies them); pasting secrets into task.

Side effects / auth / limits: calls your configured LLM provider (API key from env/config); may invoke ARGUS-configured tools; third-party MCP tools run only after WARDEN gates (static scan → threat feed → LUMEN → def-pinning). Sensitive tools are deny-by-default on this channel (no interactive approver). Spend is bounded by ARGUS budget ceilings (stops rather than overspending). Not idempotent — each call is a new metered run. May use network (model + allowed tools).

Returns: plain-text final answer. On failure or budget stop, text may still be returned with isError true. No streaming / partial events on this tool.

Example: argus_ask({ task: "Summarise https://example.com in three bullets", response_format: "bullets" })

NameRequiredDescriptionDefault
taskYesRequired. Single clear goal for ARGUS (1..8000 chars). Include constraints (length, format, tone) and any URLs/paths. Do not embed secrets (API keys, private keys, passwords) — they may be logged or sent to the LLM provider. Whitespace-only values are rejected.
focusNoOptional one-line emphasis (≤500 chars) appended as a constraint, e.g. "security only" or "ELI5". Omit when the task is already specific enough.
response_formatNoOptional output shape hint prepended to the task. `prose` = normal paragraphs; `bullets` = short bullet list; `json_hint` = ask for a single JSON object in the answer (still returned as text — not a structured MCP outputSchema result). Default prose when omitted.prose

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond annotations: calls configured LLM provider, may invoke ARGUS tools, third-party MCP tools gated by WARDEN, sensitive tools deny-by-default, spend bounded by budget, not idempotent, may use network. No contradiction with annotations (readOnlyHint=false, etc.).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized: a summary line, usage guidelines, side effects/auth/limits, return type, and an example. Every sentence is informative without redundancy. It is concise and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (agent with multiple options) and lack of output schema, the description thoroughly covers input semantics, behavioral nuances, budget limits, and return type (plain-text with potential isError). No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all three parameters (100% coverage). The description adds extra meaning: for 'task', warns against embedding secrets and specifies length constraints; for 'focus', explains it's appended as constraint; for 'response_format', defines each enum value. This provides clarity beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run one bounded natural-language task through the ARGUS-3 agent and return the final answer text.' It uses a specific verb (run) and resource (bounded natural-language task via ARGUS-3). It also distinguishes from siblings by noting when to use argus_status or argus_capabilities instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when-to-use examples (research, summarise, debug, draft) and when-not-to-use cases (interactive multi-turn chat, tasks needing human approval, pasting secrets). It also mentions alternative tools: argus_status for liveness and argus_capabilities for catalog.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

argus_capabilitiesA
Read-onlyIdempotent

List ARGUS MCP tools and WARDEN security posture as JSON text (no LLM call).

When to use: discovery — choose between argus_ask / argus_status / this catalog. When NOT to use: executing a user task (argus_ask) or a cheap ping (argus_status).

Side effects: none. Read-only, idempotent, no provider auth required for this tool.

Returns: JSON { agent, version, tools[{name, readOnly, summary}], warden, sensitiveToolsPolicy, channel }.

Example: argus_capabilities({ include_schemas: false })

NameRequiredDescriptionDefault
include_schemasNoIf true, include each tool's inputSchema in the JSON (larger payload). Default false — names + short summaries only.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds behavioral context beyond annotations: 'no LLM call', 'no provider auth required', 'Read-only, idempotent', and return format. Annotations already state readOnlyHint, idempotentHint, destructiveHint; description reinforces and expands without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise and well-structured: purpose, usage guidance, side effects, return format, example. Every sentence adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking output schema, description fully specifies return JSON structure. All relevant behavioral aspects are covered given tool simplicity and rich annotations. No gaps for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage for the single boolean parameter, including description and example. Description adds an example call but no new semantics beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly lists purpose: 'List ARGUS MCP tools and WARDEN security posture as JSON text'. It distinguishes from siblings by mentioning argus_ask (task execution) and argus_status (cheap ping). Verb 'List' and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'When to use: discovery' and 'When NOT to use: executing a user task or a cheap ping', with alternatives named (argus_ask, argus_status). Provides clear decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

argus_statusA
Read-onlyIdempotent

Return ARGUS-3 MCP runtime status as JSON text (no LLM call, no side effects).

When to use: before heavy argus_ask calls, or to confirm version/channel/tools. When NOT to use: to run a task (use argus_ask) or to list WARDEN policy detail (use argus_capabilities).

Auth / limits: none beyond MCP session. Idempotent and read-only.

Returns: JSON with status, agent, version, channel, mode, tools, detail, wardenNote, sensitiveToolsPolicy (and extra fields when detail=full).

Example: argus_status({ detail: "basic" })

NameRequiredDescriptionDefault
detailNoResponse depth. `basic` = liveness + version + tool names. `full` adds instructions excerpt, annotation summary, and MCP transport notes. Default basic.basic

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'no LLM call', 'no side effects', 'Auth/limits: none beyond MCP session', and details return fields. Consistent with annotations, adds useful context beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is brief, front-loaded with purpose, uses clear section breaks (When to use, Auth, Returns, Example), and every sentence adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 optional param, no output schema, high annotation coverage), description covers purpose, usage, behavior, auth, return fields, and example. Fully sufficient for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with full description of detail parameter. Description includes example and mention of full depth adding fields, but schema already explains enum values and default. Minimal added value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States explicit verb 'Return ARGUS-3 MCP runtime status as JSON text', names specific resource 'ARGUS-3 MCP runtime', and distinguishes from siblings by contrasting with argus_ask and argus_capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('before heavy argus_ask calls, or to confirm version/channel/tools') and when not to use ('to run a task' or 'list WARDEN policy detail'), naming alternatives (argus_ask, argus_capabilities).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.2.5
    • Changedargus_ask7 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / focus
        Added value: +{
        +  "description": "Optional one-line emphasis (≤500 chars) appended as a constraint, e.g. \"security only\" or \"ELI5\". Omit when the task is already specific enough.",
        +  "examples": [
        +    "security only",
        +    "cite sources"
        +  ],
        +  "maxLength": 500,
        +  "type": "string"
        +}
      • addedInput schema / properties / response_format
        Added value: +{
        +  "default": "prose",
        +  "description": "Optional output shape hint prepended to the task. `prose` = normal paragraphs; `bullets` = short bullet list; `json_hint` = ask for a single JSON object in the answer (still returned as text — not a structured MCP outputSchema result). Default prose when omitted.",
        +  "enum": [
        +    "prose",
        +    "bullets",
        +    "json_hint"
        +  ],
        +  "examples": [
        +    "bullets",
        +    "prose"
        +  ],
        +  "type": "string"
        +}
      • changedInput schema / properties / task / description
        Previous value: -"The task or question for ARGUS."New value: +"Required. Single clear goal for ARGUS (1..8000 chars). Include constraints (length, format, tone) and any URLs/paths. Do not embed secrets (API keys, private keys, passwords) — they may be logged or sent to the LLM provider. Whitespace-only values are rejected."
      • addedInput schema / properties / task / examples
        Added value: +[
        +  "Summarise https://example.com in three bullets",
        +  "Explain why WARDEN would block a tool whose description asks for API keys",
        +  "Draft a short README blurb for an MCP server that exposes argus_ask"
        +]
      • addedInput schema / properties / task / maxLength
        Added value: +8000
      • addedInput schema / properties / task / minLength
        Added value: +1
    • Addedargus_capabilities
    • Addedargus_status
  2. 1 tool updatev1.0.0
    • First observedargus_ask

TDQS

A4.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool maps to a distinct intent: argus_status is liveness/version, argus_capabilities is catalog/security discovery, and argus_ask is task execution. Status and capabilities share some metadata fields, but their explicitly stated when-to-use guidance cleanly separates them. Ask is unambiguously the only tool that runs a task.

Naming Consistency3/5

All names share the argus_ prefix and snake_case, but the set mixes noun-style names (argus_status, argus_capabilities) with a verb-style name (argus_ask). There is no consistent verb_noun pattern across the set. The prefix keeps it readable, but the conventions are not uniform.

Tool Count5/5

Three tools is a well-scoped, typical count for this narrow purpose: one execution tool and two read-only introspection tools. Each tool earns its place and there is no redundancy. The size fits the server's focused role well.

Completeness5/5

The set covers the full intended workflow: confirm runtime status, discover capabilities and security posture, then execute a bounded task. There are no obvious gaps or dead ends for the stated one-shot agent use case. Multi-turn and interactive flows are explicitly out of scope rather than missing coverage.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers