Skip to main content
Glama

Get hosted app source

get_app_source
Read-only

Read the files of a hosted app as Playbook stores them. Without path, returns the version's version_number and its files, each with path and bytes. With path, also returns that file's text in file.content, a slice starting at offset; while file.next_offset is not null, call again with offset set to it to read the rest. Reads the live version unless version names an older one (see list_app_versions); a version or path that is not there answers not found. Read an app's files before changing it with edit_app_source rather than rewriting them from memory. An app not deployed since Playbook began keeping versions has no stored files: the call fails with source_unavailable, and deploying its files once with deploy_app starts its history.

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": {
      "slug": "<slug>"
    },
    "name": "get_app_source"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoA file to read, e.g. `app.js`, as listed in `files`
slugYesSlug of the app, from list_apps
limitNoCharacters to return, up to 50,000 (default 12,000)
offsetNoWhere in the file to start, in characters: the previous answer's `file.next_offset`
versionNoVersion number to read; omit for the live version
organizationNoWorkspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish readOnly/non-destructive, and the description adds substantial context beyond them: the pagination contract (loop on file.next_offset), the two response shapes with and without path, default live-version behavior, and two distinct error outcomes including source_unavailable for unversioned apps.

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?

Front-loaded with the core action and the two response modes, then pagination, then version scoping, then the sibling-routing advice. It is dense and the final sentence about unversioned apps runs long, but every sentence carries operational information rather than filler.

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 return-value burden and does so fully: version_number, files entries with path and bytes, file.content, and next_offset. Combined with the error and prerequisite guidance, an agent has everything needed to call and page through this tool correctly.

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 100%, so the baseline is 3, but the description genuinely adds meaning: offset is tied to the previous answer's file.next_offset and limit/offset interact in a read loop, and version is tied to the list_app_versions sibling. Only limit's default is left entirely to the schema.

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 ("Read the files of a hosted app") plus the exact scoping model (as Playbook stores them, live version by default). It clearly differs from edit_app_source, deploy_app, and list_app_versions, so an agent can pick it without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance: read files before changing them with edit_app_source rather than rewriting from memory; omit version for live, pass one for history. It also names the exclusions and failure paths (path/version not found, source_unavailable and the deploy_app remedy).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources