Defense Signals™ MCP server

The Defense Signals™ MCP server is a single hosted endpoint. There is nothing to install, no local process, and no API key to paste into a client.

Endpoint

https://www.defensesignals.com/mcp

Transport

Streamable HTTP (MCP 2025-06-18)

Authentication

OAuth 2.1 + dynamic client registration

Protocol methods

initialize, tools/list, tools/call

Every request is a JSON-RPC 2.0 POST. Clients must send Accept: application/json, text/event-stream; servers built on the official MCP SDKs reject requests without it.

The MCP endpoint is a protected resource. Authorization is delegated to the Defense Signals authorization server, which supports dynamic client registration — so compatible clients register themselves with no manual setup.

1. The client calls POST /mcp without a token and receives 401 with a WWW-Authenticate: Bearer challenge carrying resource_metadata.
2. The client fetches the protected-resource metadata document, which names the authorization server.
3. The client fetches the authorization server's /.well-known/oauth-authorization-server discovery document and registers itself dynamically.
4. You sign in with your Defense Signals account and approve the connection on our consent screen.
5. The client exchanges the authorization code (PKCE) for an access token and replays the MCP request with Authorization: Bearer ….

An anonymous call to /mcp returns 401 Unauthorized. This is correct behavior and required by the MCP authorization specification — it is how a client discovers where to sign in.

POST /mcp  (no Authorization header)

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://www.defensesignals.com/.well-known/oauth-protected-resource"

Some directory listings run an unauthenticated probe and mark the server "unhealthy" when it sees that 401. It does not indicate downtime. The alternative — answering anonymous tool calls — would publish member intelligence to anyone on the internet.

For monitoring, use the public health endpoint instead: https://www.defensesignals.com/health/mcp. It returns 200 with operational status, transport, OAuth protection state, discovery status, and a timestamp — and no protected data.

Defense Signals access tokens carry no custom OAuth scopes. Authorization is enforced server-side: every tool call runs as the signed-in member, under that member's row-level entitlements. A token cannot reach anything the same person could not reach when signed in to the site.

There are no shared API keys and no service-role access behind the MCP server. Revoking a member's access, or ending a subscription, immediately changes what their assistant can retrieve.

Any client that supports remote MCP servers over Streamable HTTP with OAuth can connect. Step-by-step guides:

Generic configuration for file-based clients:

{
  "mcpServers": {
    "defense-signals": {
      "type": "http",
      "url": "https://www.defensesignals.com/mcp"
    }
  }
}

Claude Code, one line:

claude mcp add --scope user --transport http defense-signals 'https://www.defensesignals.com/mcp'

• Tool calls run as the authenticated member; row-level security is enforced on every query.
• Only save_signal writes, and only to the caller's own reading list.
• Access tokens are held by your MCP client, never logged or returned by our tools.
• We log tool name, timing, and outcome for reliability — not prompt or conversation content.
• Published intelligence returned through the tools stays subject to the Defense Signals terms; cite it, don't redistribute it wholesale.
• No shared API keys or service-role credentials are used by the MCP server.

Connection help and enterprise questions: support@defensesignals.com. Setup walkthroughs live on the AI assistant hub, and the server overview is at /mcp-server.