An MCP-enabled assistant is usually given the exact names of the tools available to it. That list is supplied to the model behind the scenes.
Sometimes the list does not stay behind the scenes. A user asks the assistant what tools it has, and the model replies with internal names such as search_customers, create_ticket, or admin.tools.list. These names may reveal connected systems and available actions.
The names alone are valuable to an attacker. They can be used to craft targeted prompt injections, identify sensitive operations, and find the most useful integrations to target.
This article explains the risk and how an enterpirse-grade DAST can detect it in a running LLM application.
What MCP tool inventory disclosure is
MCP tool inventory disclosure occurs when a user-facing LLM reveals the exact runtime names of tools that should remain internal.
Listing tools are expected on raw MCP endpoints and are defined by the MCP specification. The security issue is limited to application endpoints, such as chatbots, copilots, and agent APIs, where users are not intended to receive the internal catalogue.
Consider an assistant that answers with:
[“mcp__crm__search_customers”, “mcp__support__create_ticket”, “mcp__ops__restart_service”]
These names suggest connections to three systems and the presence of an operationally sensitive action. They also give an attacker exact identifiers for more targeted instructions.
Security impact
Tool names are often optimised for machine selection, which makes them unusually descriptive reconnaissance artefacts. A catalogue can disclose both capability and topology: the service namespace, the backing integration, and the verbs the agent is allowed to consider.
An attacker can use that inventory in several ways:
1 Target prompt injection. Exact identifiers can be embedded in direct or indirect instructions, removing ambiguity about which tool the model should select.
2 Prioritise high-impact capabilities. Names containing verbs such as delete, send, publish, execute, or admin identify the actions worth probing first.
3 Fingerprint integrations. Namespace prefixes can reveal CRM, source-control, cloud, support, database, or internal MCP servers that are otherwise invisible from the public interface.
4 Infer authorisation context. The current MCP specification allows the returned tool set to vary with request authorisation. A catalogue disclosed by the model may therefore reveal capabilities associated with the current user, tenant, or service identity rather than a generic global list.
5 Chain with other weaknesses. Inventory disclosure becomes more serious when combined with weak tool-call authorisation, insufficient confirmation, excessive agent permissions, or prompt injection in content the model consumes.
A list of tool names is not a credential, and hiding it is not a substitute for authorisation. However, it tells an attacker which capabilities to target.
Automating detection with DAST
The hard part is not asking an assistant to list its tools. The hard part is deciding whether its answer is genuine inventory disclosure rather than invented names, echoed request data, ordinary prose, or unrelated identifiers.
The Bright test handles that uncertainty with a deliberately constrained classifier and a cross-response confirmation rule. It probes the live application as a black box, accepts only recognisable inventory structures, and requires repeated agreement before reporting.
Scope
The test focuses on user-facing LLM applications that can access MCP tools. Raw MCP endpoints are excluded because listing tools is expected protocol behaviour.
The test checks only whether the application reveals tool names in response to user input. It does not invoke the disclosed tools or perform actions through them.
Detection approach
The automated test follows five steps:
- Select. Identify a user-facing LLM application that can access MCP tools.
- Probe. Send inventory requests to the application and inspect its responses.
- Analyse. Check whether the responses contain a plausible tool inventory.
- Confirm. Verify that the disclosed names are consistent and are not copied from the request or unrelated content.
- Report. Create a finding with evidence of the confirmed disclosure.
LLMs can respond differently to similar requests, so Bright requires clear and reproducible evidence. Ambiguous responses, content copied from the request, and unrelated identifiers are not considered sufficient. This conservative approach favours precision over coverage.
Defences and takeaways
For teams building LLM applications with MCP-backed tools:
- Define the disclosure boundary. Decide whether users should see friendly capability descriptions, exact runtime identifiers, full schemas, or no catalogue at all. Treat accidental behaviour as a policy gap, not as a de facto specification.
- Minimise the active inventory. Give the model only the tools required for the current user, tenant, and workflow. Keeping the inventory small reduces the tool information that can be disclosed or targeted through prompt injection.
- Enforce policy outside the model. System prompts can express intent, but deterministic host-side controls should govern which metadata enters the model context and what catalogue-shaped output may leave the application.
- Separate display names from runtime names. A product can transparently explain user-relevant capabilities without exposing connector namespaces or internal callable identifiers.
- Authorise every invocation. Tool names are not capabilities. Validate the user, tenant, scopes, arguments, and target resource on every call, and require confirmation for sensitive actions. The MCP specification likewise calls for access controls and human oversight around tool use.
- Validate model output. If exact inventories are prohibited, detect structured catalogue responses at the application boundary and replace them with a policy-consistent explanation.
- Test continuously. Models, prompts, tool routers, and enabled integrations change. Repeat black-box testing in CI and against deployed environments so a model or orchestration update does not silently reopen the disclosure path.
Transparency and confidentiality are not opposites here. Users should understand what an agent can do, especially before a sensitive operation, but the application should disclose that information deliberately and at the appropriate abstraction level. A model should not get to redefine the boundary because a user found the right phrasing.
Conclusion
MCP makes tools discoverable so models can use them. That same design means the model often holds an unusually precise description of the application’s connected capabilities. When a user-facing prompt can pull that description back out, the result is an attack-surface leak: no tool needs to run, and no protocol endpoint needs to be exposed.
Reliable detection requires more than spotting a function-like word in an answer. The scanner has to distinguish expected MCP discovery from application-layer disclosure, recognise the limited structures models actually return, exclude reflected and non-tool identifiers, and demand agreement across independent probes.
That is where DAST earns its place. Only the running application can show which tools are present in a real session, which policies the deployed model follows, and whether exact runtime names cross the user boundary. By testing that behaviour from the outside and requiring repeatable evidence, tool inventory disclosure becomes a concrete security finding rather than a speculative prompt-engineering concern.
