fline

Check fline.json

check_config

Read-only

Check a fline.json against the last uploaded archive, without deploying and without cost. Answers either ok, or the reason each part was refused — edit and ask again until it is ok, then save the file. There is no port field and there is no need for one: the platform passes PORT and routes whichever port the process opens. An env_names entry may be an object carrying a literal value — {"name": "KAFKA_ADVERTISED_LISTENERS", "value": "PLAINTEXT://kafka:9092"} — which is how a service that names an image is configured, since its ENTRYPOINT reads its whole configuration out of the environment and the platform cannot replace it. A value is permitted only on a service that names an image, is never a credential (name a password or token and leave the value empty; a human enters it), and stands alone: no ref, scope or bind beside it. A managed database's connection string is NOT written this way — use scope "managed" with ref naming the offering and no value. health_path, on a public service, starts with / and has at most 200 characters, with no query, fragment, spaces or "..".

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": {
      "project_id": "<project_id>",
      "config": "<config>"
    },
    "name": "check_config"
  }
}

Input Schema

Name	Required	Description	Default
`config`	Yes
`project_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavior beyond that: no cost, no deployment, and 'answers either ok, or the reason each part was refused,' which tells the agent this is a pure iterative validator. It is consistent with the annotations.

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

Conciseness3/5

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

The purpose is reasonably front-loaded, but the body is dense and drifts into schema-level detail (rules for env_names values and health_path) framed as prose. The port-field tangent ('There is no port field and there is no need for one') is verbose, weakening economy, though the detail does compensate somewhat for empty schema descriptions.

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?

With no output schema, the description supplies the return contract ('ok, or the reason each part was refused') and detailed domain rules for the config format, which is substantial for a validator. It falls short only on the two input parameters, neither of which is explained.

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 coverage is 0% with two required params (project_id, config) and a nested config object. The description elaborates heavily on the fline.json content rules (env_names, health_path), which implicitly informs the config param, but it never maps that to 'config' and never mentions project_id at all, leaving a real gap.

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 gives a specific verb+resource: 'Check a fline.json against the last uploaded archive,' and disambiguates from deploy by stating 'without deploying and without cost.' It's clear what the tool does, though it never explicitly names a sibling (e.g. deploy, refresh_config) to route against.

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?

It implies a workflow context ('edit and ask again until it is ok, then save the file'), which suggests pre-deploy validation. However, it never mentions alternative tools (deploy, submit_declaration) or when-not-to-use, leaving the agent to infer the validate-then-deploy ordering.

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

All fline tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.