lampa-mcp-server

Overview Schema Source Related Servers Discussions Admin

Catalog Lampa APIs and indexes

list_catalog

Read-onlyIdempotent

Dump a selected Lampa catalog (API surface, events, storage, network, settings, providers, or other topics) as markdown for one snapshot, with optional substring filtering and event detail.

Instructions

Dump one static catalog from the Lampa snapshot per call. Returns markdown text, not JSON, with no performance cost beyond one tree walk. Not a query (search_code), not a single-symbol walk (trace_symbol), not written docs (explain_docs), and not a live CUB client (guide_cub). scope applies only to api_surface/events/storage (default all); detail=true only affects events; query is a plain substring filter (module name, event name, storage key, component name, flag keyword, or network folder) within the chosen topic — never a repo-wide search. Example: topic=events query='player' detail=true. Empty catalog → markdown, not an error; on R2, full-tree events/storage need a prebuilt index — pass query or a narrower topic (e.g. maker, socket, flags, content_rows, favorites, mirrors) if the index is missing.

Input Schema

Name	Required	Description
`query`	No	Filter the chosen catalog only (not a repo-wide search): API module, event name, storage key, component name, flag keyword, or folder (for network).
`scope`	No	For api_surface, events, storage: limit the tree. Default all.
`topic`	Yes	Which catalog: api_surface \| events \| storage \| network \| settings \| providers \| maker \| socket \| activity \| flags \| content_rows \| favorites \| mirrors.
`detail`	No	For topic=events: include per-file listener/emitter lists. Default false.

Output Schema

Name	Required	Description	Default
`markdown`	Yes	Human-readable markdown report. Always present, including empty-result cases. Does not write files.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.8.0Sep 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, but the description adds important context beyond them. It discloses that output is markdown rather than JSON, that cost is one tree walk, that an empty catalog is not an error, and that full-tree events/storage on R2 may require a prebuilt index.

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?

The description front-loads purpose, then covers sibling alternatives, parameter constraints, an example, and edge-case behavior. It is dense but appropriately sized for a catalog tool with multiple topics and operational caveats.

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, annotations cover safety, and schema descriptions are complete. The description still adds useful index-missing guidance and clarifies empty-result behavior, so an agent has enough information to invoke it 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 description coverage is 100%, so the baseline is 3. The description adds that query is a plain substring filter and gives an example combining topic, query, and detail, but most scope/detail/topic semantics are already fully documented in 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?

It states a specific action and resource: dumping one static catalog from the Lampa snapshot. It immediately distinguishes the tool from four sibling behaviors: search_code, trace_symbol, explain_docs, and guide_cub. An agent can recognize this as static catalog retrieval rather than search, tracing, documentation, or live CUB access.

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?

The description explicitly says what the tool is not and names the alternatives, giving clear routing guidance. It also explains when to use query or a narrower topic if the R2 index is missing, and provides a concrete example with topic=events, query='player', and detail=true.

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

Deploy Server