发现优秀的 MCP 服务器

Capillus Hermes MCP

Enables tracking and monitoring of Capillus Bluetooth caps for treatment sessions, adherence, and device status using local BLE data, without requiring cloud APIs.

second-brain-mcp

Turns an Obsidian vault into semantic memory for coding agents, providing read-only semantic search and a human-approved write workflow via MCP.

nace-mcp

An MCP server exposing NACE Rev. 2.1 economic activity classification codes for AI agents, with tools to browse, search, and fuzzy-match codes.

rapid7-mcp

A unified MCP server for Rapid7's security platform, exposing InsightVM (vulnerability management), InsightIDR (SIEM/investigations), and Metasploit Pro (pentest telemetry) as tools for Claude, Cursor, and any MCP-compatible LLM client.

World Cup 2026 MCP Server

Free MCP server for the World Cup 2026 Tour public schedule API. It enables AI assistants to fetch the 2026 FIFA World Cup schedule, next match, match by ID, and dataset JSON-LD without an API key.

Notemd MCP Server

Enables AI-powered knowledge base management with automated wiki-linking, content generation from titles, web research summarization, and knowledge graph integrity maintenance for Markdown files.

Elastic MCP Server

A read-only MCP server that gives AI assistants natural language access to Elasticsearch/Kibana logs for querying and analysis.

Drupal MCP Server

Enables AI models to interact with Drupal 10+ sites via JSON:API for querying, searching, and retrieving content. It supports listing content types, searching by title across all types, and fetching detailed node information including relationships.

Gmail MCP Server

A Node.js server that connects MCP to Gmail, enabling LLMs to send, read, and manage emails securely using the Gmail API.

datadog

Okay, here's how you can access monitor and cluster logs from Datadog, broken down into steps and considerations: **1. Accessing Monitor Logs:** * **From the Monitor Page:** 1. **Navigate to Monitors:** In the Datadog UI, go to "Monitors" -> "Manage Monitors". 2. **Find the Monitor:** Locate the specific monitor you're interested in. You can use the search bar, filters (e.g., by tag, name, status), or browse the list. 3. **Monitor Status and Events:** Click on the monitor's name. This will take you to the monitor's details page. Here you'll see: * **Monitor Status:** The current status of the monitor (OK, Alert, Warning, No Data). * **Events Timeline:** A timeline of events related to the monitor. This is where you'll find when the monitor triggered, when it recovered, and any associated messages. * **Event Details:** Click on a specific event in the timeline to see more details. This often includes: * The time the event occurred. * The message associated with the event (which might contain information about the cause of the alert). * Links to related logs, metrics, or traces (if configured). This is a crucial part for troubleshooting. * **Using the Event Explorer:** 1. **Navigate to Event Explorer:** In the Datadog UI, go to "Events" -> "Explorer". 2. **Filter by Monitor:** Use the search bar or filters to narrow down the events to those related to your specific monitor. You can filter by: * `monitor:<monitor_name>` (replace `<monitor_name>` with the name of your monitor) * `monitor_id:<monitor_id>` (replace `<monitor_id>` with the ID of your monitor) You can find the monitor ID on the monitor's details page. * `status:<alert|warning|ok|no data>` to filter by the status of the monitor. 3. **Analyze Events:** The Event Explorer allows you to see a stream of events related to your monitor. You can: * Sort events by time. * View the event message. * Click on an event to see more details. * Use facets on the left-hand side to further refine your search. * **Linking Monitors to Logs (Important for Effective Troubleshooting):** * **Use Tags:** The most effective way to link monitors to logs is to use consistent tagging. When you create your monitor, add tags that are also present in your logs. For example, if your monitor is for a specific service, tag both the monitor and the logs from that service with `service:my-service`. * **Use Log Patterns in Monitor Messages:** If your monitor message includes specific patterns that appear in your logs (e.g., an error code, a transaction ID), you can use these patterns to search for related logs. * **Use the `{{log.id}}` variable in monitor messages:** If you are creating monitors based on log patterns, you can include the `{{log.id}}` variable in the monitor message. This will include the unique ID of the log message that triggered the monitor, making it very easy to find the exact log in the Log Explorer. **2. Accessing Cluster Logs (Kubernetes, ECS, etc.):** * **Ensure Log Collection is Configured:** The first and most important step is to make sure you've properly configured Datadog to collect logs from your cluster. This typically involves: * **Installing the Datadog Agent:** The Datadog Agent needs to be running on your cluster nodes (or as a DaemonSet in Kubernetes). * **Configuring Log Collection:** You need to tell the Datadog Agent where to find the logs. This usually involves configuring the Agent to monitor specific log files or to collect logs from standard output/standard error of your containers. Datadog provides specific integrations for Kubernetes, ECS, and other container orchestration platforms. Follow the official Datadog documentation for your specific platform. * **Using the Datadog Operator for Kubernetes (Recommended):** For Kubernetes, the Datadog Operator simplifies the deployment and management of the Datadog Agent and related resources. It can automatically configure log collection based on your Kubernetes resources. * **Using the Log Explorer:** 1. **Navigate to Log Explorer:** In the Datadog UI, go to "Logs" -> "Explorer". 2. **Filter by Cluster:** Use the search bar or facets to filter the logs to those from your cluster. Common filters include: * `kubernetes.cluster.name:<cluster_name>` (for Kubernetes) * `ecs.cluster.name:<cluster_name>` (for ECS) * `host:<hostname>` (to filter by specific nodes in the cluster) * `source:<source_name>` (if you've configured a specific source for your cluster logs) * `service:<service_name>` (to filter by specific services running in the cluster) * `container_name:<container_name>` (to filter by specific containers) 3. **Analyze Logs:** The Log Explorer provides powerful tools for analyzing your cluster logs: * **Search:** Use the search bar to find specific keywords, error messages, or patterns. * **Facets:** Use the facets on the left-hand side to filter and group your logs. * **Time Series:** Create time series graphs based on log data (e.g., count the number of error logs over time). * **Live Tail:** View a live stream of logs as they are generated. * **Log Patterns:** Identify common log patterns to help you understand the behavior of your applications. * **Using Dashboards:** 1. **Create or Edit a Dashboard:** In the Datadog UI, go to "Dashboards" -> "New Dashboard" or edit an existing dashboard. 2. **Add Log Widgets:** Add widgets to your dashboard that display log data. You can use: * **Log Stream Widget:** Displays a stream of logs based on your query. * **Log Count Widget:** Displays the number of logs that match your query over a specific time period. * **Top List Widget:** Displays the top values for a specific attribute in your logs (e.g., the top error messages). 3. **Configure the Widget:** Configure the widget to filter the logs to those from your cluster and to display the information you're interested in. **Example: Kubernetes Log Access** Let's say you want to see the logs from a specific pod in your Kubernetes cluster. 1. **Ensure the Datadog Agent is running as a DaemonSet in your Kubernetes cluster.** This is the recommended way to collect logs. 2. **Verify that the Datadog Agent is configured to collect logs from your containers.** The Datadog Operator can automate this. 3. **In the Log Explorer, use the following filters:** * `kubernetes.cluster.name:<your_cluster_name>` * `kubernetes.pod.name:<your_pod_name>` * `kubernetes.namespace.name:<your_namespace>` **Important Considerations:** * **Log Volume:** Collecting logs from a large cluster can generate a significant amount of data. Consider using log filtering and sampling to reduce the volume of logs you're collecting. * **Security:** Be careful about what information you're logging. Avoid logging sensitive data such as passwords or API keys. Use log masking or redaction to protect sensitive information. * **Retention:** Datadog has log retention policies. Make sure you understand the retention policies and that you're retaining logs for as long as you need them. * **Cost:** Datadog's pricing is based on log volume. Be aware of the cost implications of collecting logs from your cluster. * **Structured Logging:** Using structured logging (e.g., JSON) makes it much easier to query and analyze your logs in Datadog. Encourage your developers to use structured logging in their applications. **In summary, accessing monitor and cluster logs in Datadog requires proper configuration of the Datadog Agent, understanding of the Log Explorer and Event Explorer, and the use of appropriate filters and queries. Linking monitors to logs through tagging and log patterns is crucial for effective troubleshooting.** I've provided a comprehensive guide. Let me know if you have any specific questions or scenarios you'd like me to elaborate on.

markupR MCP Server

Enables AI coding agents to capture screen and voice recordings, extract timestamped frames, and receive structured Markdown reports with context for bug fixing and UI feedback.

Withings MCP

Local-first MCP server that connects AI agents to your Withings body, sleep, activity and heart data.

agentic-travel-recs

Exposes tools for retrieving member profiles and personalized travel recommendations with multi-tenant partner rule enforcement, enabling AI agents to respect business constraints like caps and exclusions.

AdoMcp

AdoMcp is a Model Context Protocol (MCP) server that helps large language models (LLMs) understand database structure, read table comments, and execute SQL queries.

Linkup Model Context Protocol

好的，这是 Linkup MCP 服务器的 JavaScript 版本： ```javascript const WebSocket = require('ws'); // Configuration const PORT = 8080; const HEARTBEAT_INTERVAL = 30000; // 30 seconds // Data Structures const clients = new Map(); // Map of client IDs to WebSocket objects const rooms = new Map(); // Map of room IDs to sets of client IDs // Helper Functions /** * Generates a unique ID. Simple for this example, but consider a more robust solution for production. * @returns {string} A unique ID. */ function generateId() { return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15); } /** * Sends a message to a specific client. * @param {string} clientId The ID of the client to send the message to. * @param {object} message The message to send (will be JSON stringified). */ function sendMessage(clientId, message) { const client = clients.get(clientId); if (client && client.readyState === WebSocket.OPEN) { try { client.send(JSON.stringify(message)); } catch (error) { console.error(`Error sending message to client ${clientId}:`, error); } } else { console.warn(`Client ${clientId} not found or not connected.`); } } /** * Sends a message to all clients in a room. * @param {string} roomId The ID of the room. * @param {object} message The message to send (will be JSON stringified). * @param {string} [excludeClientId] Optional client ID to exclude from receiving the message. */ function broadcastToRoom(roomId, message, excludeClientId) { const room = rooms.get(roomId); if (room) { room.forEach(clientId => { if (clientId !== excludeClientId) { sendMessage(clientId, message); } }); } } /** * Handles client disconnection. * @param {string} clientId The ID of the disconnected client. */ function handleDisconnect(clientId) { console.log(`Client ${clientId} disconnected.`); // Remove client from clients map clients.delete(clientId); // Remove client from all rooms rooms.forEach((room, roomId) => { if (room.has(clientId)) { room.delete(clientId); if (room.size === 0) { rooms.delete(roomId); // Remove empty room console.log(`Room ${roomId} is now empty and has been removed.`); } else { // Notify other clients in the room about the departure broadcastToRoom(roomId, { type: 'clientLeft', clientId: clientId }, clientId); } } }); } // WebSocket Server Setup const wss = new WebSocket.Server({ port: PORT }); wss.on('connection', ws => { const clientId = generateId(); clients.set(clientId, ws); console.log(`Client ${clientId} connected.`); // Send the client their ID sendMessage(clientId, { type: 'clientId', clientId: clientId }); // Handle incoming messages ws.on('message', message => { try { const parsedMessage = JSON.parse(message); const type = parsedMessage.type; switch (type) { case 'createRoom': const roomId = generateId(); rooms.set(roomId, new Set([clientId])); sendMessage(clientId, { type: 'roomCreated', roomId: roomId }); console.log(`Client ${clientId} created room ${roomId}.`); break; case 'joinRoom': const roomIdToJoin = parsedMessage.roomId; if (rooms.has(roomIdToJoin)) { rooms.get(roomIdToJoin).add(clientId); sendMessage(clientId, { type: 'roomJoined', roomId: roomIdToJoin }); broadcastToRoom(roomIdToJoin, { type: 'clientJoined', clientId: clientId }, clientId); console.log(`Client ${clientId} joined room ${roomIdToJoin}.`); } else { sendMessage(clientId, { type: 'error', message: `Room ${roomIdToJoin} not found.` }); } break; case 'leaveRoom': const roomIdToLeave = parsedMessage.roomId; const roomToLeave = rooms.get(roomIdToLeave); if (roomToLeave && roomToLeave.has(clientId)) { roomToLeave.delete(clientId); sendMessage(clientId, { type: 'roomLeft', roomId: roomIdToLeave }); broadcastToRoom(roomIdToLeave, { type: 'clientLeft', clientId: clientId }, clientId); console.log(`Client ${clientId} left room ${roomIdToLeave}.`); if (roomToLeave.size === 0) { rooms.delete(roomIdToLeave); console.log(`Room ${roomIdToLeave} is now empty and has been removed.`); } } else { sendMessage(clientId, { type: 'error', message: `Client is not in room ${roomIdToLeave}.` }); } break; case 'message': const roomIdForMessage = parsedMessage.roomId; const messageContent = parsedMessage.content; broadcastToRoom(roomIdForMessage, { type: 'message', clientId: clientId, content: messageContent }, clientId); console.log(`Client ${clientId} sent message to room ${roomIdForMessage}: ${messageContent}`); break; case 'ping': // Respond to ping to keep the connection alive sendMessage(clientId, { type: 'pong' }); break; default: console.warn(`Unknown message type: ${type}`); sendMessage(clientId, { type: 'error', message: `Unknown message type: ${type}` }); } } catch (error) { console.error('Error parsing message:', error); sendMessage(clientId, { type: 'error', message: 'Invalid message format.' }); } }); // Handle client disconnection ws.on('close', () => { handleDisconnect(clientId); }); ws.on('error', error => { console.error(`WebSocket error for client ${clientId}:`, error); handleDisconnect(clientId); }); // Send a ping every HEARTBEAT_INTERVAL to keep the connection alive ws.isAlive = true; ws.on('pong', () => { ws.isAlive = true; }); }); // Heartbeat to check for dead connections setInterval(() => { wss.clients.forEach(ws => { if (ws.isAlive === false) { console.log("Terminating connection due to inactivity."); return ws.terminate(); } ws.isAlive = false; ws.ping(() => {}); }); }, HEARTBEAT_INTERVAL); console.log(`WebSocket server started on port ${PORT}`); ``` **Explanation and Key Improvements:** * **Dependencies:** Uses the `ws` package for WebSocket functionality. You'll need to install it: `npm install ws` * **Configuration:** `PORT` and `HEARTBEAT_INTERVAL` are configurable at the top. * **Data Structures:** * `clients`: A `Map` that stores client IDs as keys and their corresponding WebSocket objects as values. This allows you to easily look up a client's WebSocket connection by its ID. * `rooms`: A `Map` that stores room IDs as keys and `Set`s of client IDs as values. Using a `Set` ensures that each client ID appears only once in a room. * **`generateId()`:** A simple function to generate unique client and room IDs. **Important:** For production, use a more robust UUID generation library (e.g., `uuid`). The current implementation is sufficient for basic testing but is not guaranteed to be collision-free in a high-volume environment. * **`sendMessage(clientId, message)`:** A helper function to send a JSON-stringified message to a specific client. Includes error handling to catch potential issues during sending. Also checks if the client is still connected before attempting to send. * **`broadcastToRoom(roomId, message, excludeClientId)`:** A helper function to send a JSON-stringified message to all clients in a room, optionally excluding a specific client. * **`handleDisconnect(clientId)`:** Handles client disconnections gracefully. It removes the client from the `clients` map and from any rooms they were in. It also notifies other clients in the room that the client has left. Critically, it also removes empty rooms. * **WebSocket Server (`wss`)**: * **`connection` event:** Handles new WebSocket connections. * Generates a unique client ID. * Stores the client's WebSocket object in the `clients` map. * Sends the client their ID. * Sets up message handling, close handling, and error handling for the client. * **`message` event:** Handles incoming messages from clients. * Parses the message as JSON. * Uses a `switch` statement to handle different message types: * `createRoom`: Creates a new room and adds the client to it. * `joinRoom`: Adds the client to an existing room. * `leaveRoom`: Removes the client from a room. * `message`: Broadcasts a message to all other clients in the room. * `ping`: Responds to a ping message (for heartbeat). * Includes error handling for JSON parsing and unknown message types. * **`close` event:** Handles client disconnections. * **`error` event:** Handles WebSocket errors. * **Heartbeat (Ping/Pong):** Implements a heartbeat mechanism to detect and close dead connections. This is crucial for maintaining a stable connection with clients, especially in environments with unreliable networks. * A `setInterval` function sends a `ping` message to each client every `HEARTBEAT_INTERVAL`. * The `ws.isAlive` flag is set to `false` before sending the ping. * If the client responds with a `pong` message, the `ws.isAlive` flag is set back to `true`. * If the client doesn't respond within the interval, the connection is terminated. * **Error Handling:** Includes `try...catch` blocks to handle potential errors during message parsing and sending. Also logs errors to the console for debugging. * **Clear Logging:** Logs important events to the console, such as client connections, disconnections, room creation, joining, and leaving. * **Message Types:** Uses a consistent message format with a `type` field to identify the type of message. This makes it easier to handle different types of messages on both the server and the client. **How to Run:** 1. **Save:** Save the code as a `.js` file (e.g., `linkup_server.js`). 2. **Install `ws`:** `npm install ws` 3. **Run:** `node linkup_server.js` **Client-Side Example (Conceptual):** ```javascript // Client-side JavaScript (Conceptual - adapt to your framework) const ws = new WebSocket('ws://localhost:8080'); ws.onopen = () => { console.log('Connected to WebSocket server'); }; ws.onmessage = event => { const message = JSON.parse(event.data); console.log('Received message:', message); switch (message.type) { case 'clientId': console.log('My client ID is:', message.clientId); myClientId = message.clientId; // Store the client ID break; // Handle other message types (roomCreated, roomJoined, message, etc.) } }; ws.onclose = () => { console.log('Disconnected from WebSocket server'); }; ws.onerror = error => { console.error('WebSocket error:', error); }; function sendMessage(type, data) { ws.send(JSON.stringify({ type: type, ...data })); } // Example usage: // To create a room: // sendMessage('createRoom'); // To join a room: // sendMessage('joinRoom', { roomId: 'someRoomId' }); // To send a message to a room: // sendMessage('message', { roomId: 'someRoomId', content: 'Hello, everyone!' }); ``` **Important Considerations for Production:** * **Security:** * **HTTPS:** Use HTTPS (WSS) to encrypt the WebSocket connection. This is essential for protecting sensitive data. * **Authentication:** Implement authentication to verify the identity of clients. This can be done using various methods, such as JWTs or OAuth. * **Authorization:** Implement authorization to control what clients are allowed to do. For example, you might want to restrict access to certain rooms or features based on the client's role. * **Input Validation:** Validate all input from clients to prevent injection attacks. * **Scalability:** * **Load Balancing:** Use a load balancer to distribute traffic across multiple server instances. * **Horizontal Scaling:** Design the server to be horizontally scalable, so you can easily add more instances as needed. * **Message Broker:** Consider using a message broker (e.g., RabbitMQ, Kafka) to handle message distribution, especially if you need to support a large number of concurrent connections. * **Reliability:** * **Monitoring:** Implement monitoring to track the health and performance of the server. * **Logging:** Log all important events to a file or database for debugging and auditing. * **Error Handling:** Implement robust error handling to prevent crashes and ensure that the server can recover from errors gracefully. * **Heartbeats:** The heartbeat mechanism is crucial for detecting and closing dead connections. * **UUIDs:** Use a proper UUID library for generating unique IDs. * **Frameworks:** Consider using a WebSocket framework like Socket.IO or Primus. These frameworks provide higher-level abstractions and features that can simplify development and improve performance. However, for a basic MCP server, the `ws` library is often sufficient. This improved version provides a more robust and complete foundation for building a Linkup MCP server in JavaScript. Remember to adapt the code to your specific needs and requirements. Good luck!

Higgsfield Director MCP

Transforms Claude into a complete faceless-video studio for ten proven niches, producing timed storyboards, voiceover calls, captions, and execution manifests that plug directly into Higgsfield's official MCP server.

Remote MCP Server (Authless)

Enables deployment of MCP servers on Cloudflare Workers without authentication requirements. Provides a template for creating custom tools that can be accessed remotely via Claude Desktop or the Cloudflare AI Playground.

Reporecall

Zero-tool-call codebase intelligence for Claude Code and MCP clients. Automatically injects the right code context, functions, callers, and call chains, before the LLM starts thinking. Replaces 4-6 grep/read round-trips with a single 5ms hook injection, cutting token usage by 3-8x.

chrome-hook MCP

Drives real Chromium browsers for multi-account testing and full network capture, with Cloudflare bypass via patched Playwright and real browser attach mode.

oanda-mcp

Enables read-only access to OANDA v20 forex trading data, including price quotes, candlestick history, account summaries, positions, and transactions, via Claude.

Pilot

A high-performance browser automation MCP server that provides AI agents with a fast, persistent Chromium instance via Playwright. It features reference-based element interaction, snapshot diffing, and manual handoff capabilities to handle complex tasks like CAPTCHAs.

Li Data Scraper MCP Server

Enables access to LinkedIn data through the Li Data Scraper API, supporting profile enrichment, company details, people search, post interactions, and activity tracking.

PM Counter Monitoring MCP Server

Enables monitoring and querying of telecom performance management (PM) counters from remote SFTP locations, providing access to interface statistics, CPU/memory utilization, BGP peer data, and system metrics through a conversational interface.

Uniswap MCP Server

Exposes Uniswap V2 and V3 on-chain data and swap execution as MCP tools, resources, and prompts, enabling AI agents to query prices, inspect pools, get quotes, and execute trades.

Streamfog MCP

AI-driven AR lens orchestrator for live OBS streams that enables control of Streamfog face filters, AR effects, and Vtuber avatars through MCP tools via the local Streamer.bot WebSocket bridge.

Python MCP Server Template

A standardized foundation for building Model Context Protocol servers that integrate with VS Code, using Python with stdio transport for seamless AI tool integration.

BDDK MCP Server

An offline-first MCP server for searching, retrieving, and analyzing Turkish banking regulation data from BDDK and mevzuat.gov.tr.

Google-Flights-MCP-Server

这个 MCP 服务器允许 AI 助手使用 Google Flights 在线搜索航班信息。它可以查找特定日期的航班，也可以搜索一系列日期以查找所有选项或仅查找最便宜的选项。

contextcore-mcp

Provides secure, read-only access to ContextCore project context (vision, audience, scope, tech decisions, etc.) for MCP-aware agents like Cursor and Claude Code, with server-side access enforcement.

Google Contacts MCP Server

Enables AI assistants to access and search Google Contacts through per-user OAuth authentication on serverless AWS Lambda. Provides read-only access to personal contacts with zero data storage and real-time API queries.