config://server

Purpose

Server configuration information

Description

The config://server resource exposes the MCP server's configuration including enabled features, CORS settings, and logging configuration. This read-only resource helps clients understand server capabilities and settings without needing separate configuration queries.

This resource is useful for:

• Checking which features are enabled
• Verifying OAuth and authentication support
• Understanding CORS restrictions
• Determining logging levels for debugging
• Building adaptive clients that adjust to server capabilities

Resource Details

URI: config://server

MIME Type: application/json

Authentication Required: No

The configuration resource is publicly accessible and does not require authentication.

Example Usage

Ask Claude:

"Read the server configuration resource"
"Show me what features are enabled"
"What CORS origins are allowed?"
"Check the server logging level"

Response Structure

{
  "server": {
    "name": "Seed MCP Server",
    "version": "1.0.0"
  },
  "features": {
    "authentication": true,
    "oauth": true,
    "redis": true
  },
  "cors": {
    "enabled": true,
    "allowedOrigins": [
      "http://localhost:*",
      "https://claude.ai",
      "https://*.anthropic.com"
    ]
  },
  "logging": {
    "level": "info"
  }
}

Response Fields

server

Contains basic server information:

• name (string): The server's display name
• version (string): Current version following semantic versioning

features

Boolean flags indicating which features are enabled:

• authentication (boolean): Whether JWT authentication is required
• oauth (boolean): Whether OAuth 2.1 flow is supported
• redis (boolean): Whether Redis is connected and available

cors

CORS (Cross-Origin Resource Sharing) configuration:

• enabled (boolean): Whether CORS is enabled
• allowedOrigins (string[]): List of allowed origin patterns
  • Supports wildcards (e.g., http://localhost:*)
  • Supports domain wildcards (e.g., https://*.anthropic.com)

logging

Logging configuration:

• level (string): Current logging level
  • Values: "debug", "info", "warn", "error"

Common Use Cases

Feature Detection

Check if specific features are available before using them:

"Does the server support OAuth?"
→ Read config://server
→ Check features.oauth === true
→ Proceed with OAuth flow or fall back

CORS Troubleshooting

Verify your origin is allowed:

"Am I allowed to connect from localhost:3000?"
→ Read config://server
→ Check if http://localhost:* is in allowedOrigins
→ Connection should work

Authentication Setup

Determine if authentication is required:

"Do I need to authenticate?"
→ Read config://server
→ Check features.authentication
→ If true, complete OAuth flow first

Debugging Support

Adjust debugging based on server log level:

"What's the server log level?"
→ Read config://server
→ Check logging.level
→ If "debug", expect detailed logs

Resource Access Pattern

Reading the Resource

MCP clients read resources using the resources/read request:

{
  "method": "resources/read",
  "params": {
    "uri": "config://server"
  }
}

The server responds with:

{
  "contents": [
    {
      "uri": "config://server",
      "mimeType": "application/json",
      "text": "{\"server\":{...},\"features\":{...},...}"
    }
  ]
}

Subscribing to Updates

Clients can subscribe to resource updates to be notified when configuration changes:

{
  "method": "resources/subscribe",
  "params": {
    "uri": "config://server"
  }
}

When the configuration changes, the server sends a notification:

{
  "method": "notifications/resources/updated",
  "params": {
    "uri": "config://server"
  }
}

Configuration Changes

The configuration resource reflects the server's runtime configuration. Changes occur when:

• Server restart with new environment variables
• Feature flags are toggled
• CORS origins are updated
• Logging level is changed

Subscribed clients are notified automatically and can re-read the resource.

Security Considerations

Public Access

This resource is publicly accessible because:

• Configuration details help clients integrate properly
• No sensitive credentials or secrets are exposed
• Information is necessary for proper CORS and auth setup

What's NOT Included

The resource intentionally excludes:

• Secret keys or credentials
• Internal service URLs
• Database connection strings
• API keys
• User data

These remain protected in environment variables and never appear in resources.

Integration Examples

Adaptive Client

// Read server config
const config = await client.readResource("config://server");
const features = JSON.parse(config.contents[0].text).features;

// Adapt behavior based on features
if (features.authentication) {
  // Show login flow
  await initiateOAuth();
} else {
  // Connect directly
  await connectToMCP();
}

Feature Gates

// Check if OAuth is available
if (config.features.oauth) {
  // Enable OAuth login button
  showOAuthButton();
} else {
  // Show alternative auth
  showDirectConnectOption();
}

CORS Validation

// Check if current origin is allowed
const currentOrigin = window.location.origin;
const allowed = config.cors.allowedOrigins.some(pattern =>
  matchesPattern(currentOrigin, pattern)
);

if (!allowed) {
  showCORSError();
}

Related Resources

• user://profile - Authenticated user information

Related Tools

• healthcheck - Check server health and version
• system-status - Get detailed system metrics

Related Concepts

Resource vs Tool

Use config://server resource when:

• You need to read server configuration
• You want to subscribe to config changes
• You're building adaptive client features

Use healthcheck/system-status tools when:

• You need real-time health status
• You want operational metrics (memory, CPU)
• You're monitoring server availability

Resources are for static/semi-static data, tools are for dynamic operations.

Next Steps

• All Resources - Return to resources overview
• user://profile - Learn about user profile resource
• Development Guide - Build custom resources