What Public MCP Tool Descriptions Reveal About Internal Data Access

A public name is a lead, not a finding

Model Context Protocol (MCP) servers connect AI applications to tools and data sources. A hostname that includes “mcp,” or a certificate issued for a related name, may suggest that an organisation has configured an MCP service. It does not prove the name currently resolves to a live service, that the service speaks MCP, that its tools are publicly reachable, or that anyone has used it.

DNS records can be stale, point to a shared edge, or belong to a test environment. Certificate transparency records show that a certificate was issued for a name; they do not establish what runs there now. Treat both as investigation leads. Confirm ownership and scope with the service owner before any active testing.

Descriptions become visible after access

When a client has an authorized MCP session, the server can provide a tool inventory and, depending on its implementation and protocol version, details such as each tool’s name, description, and input schema. These details help an AI client decide when and how to call a tool. They can also tell a reader what the integration is designed to do.

A tool named for searching customer records, opening support cases, querying a warehouse, or changing cloud configuration may reveal a capability or business process. Its description can explain the intended operation. A JSON Schema can expose expected fields, accepted formats, optional versus required inputs, and sometimes internal terminology. Taken together, the metadata may make the boundary between an assistant and connected systems easier to understand.

That information is not the same as access to the underlying data. A schema describing an account lookup does not prove that a caller can retrieve any account, and a write-oriented tool description does not prove that a change is possible. Authentication, authorization, server-side validation, and the caller’s identity determine what a particular session can do.

The design choices that create unnecessary exposure

Tool metadata is often written for model usability, not external publication. Internal project names, database labels, endpoint paths, table names, operational notes, and examples containing realistic identifiers can leak through descriptions or schemas. Even without secrets, that detail can help an authorized reviewer understand the intended integration and can give an unauthorized reader context if the service grants access too broadly.

The more serious issue is usually the authorization model behind the metadata. A service that presents tools to every authenticated user, grants a shared service identity access to broad datasets, or trusts the model to enforce access decisions has a wider exposure than the description alone suggests. The server must check what the authenticated principal may do on every request.

Keep tool descriptions useful but spare. State the operation and its limits. Do not include credentials, tokens, private URLs, customer examples, internal incident notes, or instructions that reveal hidden implementation details. Treat schemas as externally reviewable documentation, even when the MCP endpoint is intended for employees only.

Audit the boundary without touching unapproved systems

Start with your own asset records, DNS administration, certificate inventory, cloud configuration, and service-owner interviews. Map each suspected MCP name to an owner, environment, business purpose, identity provider, and data classification. Mark unknowns for owner confirmation rather than assuming a public name represents a deployed endpoint.

For a service in scope, ask its owner to provide a sanctioned test environment or a test identity with documented permissions. Verify that unauthenticated requests receive the intended denial, that an authenticated identity sees only its assigned tools, and that each tool enforces authorization on the server. Use approved, non-sensitive test records. Do not infer authorization from the tool list.

• Compare the tools and schemas shown to each approved role; investigate any capability that exceeds that role’s job or data access.
• Review tool descriptions, schema fields, defaults, examples, and error messages for secrets, internal-only identifiers, customer data, or unnecessary implementation detail.
• Trace each tool to its backend identity and confirm that the backend enforces per-user or per-service permissions rather than trusting model instructions.
• Check server logs for identity, tool name, authorization outcome, timestamp, and request correlation ID; avoid recording sensitive input values unless policy requires them.
• Record the test scope, account, environment, expected result, observed result, owner, and remediation date so the review is repeatable.

Reduce what a successful session can reach

Give each integration a dedicated identity with access limited to its task. Separate read operations from writes. Require explicit user approval for consequential changes, and place additional checks on actions such as deleting records, changing permissions, or initiating payments. The server, not the model prompt, must enforce these rules.

Expose only the tools an application needs. Apply row-level and object-level authorization in the backend, validate every argument against server-side constraints, and cap results so a broad query cannot return an entire dataset by default. Keep secrets in a managed secret store and avoid returning them in tool results or errors.

Review MCP registrations when teams change tools, owners, or data sources. Retire unused endpoints and credentials, rotate credentials after confirmed exposure or a planned access change, and alert on unexpected tool use or authorization failures. For public DNS or certificate findings, verify ownership and deployment status through your own records before taking remediation action; those public signals alone do not justify credential rotation or a compromise declaration.