An honest answer states whether you keep a register of MCP servers that company agents and assistants can connect to, what it records for each one, who approves additions, and how often it is reviewed. If the register is partial, say which scope it covers and when the rest will be done.
Why this question appears now
Model Context Protocol servers give an assistant tools, such as reading files or calling an API. The MCP specification says local servers may have direct access to the user's system, and that clients should warn that servers run with the same privileges as the client. A reviewer who reads that sentence will want to know how many such servers exist in your company.
Inventory is the cheapest control that makes the others possible. You cannot gate, scope or revoke what you have not listed.
What the register should hold
| Field | Why it matters |
|---|---|
| Server name and source | Where the code comes from |
| Local or remote | Local servers run on the laptop with its privileges |
| Transport and endpoint | stdio or HTTP, and which host |
| Tools exposed | Read only or able to change things |
| Credentials used | Which token, with what scope |
| Owner and approver | A person, not a team alias |
| Approval date and review date | Shows it is maintained |
| Client apps using it | Editors, desktop apps, agents |
Sample wording
"Yes. We keep a register of MCP servers approved for use with company assistants. Each entry records the source, whether it runs locally or remotely, the tools it exposes, the credential and its scope, an owner and a review date. Additions need security approval. The register covers engineering laptops and our CI agents; coverage of the data team is scheduled for next quarter."
The last sentence matters. Stating the boundary is more credible than claiming total coverage.
Where partial answers go wrong
- Counting only servers someone submitted. People install them from a project config file without telling anyone.
- Listing a server without the credential it uses. The token is the real risk.
- Recording a version once and never checking. Tool lists can change after approval, so note the review cadence.
A discovery step helps. Search repositories for MCP config files, review editor settings during onboarding, and compare against the register monthly. See also how to register MCP servers and agents in an inventory.
Evidence to offer
A redacted export of the register, the approval procedure, and the date of the last review. Do not send raw tokens or internal hostnames.
Safeguard offers asset discovery and agent identity for this kind of inventory, and an MCP Guardrail for controlling which tools agents can call.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which details you would need to record for each server you connect.
Quick check
Does a remote MCP server belong in the inventory?
Yes. A remote server is a third party that receives your agent's requests, so it needs an owner, a credential record and a data handling note.
How often should the register be reviewed?
Pick a cadence you will keep, such as quarterly, and state it. A review you can prove beats a monthly promise you cannot.
Sources
Last reviewed: 19 October 2026.
