argus
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 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" }) |
| argus_statusA | 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" }) |
| argus_capabilitiesA | 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 }) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
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.
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.
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.
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.