Staticbot MCP server

list_base44_apps

Read-only

Lists the Base44 apps a connected integration can migrate so you can choose the correct app before starting a migration. Use it to identify the target app when the integration token has access to multiple apps.

Instructions

List the Base44 apps a connected Base44 integration can migrate. Call this before create_migration for any BASE44_NATIVE migration: a Base44 personal access token is scoped to a WORKSPACE and reaches every app in it, so the integration alone does not identify which app to migrate. Pass the chosen app's id as create_migration's base44AppId. Ask the user which app when more than one is returned — never guess, and never assume the first or the most recently edited one is meant. Migrating the wrong app is not cheaply reversible. An empty list means the token cannot see any apps: usually a token scoped to a single app that has since been deleted, or one created with Access limited to one app. A 400 means the integration still holds a legacy Base44 account API key, which cannot enumerate apps and stops working entirely on 2026-10-15 — tell the user to reconnect Base44 with a personal access token. Contains no secrets. NEVER ask the user to paste their Base44 personal access token into the conversation, and never accept one if they offer it — no Staticbot tool takes it, and there is nowhere for it to go. It is a long-lived, workspace-wide, full-access credential that can read and change every app in the workspace. A token pasted into chat is sent to the model, kept in the conversation transcript, and may be retained in client logs. The only correct handling is the browser: send the user to the integrations page and have them enter it there. If no Base44 integration exists yet, this tool and create_migration both return the exact connect URL in their error — give the user that URL verbatim.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`base44IntegrationInstanceId`	Yes	Base44 integration instance ID (from list_integration_instances, type='base44')

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Parsed JSON response from the Staticbot public API

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.8.1Sep 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only provide readOnlyHint and destructiveHint, which are minimal. The description adds substantial behavioral context: token scoping, why the integration alone doesn't identify the app, security warnings about personal access tokens, error handling semantics, and the note that it contains no secrets. This goes well beyond the annotations and is critical for correct and safe usage.

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?

The description is long but every sentence earns its place. It starts with the primary purpose, then proceeds through usage, error handling, and security in a logical order. Each paragraph addresses a distinct concern (purpose, selection guidance, error interpretation, token safety), and the structure aids clarity despite the length.

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?

The description covers all essential aspects: what the tool lists, why it's needed, how to use its output, how to handle errors, and critical security practices. With an output schema present, it needn't detail return values, and it does not leave any obvious gaps for correct invocation.

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?

The single parameter `base44IntegrationInstanceId` is fully documented in the schema with a clear description and source reference. The description adds contextual rationale for the parameter's importance (token scoping) but does not add new meaning about the parameter itself. Since schema coverage is 100%, a baseline of 3 is appropriate.

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 begins with a clear verb and resource: 'List the Base44 apps a connected Base44 integration can migrate' and immediately ties it to the migration workflow by referencing create_migration. It distinguishes this tool from siblings by clarifying its role as a prerequisite enumeration step.

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?

Explicitly states when to use it ('Call this before create_migration for any BASE44_NATIVE migration'), provides a direct instruction for the output ('Pass the chosen app's `id` as create_migration's `base44AppId`'), and includes behavioral guidance on not guessing apps. It also details error cases (empty list, 400) with actionable remedies.

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

Deploy Server