Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Coolify: List application envs

coolify_list_application_envs
Read-only

Retrieve environment variables for a specified Coolify application using its site and UUID to inspect configuration values.

Instructions

[UNIFIED] List environment variables for a Coolify application.

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": {
      "site": "<site>",
      "uuid": "<uuid>"
    },
    "name": "coolify_list_application_envs"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes
uuidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, so safety is covered, but the description adds no behavioral context of its own. For an env-var listing tool it says nothing about whether secret values are masked, whether values are paginated, or whether an unauthorized site/uuid errors out.

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?

A single front-loaded sentence with no filler. The only wasted token is the unexplained '[UNIFIED]' prefix, which conveys nothing actionable to an agent.

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

Completeness2/5

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

This is a simple two-parameter read tool, but with 0% schema coverage and no output schema the description should carry the burden of explaining the parameters and the return shape. It does neither, so an agent knows what the tool does but not how to call it correctly or what it gets back.

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

Parameters2/5

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

Schema description coverage is 0% and neither required parameter ('site', 'uuid') is explained. The phrase 'for a Coolify application' weakly implies uuid identifies the app, but the meaning and format of 'site' (instance/host?) is left entirely undocumented.

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?

States a specific verb and resource: 'List environment variables for a Coolify application.' The word 'application' implicitly separates it from coolify_list_service_envs, but the description never names that sibling and the '[UNIFIED]' prefix is unexplained, so an agent must infer the application/service split.

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

Usage Guidelines2/5

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as coolify_list_service_envs or the update_*_envs_bulk siblings. Usage is only implied by the verb 'List'.

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