Skip to main content
Glama
Sign In

Meridian

by ai.the-meridian
OverviewDiscussions(2)Admin

Get App

app_get
Read-only

Returns detail for a single Meridian app: its Shopify connection state, its environments, and its plan feature entitlements. Takes the app_id returned by apps_list. No secret values are ever included, only metadata.

Each environment carries base_url (where the environment answers, the same as public_url, null until the first runtime deploy), platform_hostname, public_url, domains (the platform domain and each custom domain, with DNS and certificate state), database_status and database (status, engine, error_code, error_message, the database add-on first), the same fields as environments_list without the scaling configuration.

environments requires the hosting.view permission and entitlements requires plan_builder.view. When the caller lacks one, that block is null and omitted maps the block name to the permission it needs (for example {"environments": "requires hosting.view"}); omitted is an empty object when nothing was withheld. Call whoami to see which permissions you hold.

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": {
      "app_id": "<app_id>"
    },
    "name": "app_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_idYesThe app uuid returned by `apps_list`.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the read-only annotations, it discloses that no secret values are returned, that `environments` needs `hosting.view` and `entitlements` needs `plan_builder.view`, and precisely what happens on missing permissions (`null` block plus an `omitted` map keyed to the missing permission, empty object when nothing withheld). That partial-response contract is behavior an agent could not infer from the schema or annotations.

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?

Purpose and call sequence are front-loaded, and the permission/omission rules follow in a tight conditional sentence. The middle paragraph is dense field-by-field reference prose, but since there is no output schema it is doing necessary work rather than padding.

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?

With no output schema, the description carries the full burden of describing the return shape, and it does so thoroughly — per-environment fields, database status fields, and entitlement/permission gating. Nothing an agent needs to interpret a partial or null-block response is missing.

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?

Schema description coverage is 100%, so both parameters are already documented, and the description only restates that `app_id` comes from `apps_list`. It says nothing about `organization_id` slug-resolution behavior, which lives entirely in the schema, so the description adds little meaning here.

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?

States a specific verb and resource ('Returns detail for a single Meridian app') and enumerates the three blocks returned: Shopify connection state, environments, and plan feature entitlements. It also distinguishes itself from `apps_list` by naming it as the source of the required `app_id`, so an agent can tell which of the two to call.

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

Usage Guidelines4/5

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

Gives a clear call sequence — obtain `app_id` from `apps_list`, then call this — and clarifies the relationship to `environments_list` by noting this returns the same environment fields minus scaling configuration. It does not explicitly state when to prefer a sibling such as `app_readiness_get` or `environments_list` instead, so the exclusion side is thinner than the inclusion side.

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

All Meridian toolsInspect
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.

Resources