Skip to main content
Glama

detect_environment

Resolves the current environment slug (dev, staging, prod) by checking QRING_ENV, NODE_ENV, .q-ring.json, and git branch. Returns detected env and source for logging or tool chaining.

Instructions

[project] Resolve which environment slug (e.g. 'dev', 'staging', 'prod') the current invocation should collapse to. Use before reading secrets when you want to mirror the same env q-ring would auto-pick (e.g. to log it, or to pass through to another tool); prefer passing an explicit env to get_secret/env_generate when you already know which env you want. Read-only; checks the QRING_ENV env var, NODE_ENV, the project's .q-ring.json, and the current git branch in priority order. Returns JSON { env, source } (e.g. { env: 'dev', source: 'NODE_ENV' }), or a plain message indicating that no env could be detected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectPathNoAbsolute path to the project root for project-scoped secrets and policy resolution. Defaults to the MCP server's current working directory when omitted.
Behavior4/5

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

Description discloses read-only nature, priority order of checks, and return format. Annotations are absent, so description carries full burden; it provides good but not exhaustive detail.

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?

Two sentences, front-loaded with purpose. Every sentence adds essential information without waste.

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 one optional parameter and no output schema, description fully explains return format and resolution priority. Complete for a simple detection tool.

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

Parameters4/5

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

Schema covers 100% of parameters with descriptions. Description adds value by noting default behavior of projectPath, which is not in 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?

Description clearly states the tool resolves an environment slug, using the verb 'Resolve' and specifying the resource. It distinguishes from siblings like get_secret by noting when to prefer explicit env.

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 reading secrets to mirror auto-picked env) and when not to (when env is already known, prefer passing explicit env). Also mentions use for logging or passing through.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/I4cTime/quantum_ring'

If you have feedback or need assistance with the MCP directory API, please join our Discord server