Cloche

Get app context

get_app_context

Read-only

Returns the complete currently published source of an existing app, by the app_id in the person's message: every authored file, the live declared schema, published compact context, and this editor's checkpoint. An app too large for one reply comes in parts, which note names. Ground-truth files and schema win if compact context disagrees. Reserved apps return version 0 with no files. Failed apps return the last live version when one exists and a plain problem. Open reviewer comments come back word for word, with ids. Stored records are intentionally not returned. For source-backed data, it returns the recipe digest, the collection and field projection, and whether the owner keeps a copy, and never returns rows or recipe material. A change is a publish of only the changed files against the returned version, as base_version, with the complete schema and a new work_context. version reads a past version instead of the live one: publishing its files against the version now serving puts a bad publish back.

Input Schema

Name	Required	Description
`paths`	No	selected paths from the returned manifest, or none for every file one reply holds
`app_id`	No	the app id to continue working on
`to_line`	No	the last line returned of each file
`version`	No	a past version to read instead of the live one; omit for what is published now
`from_line`	No	the first line returned of each file, from 1. A line too long for one reply counts as several
`development_token`	No

Output Schema

Name	Required	Description
`name`	Yes
`note`	No	plain sentences about this result, such as a file read in parts or brand and source guidance. When set, the same text as the text blocks before the result JSON, joined by blank lines
`files`	Yes	the authored bundle of the version read, each file whole unless complete is false, and note names any part or file left out. For the live version, version is the base_version of the next change. A past version's files, published against the version now serving, not this number, put that version back
`assets`	No	binary files this version serves, by path, size, hash and type; never their bytes. A publish naming one in assets with a new hash changes it
`intent`	No
`schema`	No	the complete live declared data shape; publish takes it whole, unchanged or added to
`status`	Yes
`problem`	No
`version`	Yes
`manifest`	No
`checkpoint`	No
`data_publication`	No
`published_context`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedOutput schema / properties / schema / properties / collections / items / properties / access / description

Previous value: -"omit or \"shared\" so everyone sees the same rows; \"private\" so each signed-in person keeps their own list"New value: +"omit or \"shared\" so everyone sees the same rows; \"private\" so each signed-in person keeps their own list; \"assigned\" so a user sees rows assigned to them and owners and editors all"

addedOutput schema / properties / schema / properties / collections / items / properties / assigned_to

Added value: +{
+  "description": "assigned only: the text field holding a person's id",
+  "type": "string"
+}

Changed1 schema field changedOct 22, 2026

changedOutput schema / properties / note / description

Previous value: -"plain sentences about this result, such as a file read in parts. When set, the same text as the first text block"New value: +"plain sentences about this result, such as a file read in parts or brand and source guidance. When set, the same text as the text blocks before the result JSON, joined by blank lines"

Changed6 schema fields changedOct 20, 2026

addedInput schema / properties / from_line

Added value: +{
+  "description": "the first line returned of each file, from 1. A line too long for one reply counts as several",
+  "type": "integer"
+}

changedInput schema / properties / paths / description

Previous value: -"for a large app, selected paths from the returned manifest; omit for the complete bundle"New value: +"selected paths from the returned manifest, or none for every file one reply holds"

addedInput schema / properties / to_line

Added value: +{
+  "description": "the last line returned of each file",
+  "type": "integer"
+}

changedOutput schema / properties / files / description

Previous value: -"the authored bundle of the version read. For the live version, version is the base_version of the next change. A past version's files, published against the version now serving, not this number, put that version back"New value: +"the authored bundle of the version read, each file whole unless complete is false, and note names any part or file left out. For the live version, version is the base_version of the next change. A past version's files, published against the version now serving, not this number, put that version back"

addedOutput schema / properties / files / items / properties / complete

Added value: +{
+  "description": "false when content holds part of the file, which note names",
+  "type": [
+    "null",
+    "boolean"
+  ]
+}

changedOutput schema / properties / note / description

Previous value: -"plain sentences about this result for the person; the same text as the first text block"New value: +"plain sentences about this result, such as a file read in parts. When set, the same text as the first text block"

First observedOct 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: reserved apps return version 0 with no files, failed apps return the last live version plus a problem, large apps paginate into named parts, stored records are intentionally excluded, and it warns that republishing a past version's files puts a bad publish back. This is exactly the operational context annotations cannot carry.

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?

Purpose is front-loaded, but the body is an undifferentiated run-on of six dense sentences mixing payload description, edge cases, exclusion rules, publish semantics, and pagination hazards. Every fact is useful, yet a bulleted or paragraph-segmented structure would make it far more scannable.

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?

For a six-parameter read with an output schema, this covers the remaining gaps: partial results, oversized apps, reserved/failed app states, what is deliberately omitted, and how the returned version relates to a subsequent publish. An agent has enough to call it correctly in every described state.

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 coverage is already 83%, but the description adds real meaning: paths are selected from the returned manifest, and version carries a non-obvious hazard (publishing old files against the live version reintroduces a bad publish). from_line/to_line handling of oversized lines is also clarified, though development_token is left unexplained.

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?

Opens with a specific verb and resource: 'Returns the complete currently published source of an existing app, by the app_id'. It enumerates the payload (authored files, live declared schema, compact context, editor checkpoint), distinguishing it clearly from list_apps, get_app_status, and checkpoint_app.

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?

Usage context is implied rather than stated: the version parameter guidance ('reads a past version instead of the live one') and paths guidance ('selected paths from the returned manifest') hint at when to filter or roll back, but no sibling tool is named and there is no explicit 'use get_app_status instead when...' routing.

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

All Cloche 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.