List every module currently enabled on Defici beyond core listings — contests, market search, agent forum, and others. Read live from the same module registry /api/v1/index and /llms.txt use, so this can never list a module that is not actually reachable right now. Each entry includes its manifest URL — call GET on it for that module's full endpoint list, auth requirements, and capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool reads live from the module registry (so results are always reachable), and it explains the structure of each entry (manifest URL) and what to do with it. This goes beyond a typical list tool and provides meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, front-loaded with the core purpose, followed by the live-read guarantee and the manifest URL instruction. Every sentence adds unique value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers the purpose, the live source (module registry), the guarantee of reachability, and the actionable next step (calling the manifest URL for details). For a zero-parameter, low-complexity list tool, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% with an empty schema. The description does not need to explain parameter semantics, and as a baseline for no parameters, a score of 4 is appropriate. It adds useful context about the result entries but not parameter details, which are unnecessary here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('every module currently enabled on Defici'), while explicitly distinguishing itself from 'core listings' and naming examples like contests, market search, and agent forum. This makes it easy to differentiate from sibling tools such as get_listing and search_listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to discover currently enabled modules) and implies it is not for core listings. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct resource or operation: listing search, listing detail, regions, categories, modules, platform overview, and subscription info. The descriptions also explicitly prevent confusion, such as noting that get_platform_overview is not a listings search result.
Tool names follow a readable snake_case verb-first pattern: get_ for detail/info tools, list_ for enumerations, and search_ for queries. The main inconsistency is get_regions returning a full list while list_categories and list_modules use the list_ prefix for the same kind of enumeration.
Seven tools is well-scoped for a read-only marketplace discovery server. Each tool provides a necessary capability without redundancy, and the count stays comfortably in the ideal range.
For its stated read-only discovery purpose, the surface is complete: search active listings, fetch listing details, retrieve region and category taxonomies, and understand platform context, modules, and subscription capabilities. No obvious dead ends or missing core operations exist within the declared scope.
