[BUG] inspect_schema matches named container case-insensitively without preferring exact match

Open Beginner friendly
  • Is something wrong?
#2,128 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@Maaz2212 is already working on this.

Since Nov 1, 2026.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rabbitmq, typescript
Domain
databases

Research direction

Read src/lib/mcp/tools/inspect-schema.ts and the existing tests in tests/unit/mcp/inspect-schema.test.ts. Add coverage for containers named Billing and billing, including the case-insensitive fallback when there is no exact match. Done means exact matches are preferred and the tests pass.

Written by the indexing model from the issue text.

Description

bug

Description

When calling the MCP tool inspect_schema with a schema argument, chooseContainer performs a purely case-insensitive search (candidate.name.toLowerCase() === wanted) against the list of available containers.

On database engines and message brokers that support case-sensitive container names (for instance, RabbitMQ virtual hosts such as Billing and billing, or engines with case-sensitive schema names), requesting schema: "billing" will pick whichever container is returned first by listContainers(). If Billing appears first in the list, inspect_schema inspects Billing instead of the exact match billing.

Steps to Reproduce

  1. Configure a connection to an engine with case-sensitive container names (e.g., RabbitMQ with virtual hosts Billing and billing, where Billing is listed first).
  2. Invoke the MCP tool inspect_schema passing schema: "billing": 
    {
  "connection_id": "<connection_id>",
  "schema": "billing"
}
  3. Inspect the returned container in the response payload.
  4. Notice that inspect_schema chose the container Billing instead of the exact match billing.

Expected Behavior

chooseContainer should prioritize an exact case match (candidate.name === schema) first. It should only fall back to a case-insensitive match (candidate.name.toLowerCase() === wanted) when no exact match exists.

Actual Behavior

chooseContainer uses containers.find((candidate) => candidate.name.toLowerCase() === wanted) immediately. Whichever container appears earlier in the enumeration order is chosen, even when an exact case match exists later in the array.

Environment

  • LibreDB Studio Version: 1.2.0
  • Browser: All / Headless MCP
  • OS: macOS / Linux / Windows
  • Node.js/Bun Version: Bun 1.4.3 / Node.js 24
  • Database Type: RabbitMQ / PostgreSQL / case-sensitive container engines

Additional Context

Documented in docs/BACKLOG.md under item MCP3:

chooseContainer compares names lower-cased, so on a RabbitMQ broker with virtual hosts Billing and billing a call naming billing reads whichever is listed first; Kubernetes namespaces are lower case, so it never mattered before.

Done when: the chooser prefers an exact match and falls back to the case-insensitive one only when no exact match exists, for every provider, with a test on two names that differ by case.

Possible Solution

In src/lib/mcp/tools/inspect-schema.ts, update chooseContainer:

const chosen = named
  ? (containers.find((candidate) => candidate.name === schema) ??
     containers.find((candidate) => candidate.name.toLowerCase() === wanted))
  : (containers.find((candidate) => candidate.isSessionDefault === true) ?? containers[0]);

Add a test in tests/unit/mcp/inspect-schema.test.ts verifying that when containers ['Billing', 'billing'] are present, querying schema: "billing" selects billing, and querying schema: "BILLING" falls back to the first match when no exact match exists.

Dominant language
TypeScript
Stars
810
Forks
158
Avg merge
9h 48m
Merged PRs (30d)
627

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from libredb/libredb-studio

All issues in libredb/libredb-studio

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.