open-mcp-apps

Overview Schema Source Related Servers Discussions Admin

Install an App Store app

install_from_app_store

Idempotent

Add or update a ready-made app from the built-in App Store directly to your registry. Installed apps behave like your own, with UI updates coming from the store.

Instructions

Install (or update) a ready-made app from the built-in App Store into the user's registry. Once installed it behaves like any app of the user's own; its UI updates come from the App Store (newer store version), not from edits. Use app_store_list to see what's available.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	App Store entry name (see app_store_list)
`command_id`	No	idempotency key (uuid); auto-generated if omitted

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`note`	No
`tier`	Yes
`outcome`	Yes	installed = first install; updated = the store had a newer version; current = already installed and unchanged
`updated`	No
`version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.10.1Oct 18, 2026
- addedOutput schema / properties / note
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedv0.7.2Oct 4, 2026

addedOutput schema / properties / outcome

Added value: +{
+  "description": "installed = first install; updated = the store had a newer version; current = already installed and unchanged",
+  "enum": [
+    "installed",
+    "updated",
+    "current"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "name",
-  "version",
-  "tier"
-]New value: +[
+  "name",
+  "version",
+  "tier",
+  "outcome"
+]

First observedv0.5.7Aug 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare it as non-read-only, idempotent and non-destructive; the description adds genuinely new behavioral context: install doubles as update, the app then behaves like a user-owned app, and its UI updates come from newer store versions rather than local edits. Minor gap: it doesn't state what happens on name collision beyond the parenthetical 'or update'.

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

Conciseness5/5

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

Three tight sentences, zero filler, with the core action and its update semantics front-loaded before the pointer to app_store_list. Every sentence earns its place.

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?

An output schema exists so return values need not be explained, and the annotations cover the safety profile. What remains — discovery via app_store_list and the post-install update model — is fully covered, leaving nothing an agent needs in order to invoke this correctly.

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 coverage is 100% and both parameters (name, command_id idempotency key) are documented in the schema itself. The description adds no syntax, format or constraint detail beyond what the schema already provides, so the baseline 3 applies.

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+resource (install/update a ready-made App Store app into the user's registry) and immediately differentiates from the user's own apps by explaining that installed store apps update from the store rather than from edits. An agent can distinguish it from save_app/edit_app 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 Guidelines4/5

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

Gives clear context — use app_store_list to discover available entries, and install-from-store is the path for ready-made apps rather than authoring your own. It lacks an explicit exclusion (e.g., 'use save_app to create your own app'), so it stops short of full when/when-not guidance.

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