Lists Firebase Storage objects and folder prefixes under a specified bucket prefix one level deep, with paging controls.
List Storage objects and folder prefixes under a prefix (one level, like listAll).
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | No | Storage bucket; default <project>.appspot.com | |
| prefix | No | Folder prefix, e.g. uploads/ (a trailing slash is added) | |
| pageToken | No | Continue a previous listing | |
| maxResults | No | Page size; default 100 |
Changes observed during successful MCP inspections.
v0.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose a meaningful behavior beyond the schema: the listing is one level deep and returns both objects and folder prefixes, which is the key semantic an agent needs. It omits permissions/auth expectations and any note that results are paged rather than exhaustive.
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?
A single sentence with no filler, and the most decision-relevant clause (one level, not recursive) is placed where it will be read first.
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?
All four parameters are optional and fully described in the schema, and no output schema exists, so most of what an agent needs is covered elsewhere. The description still leaves gaps for a read tool with zero annotations: no statement of auth requirements, no note that results are paginated via pageToken, and no indication of how folders versus objects are distinguished in the response.
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?
Schema description coverage is 100%, so bucket, prefix, pageToken and maxResults are already documented, including the trailing-slash normalization and the default page size. The description only reinforces that prefix scopes the listing; it adds no format or default details beyond the schema, so the baseline 3 applies.
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?
States a clear verb and resource: 'List Storage objects and folder prefixes under a prefix.' The added scope '(one level, like listAll)' distinguishes it from the recursive/metadata siblings such as storage_get_metadata and storage_read, though no sibling is named explicitly.
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?
Usage is implied rather than stated: 'one level, like listAll' tells the agent this is a shallow browse, not a recursive walk or a content read. There is no explicit when-to-use/when-not guidance and no named alternatives to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.