Skip to main content
Glama

detect_environment

Detect a project's Symbols environment from caller-supplied flags (symbols.json, symbols dir, package.json, CDN) to get env_type and guidance.

Instructions

[Legacy] Detect Symbols environment from caller-supplied file flags.

Prefer get_project_context — it does the same classification by inspecting the filesystem directly (no caller-supplied flags needed) AND returns project owner/key/auth state in the same call.

Kept for backward compatibility with older agent prompts. New code should call get_project_context(cwd) instead — its response includes env_type, env_evidence, and env_guidance fields equivalent to this tool's output, plus owner, key, token_present, and next_step guidance.

Args: has_symbols_json: Whether symbols.json exists in the project root. has_symbols_dir: Whether a symbols/ directory exists with components/, pages/, etc. has_package_json: Whether package.json exists with smbls dependency. has_cdn_import: Whether HTML files contain CDN imports (esm.sh/smbls, etc.). has_iife_script: Whether HTML files use script src smbls (IIFE global). has_json_data: Whether the project uses frank-generated JSON data files. has_mermaid_config: Whether mermaid/wrangler config or GATEWAY_URL/JSON_PATH env vars are present. file_list: Comma-separated list of key files in the project root.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_listNo
has_json_dataNo
has_cdn_importNo
has_iife_scriptNo
has_symbols_dirNo
has_package_jsonNo
has_symbols_jsonNo
has_mermaid_configNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses that the tool is legacy and depends on caller-supplied file flags rather than inspecting the filesystem. It also implies the output structure by referencing equivalent fields in `get_project_context`. However, it does not explicitly discuss side effects, read-only behavior, or error conditions.

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?

The description is well-structured with a legacy notice, a preference for an alternative, and a clear Args list. It includes some extra detail about `get_project_context`'s output, which is useful for migration but slightly extends length. Overall, every section earns its place.

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

Completeness4/5

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

Given the tool has 8 parameters and no annotations, the description covers input semantics thoroughly and provides migration guidance. Since an output schema exists, the description doesn't need to detail return values, but it still hints at the output fields by comparing to `get_project_context`. This is adequate for the tool's complexity.

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?

Schema description coverage is 0%, so the description fully compensates. Every parameter (has_symbols_json, has_symbols_dir, etc.) is explained with a clear, specific meaning, e.g., 'Whether symbols.json exists in the project root.' The `file_list` parameter is also described as a comma-separated list. This adds substantial meaning beyond the raw 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 'Detect[s] Symbols environment from caller-supplied file flags,' specifying both the action and the resource. It distinguishes itself from the sibling tool `get_project_context` by explicitly noting it relies on caller-supplied flags and is a legacy alternative.

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 provides explicit usage guidance: 'Prefer `get_project_context`' and 'New code should call `get_project_context(cwd)` instead.' It also explains that this tool is 'Kept for backward compatibility with older agent prompts,' giving clear when-to-use and when-not-to-use direction.

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/symbo-ls/symbols-mcp'

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