Skip to main content
Glama

trmnl_prepare_installation

Prepares a TRMNL plugin installation by submitting source, revision, and choice details, optionally assigning the plugin to a device playlist once complete.

Instructions

Prepare an installation TRMNL POST /api/plugin_installations. Changes remote state or starts work. Run only within the user-authorized scope.

Input Schema

NameRequiredDescriptionDefault
bodyYes
headersYes
profileNoConfigured profile name; defaults to default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.2/5.0
Behavior3/5

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive; the description's "Changes remote state or starts work" is consistent with that but adds little. It omits genuinely useful behavior: that this starts a multi-step installation flow, that an Idempotency-Key is mandatory, and what state exists after the call.

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

Conciseness2/5

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

Very short, but the content is not front-loaded meaningfully: a restated name, a bare HTTP endpoint, and two generic boilerplate sentences. The endpoint reference is noise for an agent and none of the sentences adds actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with a three-field nested body, 33% schema coverage and no output schema, the description should explain the initiation flow and required identifiers. Instead it provides no information an agent couldn't get from the name and annotations.

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 description coverage is only 33% and the body is a nested object with required fields (kind, source_id, source_revision, choice_id), yet the description explains none of them. The relationship between source_id/source_revision/choice_id and the required Idempotency-Key header is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Prepare an installation" largely restates the tool name, and the raw endpoint line (POST /api/plugin_installations) is implementation detail rather than purpose. It never clarifies what "prepare" yields or how it differs from siblings like trmnl_complete_installation, trmnl_cancel_installation, or trmnl_install_recipe.

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

Usage Guidelines2/5

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

The only guidance is the generic "Run only within the user-authorized scope," which applies to every mutating tool and doesn't help select this one. There is no statement of when to initiate an installation versus listing (trmnl_list_app_installations) or completing (trmnl_complete_installation) one.

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

Deploy Server

Other Tools