Add a mongodb-list-collections tool to discover collections in a database
Prerequisites
- Search the current open issues
What are you trying to do that currently feels hard or impossible?
After merging https://github.com/googleapis/mcp-toolbox/pull/3715, a single MongoDB tool config can leave collection out and have the agent supply it at runtime (https://github.com/googleapis/mcp-toolbox/issues/1679). But that only works if the agent already knows the collection name. There's no way for it to ask "what collections exist in this database?" so it either guesses a name, or the person driving it has to know the schema and spell it out. Both are easy to get wrong, and a wrong guess just fails at query time.
For Postgres/MySQL there's list-tables, and Firestore has list-collections, so an agent can discover what it's allowed to touch before it runs anything. MongoDB has no equivalent, which makes the runtime-collection flow harder to use than it should be.
Suggested Solution(s)
Add a mongodb-list-collections tool that returns the collection names in a configured database. The MongoDB source already holds a live client (MongoClient() in internal/sources/mongodb/mongodb.go), and the driver exposes Database.ListCollectionNames, so this is a thin tool over an existing capability.
Rough shape, following the existing MongoDB tools:
tools:
list-collections:
kind: mongodb-list-collections
source: my-mongo-source
database: my-db
description: List the collections available in the database.- Config: source, database, description (no collection — it lists them).
- New source method, e.g.
ListCollectionNames(ctx, database string) ([]string, error), mirroring the other Source methods. - Naming per the style guide:
type mongodb-list-collections (kebab-case, product-prefixed), tool namelist_collections (snake_case, no product prefix)— same as firestore-list-collections. - Unit + integration tests, and a doc page under docs/en/integrations/mongodb/tools/.
Open design question, how should this interact with collectionAllowedValues?
The operation tools (find, insert, etc.) can be scoped with collectionAllowedValues. The discovery tool is a separate tool with its own config, so the question is what it should return:
- Case 1: No scoping (pure discovery). Config is just source + database; the tool returns every collection in the database via ListCollectionNames. Simplest, and matches the list-tables / firestore-list-collections precedent. Downside: if the operation tools are scoped with collectionAllowedValues, discovery can surface names those tools will then reject — the same "wrong guess fails at query time" problem, just moved one step.
- Case 2: Scoped discovery (intersection). Let the list tool also take collectionAllowedValues, and when it's set return ListCollectionNames(db) ∩ collectionAllowedValues — i.e. only the allowed collections that actually exist. This keeps the discovery tool consistent with the scoped operation tools, so what the agent sees lines up with what it's allowed to use.
Alternatives Considered
No response
Additional Details
Ref thread: https://github.com/googleapis/mcp-toolbox/pull/3715#discussion_r3688417293 Ref PR: https://github.com/googleapis/mcp-toolbox/pull/3715 Ref Issue: https://github.com/googleapis/mcp-toolbox/issues/1679
Source: googleapis/mcp-toolbox