Skip to main content
Glama
Sign In
Smart Quota Orchestrator

Smart Quota Orchestrator

by ElNeMeR70
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sqo_drift_guard

Cross-checks environment variable references in code against .env.example to detect config drift and prevent production boot crashes.

Instructions

Environment Variable & Config Drift Detector (v11.0 Hypernova): cross-checks all process.env, os.getenv, env(), and String.fromEnvironment references in code against .env.example to prevent production boot crashes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace": "<workspace>"
    },
    "name": "sqo_drift_guard"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceYesWorkspace root directory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv13.0.0

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations at all, the description must carry the whole disclosure burden. It explains the comparison being performed but never states whether the tool only reads or can write/patch files, whether `.env.example` must already exist, or how it reports results — significant gaps for an unannotated tool.

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

Conciseness4/5

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

One front-loaded sentence delivers the purpose, the mechanism, and the payoff. The accessor list is functional rather than filler, though the '(v11.0 Hypernova)' branding and 'Environment Variable & Config Drift Detector' label are redundant with the tool name.

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

Completeness3/5

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

For a one-parameter scanner the purpose is adequately conveyed, but with no output schema the description should say what a run returns (violations list, severities, counts) and whether the analysis is non-destructive. Those omissions matter more than the missing parameter detail.

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?

The single `workspace` parameter is fully described in the schema ('Workspace root directory.'), so the schema does the work. The description adds no meaning about scope, path format, or whether scanning is recursive, leaving it at the baseline for fully documented parameters.

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

Purpose4/5

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

The description uses a specific verb ('cross-checks') on a specific resource (env-var references in code vs `.env.example`) and enumerates the accessor forms it recognizes, so an agent knows exactly what the tool inspects. It stops short of naming which situation or sibling it replaces, which is the only thing keeping it from a 5.

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

Usage Guidelines3/5

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

Timing is only implied by the phrase 'to prevent production boot crashes', which suggests use before deploy or when config breaks. There is no explicit when-to-use instruction, no when-not-to-use, and no named alternative among the many `sqo_*` tools, so the agent must infer the trigger.

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

Deploy Server

Other Tools