Tool availability & gating

Safeguard's MCP server registers 650+ tools spanning vulnerability management, SBOM and supply-chain analysis, findings, compliance, cloud and API security, secrets, and more. Not every tool is exposed to every workspace. Instead, tool availability is governed per tenant so administrators decide exactly which capabilities their assistants can use.

How it works

Each MCP tool has its own feature flag of the form mcp:tool:<tool_name>. When your assistant connects, the server resolves the set of tools enabled for your tenant and uses that set for both:

• Discovery (tools/list) — only enabled tools are advertised to the assistant, and
• Execution (tools/call) — a call to a tool that is not enabled for your tenant is rejected.

Both surfaces resolve from the same source, so an assistant can never see a tool it cannot call, or call a tool it cannot see.

What a rejected call looks like

If your assistant calls a tool your tenant hasn't enabled, the server doesn't fail the connection — it returns a normal tool result with an error flag rather than a transport-level error:

{
  "content": [
    {
      "type": "text",
      "text": "Tool \"safeguard_scan_manifest\" is not enabled for this tenant. An administrator can enable it via MCP tool feature flags."
    }
  ],
  "isError": true
}

Most assistants surface that message directly, so the fastest path from "my assistant says a tool isn't available" to fixed is usually: copy the tool name out of the message and search for it under Feature Flags.

What's enabled by default

A fresh workspace starts with a curated default set of just 10 core tools covering the common onboarding loop — connect a repository, scan it, browse the results, and orient the session. Every other MCP tool (billing & procurement, account management, notifications, help, search/AI, admin CRUD, security, and the entity consoles) ships disabled by default and is enabled per tenant by an administrator (see below). The 10 core tools:

Each of these corresponds to a mcp:tool:<tool_name> flag that's on by default for every tenant — for example, mcp:tool:safeguard_list_vulnerabilities. Any default-on tool can also be turned off per tenant. Every other tool (the ~900 beyond the core 10) stays registered on the server but is off until an administrator turns it on for the tenant — that's how you switch on billing, notifications, admin CRUD, the consoles, etc. for your workspace. A tool that isn't enabled doesn't show up in tools/list at all — there's no separate "disabled" entry indicating it exists but is off.

Enabling more tools

Administrators enable or disable any tool per tenant from the Safeguard admin console, under Feature Flags — search by name or filter by category (per-tool MCP flags are grouped under the mcp category), toggle the tool on, and save. Toggling a tool creates a tenant-specific override; toggling it back to match the platform default (or using Reset to Defaults) removes the override so the tenant simply inherits whatever the platform default is going forward. This lets teams start narrow and widen access deliberately as they build trust in each capability.

Enabled-tool resolution is re-checked periodically (on the order of a minute) rather than only once per connection, so a change usually reaches an already-connected assistant session without reconnecting. The more common source of delay is the assistant client itself: many MCP clients fetch tools/list once when a session starts and cache it locally, so if a newly enabled tool still doesn't show up, reconnect or restart your assistant to force it to re-fetch the current list.

Feature Flags is an administrative screen, managed on your tenant's behalf rather than a self-service toggle every teammate sees — if you need a tool enabled and don't have access to it yourself, ask whoever administers your Safeguard tenant.

Design principles

• Least privilege by default. Only the 10-tool core loop is on out of the box; everything else — billing, account, notifications, admin CRUD, the consoles, and more — is opt-in per tenant, and any default can be switched off.
• Tenant isolation. Enabled-tool resolution is scoped to your tenant, organization, and product context — one workspace's configuration never affects another's.
• Fail safe, never fail open. If tool resolution cannot complete (for example, a transient outage), the server falls back to the small default set rather than exposing anything wider. An outage can never broaden what your assistant can do.
• Stateless enforcement. The MCP server holds no database of its own; it resolves your enabled tools from Safeguard's authentication service on demand (cached briefly per session, as described above) rather than storing them locally.

FAQ & Troubleshooting

My assistant tries to use a tool and gets an error saying it's "not enabled for this tenant." That's the tool-gating check on tools/call doing its job — the tool exists and is registered on the server, but your tenant hasn't turned it on. The error comes back as a normal tool result rather than a connection failure (see What a rejected call looks like above), so most assistants will just relay the message. Copy the tool name and ask an administrator to enable it under Feature Flags.

I just enabled a tool in Feature Flags, but my assistant still says it isn't available. Give it a little time — enabled-tool resolution is cached briefly (on the order of a minute) rather than re-checked on every call, so a just-toggled flag can take a moment to take effect even on a session that's already connected. If it's still missing after that, the more likely cause is the assistant client: many MCP clients fetch tools/list once when a session starts and cache the result, so reconnect or restart your assistant to force a re-fetch.

How do I find the exact tool name to search for in Feature Flags? Tool names follow the pattern safeguard_<verb>_<noun> — for example, safeguard_scan_manifest or safeguard_list_sboms. If you don't know the exact name, ask your assistant what it can currently do, or search Feature Flags by a keyword for the capability you want (e.g. "sbom" or "secrets") rather than the exact tool name.

Can I enable different tools for different users, or only for the whole tenant? Tool gating resolves per tenant, not per individual user — everyone connecting under the same tenant (and the same organization/product, if your session switches context with safeguard_switch_organization or safeguard_switch_product) sees the same enabled-tool set. If you need finer-grained, per-agent control, that's what Guard (below) is for.

Does turning a tool off here also block it in Guard, or does a Guard policy change affect what's enabled here? No — the two are independent mechanisms. See the callout in How this relates to Guard below.

How this relates to Guard

Everything above describes tool gating for Safeguard's own MCP server — the 650+ platform tools and the per-tenant feature flags that decide which of them a given workspace can see and call. If you're building or operating MCP servers of your own (or fronting third-party ones) and want that same kind of control — deciding which tools an agent may discover or invoke — that's what Guard provides as a product for MCP traffic in general.

Guard implements enforcement in the same two shapes tool gating conceptually splits into, discovery-time and call-time control, just generalized beyond Safeguard's own tools:

• Guard SDK — embed enforcement directly inside your own MCP server or agent process. Your code calls analyze_request (or the TypeScript/Go equivalent) before a tool call executes, and the SDK applies your live policy in-process, continuously pulled in the background with no restarts to roll out a change.
• Guard Proxy — run Guard as a standalone reverse-proxy gateway in front of one or more MCP servers you don't control the code of. Point your agent at the proxy instead of the upstream server, and every JSON-RPC call is evaluated against policy before it's forwarded on.

Both modes enforce the same underlying policy, authored in your Safeguard workspace rather than as files you check into source control — see Guard Policies for how rules are structured. A Guard policy rule can match on tool name (with glob wildcards) and resolve to allow, deny, or monitor — the general-purpose counterpart to the enabled/disabled decision the mcp:tool:<tool_name> feature flags above make specifically for Safeguard's bundled tools. Guard policies can also go further than allow/deny alone, filtering request and response content: masking PII in tool responses, redacting fields, capping row counts, or catching jailbreak attempts in tool inputs.

Feature-flag-based tool gating (this page) and Guard policy enforcement are independent mechanisms. Disabling a Safeguard tool under Feature Flags does not create or change a Guard policy, and enforcing a Guard policy against your own MCP server does not touch Safeguard's tool feature flags. Use Feature Flags to control access to Safeguard's own MCP tools; use Guard (SDK or Proxy) when you need the same kind of control over MCP servers and agents you build or operate yourself.

Related

• MCP Integrations overview
• Guardrails enforcement
• Guard SDK — embed policy enforcement directly in an MCP server or agent process you control.
• Guard Proxy — enforce policy in front of MCP servers without modifying their code.
• Guard Policies — how allow/deny/monitor rules are authored and matched against tool calls.
• RBAC, Teams & Organizations — how Safeguard's organization roles and permissions work more broadly.