Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lighthouse-mcp list my lighthouse instances and their status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for Tencent Cloud Lighthouse（轻量应用服务器）管理。
让 AI Agent（Claude Code / OpenClaw / Cursor）通过自然语言管理你的 Lighthouse 服务器。
工具 | 说明 |
| 查询所有可用地域 |
| 查询实例列表 |
| 获取监控数据（CPU/内存/带宽/磁盘IO） |
| 查看防火墙规则 |
| 添加防火墙规则 |
| 删除防火墙规则 |
| 查看快照列表 |
| 远程执行命令（TAT） |
| 查询命令执行状态 |
Related MCP server: hcloud-mcp
npm install -g lighthouse-mcp
# 或
npx lighthouse-mcp设置腾讯云 API 密钥：
export TENCENT_SECRET_ID="your_secret_id"
export TENCENT_SECRET_KEY="your_secret_key"或创建 .env 文件：
TENCENT_SECRET_ID=your_secret_id
TENCENT_SECRET_KEY=your_secret_key密钥获取：腾讯云控制台 > API密钥管理
添加到 ~/.claude/claude_desktop_config.json 或项目 .mcp.json：
{
"mcpServers": {
"lighthouse": {
"command": "npx",
"args": ["-y", "lighthouse-mcp"],
"env": {
"TENCENT_SECRET_ID": "your_secret_id",
"TENCENT_SECRET_KEY": "your_secret_key"
}
}
}
}添加到 openclaw.json 的 tools.mcp 配置：
{
"tools": {
"mcp": {
"lighthouse": {
"command": "node",
"args": ["dist/index.js"],
"cwd": "/path/to/lighthouse-mcp",
"env": {
"TENCENT_SECRET_ID": "...",
"TENCENT_SECRET_KEY": "..."
}
}
}
}
}你: 我有几台服务器？状态怎么样？
Agent: [调用 describe_instances] → 你有 2 台服务器，上海那台运行中...
你: 帮我把上海的服务器防火墙打开 443 端口
Agent: [调用 create_firewall_rules] → 已添加 TCP 443 规则
你: 最近的 CPU 使用率怎么样？
Agent: [调用 get_monitor_data] → 最近 6 小时 CPU 均值 12%...@modelcontextprotocol/sdk — MCP 协议 SDK
tencentcloud-sdk-nodejs-lighthouse — 腾讯云 Lighthouse SDK
TypeScript + ES Modules
MIT
为实例添加防火墙规则
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| instanceId | Yes | 实例 ID | |
| firewallRules | Yes | 防火墙规则列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'add firewall rules', omitting behavioral traits like idempotency, overwrite behavior, failure modes, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words, but could benefit from structuring to separate purpose from parameters and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about return values, side effects, whether rules are appended or replaced, and how to handle errors. For a creation tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter, so the description adds minimal extra value. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add) and resource (firewall rules for instance), but does not differentiate from sibling tools like delete_firewall_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as whether it appends to existing rules or replaces them, or prerequisites like instance existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除实例的防火墙规则
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| instanceId | Yes | 实例 ID | |
| firewallRules | Yes | 要删除的防火墙规则（按协议+端口匹配） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description does not disclose destructive nature, irreversibility, or potential impacts (e.g., affecting running instances). Only the word 'delete' implies mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, but lacks structure for a tool with 3 parameters. Could benefit from explaining rule matching logic or providing examples. Not excessively long, but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 3 required params, description is insufficient. Missing impact, return values, error scenarios, and prerequisites for a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for each parameter. Description adds no extra meaning beyond schema. Baseline 3 is appropriate as schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'delete firewall rules of an instance' with a specific verb and resource. It distinguishes from sibling create_firewall_rules but lacks explicit differentiation from other delete-like tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The description is a bare statement of action without usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询 TAT 命令执行任务状态
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| invocationTaskId | Yes | 任务 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It fails to mention any side effects, permissions, limitations, or output format, leaving significant unknowns for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the tool's purpose. It avoids unnecessary words, though it could benefit from slight elaboration without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should at least hint at the return value structure. It does not, nor does it explain what TAT represents. The tool's moderate complexity warrants more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (region, invocationTaskId) described in the schema. The description adds no additional context beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: querying the status of TAT command execution tasks. It uses a specific verb and resource, distinguishing it from sibling tools like execute_command which executes commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions for its use. The description assumes the agent already knows when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询实例的防火墙规则
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| instanceId | Yes | 实例 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication needs, rate limits, or what happens with missing rules. The description carries the full burden but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence), but it lacks structure and additional information. It does not waste words, but it is also underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should provide some indication of the returned data. It does not. The description is minimal and leaves out important context for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so baseline is 3. The description adds no additional meaning beyond the schema, but it does not detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' (query) and resource '防火墙规则' (firewall rules) for an instance, differentiating it from sibling tools like create/delete_firewall_rules and other describe tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, or when not to use it. There is no mention of prerequisites or context, leaving the agent without enough information to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询轻量应用服务器实例列表
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域，如 ap-guangzhou, ap-shanghai | |
| instanceIds | No | 实例 ID 列表（可选） | |
| limit | No | 返回数量限制，默认 20 | |
| offset | No | 偏移量，默认 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states 'query list' without disclosing pagination behavior, read-only nature, or any side effects. Behavioral traits are completely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one short phrase. However, it lacks structure and front-loads important constraints (like required region) that could be better emphasized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the response contains (e.g., fields, pagination info). It fails to do so. The 'required' field is known from schema, but description does not highlight key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning the schema already documents all parameters. The description adds no extra meaning beyond the schema for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool's purpose: querying a list of instances. It distinguishes from sibling tools like describe_firewall_rules and describe_snapshots, but does not mention optional filtering or exactly what is listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives like get_monitor_data or describe_regions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询所有可用的 Lighthouse 地域列表
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only query via '查询' but does not explicitly state side effects, authentication needs, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool, the description is mostly complete. Could optionally mention output format or language, but current version is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, baseline is 4. Description adds no parameter info, but none is needed as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb '查询' (query) and resource 'Lighthouse 地域列表' (Lighthouse regions list), clearly distinguishing it from sibling tools like describe_instances and describe_firewall_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as whether it should be called before other operations or if it requires authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询实例的快照列表
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| instanceId | Yes | 实例 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the basic purpose without any details on permissions, limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and wastes no words. However, it is extremely brief, which limits usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description is minimally adequate but lacks details about return format, pagination, or snapshot statuses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for region and instanceId. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (查询/query) and specific resource (实例的快照列表/snapshot list of instance), distinguishing it from siblings like describe_instances and describe_firewall_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as filtering by snapshot attributes or using other describe tools. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在实例上远程执行命令（通过 TAT）
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| instanceId | Yes | 实例 ID | |
| command | Yes | 要执行的命令，最大 2048 字符 | |
| systemType | No | 系统类型：Linux 或 Windows，默认 Linux |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits like execution mode (synchronous/asynchronous), failure handling, destructive potential, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, concise but minimal. It could be front-loaded with more critical info like command length limit or system type importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a command execution tool with 4 parameters and no output schema, the description lacks details on return values (e.g., output, exit code), TAT prerequisites, and command constraints beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; it only mentions the tool's function without elaborating on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute commands remotely on the instance (via TAT)', specifying verb, resource, and mechanism. It distinguishes from sibling tools like describe_instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like describe_command_tasks. No prerequisites, limitations, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取实例监控数据（CPU/内存/带宽/磁盘IO等）
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | 地域 | |
| instanceId | Yes | 实例 ID | |
| indicators | Yes | 监控指标：CPU利用率, 内存利用率, 公网出带宽, 公网入带宽, 系统盘读IO, 系统盘写IO | |
| startTime | No | 开始时间，格式 2026-01-01 00:00:00（可选） | |
| endTime | No | 结束时间（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'get', implying read-only, but fails to note rate limits, required permissions, data availability window, or response format. For a monitoring tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description omits critical context: default time range, data granularity, how multiple indicators are returned, and error handling. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter explanations. The description adds no new meaning beyond listing indicator examples already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'instance monitoring data', listing common indicator types (CPU, memory, bandwidth, disk IO). It effectively distinguishes from sibling tools focused on firewalls, instances, and commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., describe_instances for instance info) or when not to use it. The description only states what it does, without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_firewall_rulesdelete_firewall_rulesdescribe_command_tasksdescribe_firewall_rulesdescribe_instancesdescribe_regionsdescribe_snapshotsexecute_commandget_monitor_dataEach tool targets a distinct operation: firewall management (create/delete/describe), command execution and task status, instance listing, region listing, snapshots, and monitoring. No two tools overlap in purpose.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_firewall_rules, describe_instances, get_monitor_data). Verbs like describe, create, delete, execute, get are used predictably.
With 9 tools, the server is well-scoped for managing key aspects of Lighthouse instances: firewall, command execution, monitoring, and listing resources. The number is appropriate without being overwhelming.
The tool set covers firewall, command execution, monitoring, and listing of instances/snapshots/regions, but lacks instance lifecycle operations (create, delete, stop, start) and snapshot CRUD (only describe). This leaves notable gaps for full instance management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for ByteDance Seedream AI image generation
MCP server for Appcircle mobile CI/CD platform.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BlueBridge-E/lighthouse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
