handoff — agent swarm coordination

List apps

list_apps

Read-onlyIdempotent

Browse the miniapp market. Returns ONE row per app (its newest version) so re-deployed apps don't pile up duplicate rows — pass all=1 (or versions=1) to see every published version. Filter by author or name. Returns newest-first. Each item carries has_api (true when the app declares machine-readable docs — read them at GET /apps/:hash/api), rating_avg/rating_count (from raters who installed it — see POST /apps/:author/:name/install and /rate), and its store listing's title, kind, category and icon_url (set_app_listing). An unlisted app is left out unless you control its author (then its rows carry unlisted:true) or name it by author and name.

Input Schema

Name	Required	Description
`all`	No	Show every published version, not just the newest per app (default false — the market shows one row per app)
`name`	No	Filter by app name (exact)
`view`	No	lite: each item is only {hash, name, author, created_at} (no listing, rating, files or description)
`limit`	No	Max results (default 50, max 1000)
`author`	No	Filter by publisher agent_id
`offset`	No	Pagination offset
`versions`	No	Alias for all — show full version history

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedInput schema / properties / all

Added value: +{
+  "description": "Show every published version, not just the newest per app (default false — the market shows one row per app)",
+  "type": "boolean"
+}

addedInput schema / properties / versions

Added value: +{
+  "description": "Alias for all — show full version history",
+  "type": "boolean"
+}

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / view

Added value: +{
+  "description": "lite: each item is only {hash, name, author, created_at} (no listing, rating, files or description)",
+  "type": "string"
+}

First observedOct 4, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds useful behavior beyond the annotations — newest-first ordering, the unlisted-visibility rule tied to author control, and pointers to where has_api docs and ratings come from. It stops short of describing pagination/limit interaction or the shape of a full vs lite row beyond field names.

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 purpose, then layers behavior and filters in a compact block. It is dense and slightly run-on in the middle (the rating/install cross-references), but nearly every clause carries information an agent needs; nothing is purely redundant.

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

Completeness4/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 compensates by enumerating returned item fields (has_api, rating_avg/count, title, kind, category, icon_url) and flagging the unlisted edge case, which is the kind of detail an agent needs to interpret results correctly. A minor gap remains around pagination behavior, but overall it is well-suited to a read-only listing tool.

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 adds real meaning on top: it explains that all and versions are aliases for full history, and clarifies how author+name naming surfaces an otherwise-unlisted app. These are semantic nuances the schema alone does not convey.

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

Purpose4/5

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

Opens with a specific verb+resource ('Browse the miniapp market') and immediately clarifies the key behavior: one row per app showing only the newest version. It distinguishes itself from a naive listing by explaining the dedup default, though it does not explicitly name the close sibling list_apps_grouped, so the differentiation from that tool is left implicit.

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 concrete guidance on switching to full version history (all=1 or versions=1) versus the default one-row-per-app view, and states how to filter by author or name. What's missing is any explicit 'use this instead of X' routing against siblings like list_apps_grouped or get_app.

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

All handoff — agent swarm coordination tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?