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

TableJSON Schema

Name	Required	Description
`paths`	No	for a large app, selected paths from the returned manifest; omit for the complete bundle
`app_id`	No	the app id to continue working on
`version`	No	a past version to read instead of the live one; omit for what is published now
`development_token`	No

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`note`	No	plain sentences about this result for the person; the same text as the first text block
`files`	Yes	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
`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.

First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true), the description discloses rich edge-case behavior: reserved apps return version 0 with no files, failed apps return the last live version plus a plain problem, stored records are intentionally omitted, and source-backed data returns only a recipe digest and projection, never rows. It also clarifies that ground-truth files/schema win over compact context on disagreement.

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?

It is front-loaded with the core purpose before edge cases, and nearly every sentence carries distinct information (reserved/failed apps, source-backed data, version semantics). It is dense and the final version sentence is a run-on, so it is not maximally tight, but it is largely free of waste.

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?

Given an output schema exists and the tool's complexity (versioning, reserved/failed app states, source-backed projections), the description covers everything an agent needs to call it correctly and interpret results. Return-shape details are supplementary rather than required.

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 75%, and the description adds real meaning: paths selects from the returned manifest (omit for the full bundle), version reads a past version and carries a publish-safety warning, and app_id is the identifier from the message. development_token is undocumented in both schema and description, a minor gap.

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 states a precise verb+resource+scope: it returns the complete currently published source of an existing app, keyed by app_id from the user's message. It distinguishes itself from siblings like get_app_status and list_apps by defining exactly what source, schema, and context are returned.

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?

Usage context is clear (call with the app_id in the person's message) and it explains the version parameter's purpose, including a warning that republishing a past version reintroduces a bad publish. It does not explicitly name alternative sibling tools (e.g., get_app_status vs get_app_context) for comparison, so it stops short of full routing guidance.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.