A
licenseB
qualityF
maintenanceA server facilitating web search functionality by utilizing Perplexity AI's API, designed to integrate with the Claude desktop client for enhanced search queries.
1
308
MIT
LSD MCP Server
by lsd-so
LSD MCP 服务器
只需通过 Claude MCP 向 LSD 提供链接，即可立即从网站直接收集大量高质量信息。
您将看到 Claude 连接到互联网并且：
编写 LSD SQL
自我纠正的 LSD SQL
运行连接到云浏览器的 LSD SQL
演示
以下是实际操作的演示：
我们给克劳德做了迷幻药LSD（迷幻药）治疗，现在它真的有效了。YouTube上有一个更长的视频
Related MCP server: MCP-Python
内容
快速入门
依赖项
要运行 MCP 服务器，您需要安装Python和uv 。要使用 MCP 服务器，您需要下载Claude 桌面应用程序或其他 MCP 客户端。
要使用 LSD，您需要注册并创建 API 密钥，以便您的查询仅与您的帐户私下关联。您可以使用 Google 帐户免费进行此操作。
给克劳德迷幻药
将此存储库克隆到您的计算机上
$ git clone https://github.com/lsd-so/lsd-mcp.git
$ cd lsd-mcp使用
LSD_USER（包含您在 LSD 上拥有帐户的电子邮件）和LSD_API_KEY包含您从个人资料页面获取的 API 密钥）更新.env文件中的值。
LSD_USER=<your_email_here>
LSD_API_KEY=<api_key_from_your_profile_page>给克劳德服用 LSD
$ uv run mcp install app.py**注意：**每次运行mcp install时，如果您第一次需要更新claude_desktop_config.json ，则需要记住在每次安装 MCP 服务器时更新uv的路径。
重新启动 Claude 桌面应用程序，现在，Claude 应该能够在 LSD 上做一些迷幻的事情。
克劳德吸食迷幻药
如果这是您在聊天会话中第一次想让 Claude 使用 LSD，因为我们不够受欢迎，不会被 Anthropic 的爬行所吸引，您需要首先利用我们的自定义提示，该提示将在我们的文档中提供作为帮助的一部分。
如果您对它的工作原理感兴趣，请参阅write_lsd_sql函数，但它只是归结为我们添加到 SCAN 关键字中的一个方便的规则，使开发人员或 LLM 能够在 markdown 中检索我们语言的文档（如果您想自己运行它）。
SCAN https://lsd.so/docs/database/language无法启动 MCP 服务器
如果您在启动 Claude 桌面时遇到类似以下消息的错误消息：
Failed to start MCP server: Could not start MCP server LSD: Error: spawn uv ENOENT首次运行 MCP 服务器
如果这是您第一次在计算机上使用 MCP 服务器，那么为了纠正上面显示的错误，请按照 添加文件系统 MCP 服务器步骤下的说明创建 Claude 桌面可以参考的claude_desktop_config.json文件。
缺少可执行文件
此外，如果您从未在计算机上执行过任何与Postgres相关的事情，那么您可能会遇到包含以下内容的错误消息：
Error: pg_config executable not found.要修复此问题，只需使用可用的包管理器将postgres安装到您的计算机上即可。如果您使用的是 Mac，则可以使用 brew 进行安装。
$ brew install postgres路径不完整
否则，也许除了上面显示的问题之外，在存储claude_desktop_config.json的位置（如果您在 Mac 上运行，则为~/Library/Application Support/Claude/claude_desktop_config.json ），修改mcpServers -> LSD下的command键的值以包含运行uv的完整路径（如果您还不知道它是什么，请在终端中运行which uv ）。
{
"mcpServers": {
"LSD": {
- "command": "uv",
+ "command": "/Users/your_mac_name/.local/bin/uv",
"args": [
"run",
"--with",
"mcp[cli]",
"--with",
"psycopg2-binary",
"mcp",
"run",
"/Users/y/testing-mcp/lsd-mcp/app.py"
]
}
}
}完成后，重新启动 Claude 桌面，问题应该就能解决了。如果没有解决，请提交问题。
什么是 MCP？
MCP 是模型上下文协议 (MCP)的缩写，它在Claude与计算机可访问接口（例如文件系统或Web API）之间提供了一个通信层。如果说 LLM 的限制因素在于它脱离了“现实世界”，因为它只是一个文本生成模型，那么 MCP 则允许用户和开发者将 Claude 变为现实。
LSD 是什么？
LSD SQL 是一种 Web 领域特定语言 (DSL) ，它使开发人员能够将互联网连接到应用程序，就像连接Postgres 兼容数据库一样。它并非提出新的语义网本体或构建新的互联网，而是提供一种基于现有语言的动态声明式语言。
LSD 的设计目标是浏览器而非架构，它支持强大的并行处理，同时保留了即时表的简单性，这意味着您无需事先运行 CREATE TABLE 语句即可直接获取数据。立即免费注册 Google 帐户，开始查询互联网！
以下是使用 LSD 进行操作的示例，首次运行大约需要 30 秒
接触
如果您有任何疑问，请联系 pranav at lsd dot。
锻造工艺
通过 Smithery 安装
要通过Smithery自动为 Claude Desktop 安装 LSD MCP 服务器：
npx -y @smithery/cli install @lsd-so/lsd-mcp --client claudeAvailable Tools
4 toolsrun_lsdC
Runs LSD SQL using user credentials in .env
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lsd_sql_code | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'using user credentials in .env', hinting at authentication needs, but doesn't disclose behavioral traits such as whether it's read-only or destructive, rate limits, or what the tool actually does beyond running SQL. This leaves significant gaps for a tool that likely executes SQL queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, though it could benefit from more detail given the lack of annotations and schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running SQL queries, no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what LSD SQL is, what the tool returns, or any error handling, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't add any meaning to the parameter 'lsd_sql_code' beyond what's implied by the name. No details on syntax, format, or examples are provided, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Runs LSD SQL using user credentials in .env', which provides a verb ('Runs') and resource ('LSD SQL'), but it's vague about what LSD SQL is and doesn't distinguish it from sibling tools like 'view_lsd'. It's not tautological but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'search_trips' or 'view_lsd'. The description mentions user credentials in .env, which implies a context for authentication, but doesn't specify use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_tripsC
Returns a list of objects with LSD trips available to the user and what each of them do.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions returning a list but doesn't specify whether this is a read-only operation, if it requires authentication, what happens on errors, or any rate limits. This leaves significant gaps for a tool that presumably interacts with user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is reasonably concise, but it's not front-loaded with critical information and includes vague phrasing like 'what each of them do' which adds little value. It could be more structured to clarify purpose upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of searching user-available trips, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what the returned objects contain, how results are filtered, or any behavioral traits, making it inadequate for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'query' with 0% description coverage, and the tool description provides no information about what the 'query' parameter should contain, its format, or examples. This fails to compensate for the low schema coverage, leaving the parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'returns a list of objects with LSD trips available to the user', which provides a basic purpose (verb+resource). However, it's vague about what 'objects' contain and what 'what each of them do' means, and it doesn't distinguish this tool from siblings like 'view_lsd' or 'use_trip'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'view_lsd' or 'use_trip'. The description implies it's for searching available trips, but there's no explicit context, exclusions, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
use_tripC
Invokes a trip on LSD based on its identifier using the [ACCORDING TO] keywords.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| trip_identifier | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'invokes a trip on LSD,' which suggests a mutation or action, but fails to describe key traits such as permissions required, side effects, error handling, or response format. The phrase '[ACCORDING TO] keywords' adds some context but is vague and insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with one sentence, which is appropriately sized for a simple tool. However, the phrase '[ACCORDING TO] keywords' is unclear and adds noise without value, reducing efficiency. It is front-loaded with the main action but could be more streamlined by omitting ambiguous elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving 'invoking' a trip on LSD), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It does not cover essential aspects like what the tool returns, error conditions, or prerequisites, making it inadequate for effective use by an AI agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description does not add meaningful semantics beyond the schema. It references 'trip_identifier' indirectly but does not explain what this identifier is, its format, or how to obtain it. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'invokes a trip on LSD based on its identifier,' which provides a vague purpose with the verb 'invokes' and resource 'trip on LSD.' However, it lacks specificity about what 'invokes' means (e.g., starts, executes, triggers) and does not clearly differentiate from sibling tools like 'run_lsd' or 'search_trips,' leaving ambiguity in its exact function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the phrase 'using the [ACCORDING TO] keywords,' which implies some context or method for usage, but it does not provide explicit guidance on when to use this tool versus alternatives like 'run_lsd' or 'search_trips.' There are no clear when/when-not instructions or named alternatives, resulting in minimal actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view_lsdC
"Returns a URL to a page where the user can view results as well as a visual playback of LSD SQL evaluation
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lsd_sql_code | Yes |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a URL but doesn't describe what the URL leads to in detail, whether it's interactive or static, if authentication is needed, or any side effects. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without unnecessary details. It's front-loaded and wastes no words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter, no annotations, no output schema), the description is incomplete. It lacks details on the URL's nature, expected input format, and how it differs from siblings like 'run_lsd', making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'LSD SQL evaluation' but doesn't explain the 'lsd_sql_code' parameter beyond what's implied. With 0% schema description coverage and 1 required parameter, the description fails to add meaningful semantics, such as the format or purpose of the code input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns a URL to a page where the user can view results as well as a visual playback of LSD SQL evaluation.' It specifies the verb ('Returns a URL') and resource ('page for viewing LSD SQL evaluation results and playback'), though it doesn't explicitly differentiate from sibling tools like 'run_lsd' or 'search_trips'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'view_lsd' over 'run_lsd' or other siblings, nor does it specify prerequisites or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- First observed
run_lsd - First observed
search_trips - First observed
use_trip - First observed
view_lsd
TDQS
B3/5.0
Scored across 4 tools
Disambiguation4/5
The tools have mostly distinct purposes: run_lsd executes SQL queries, search_trips lists available trips, use_trip invokes a specific trip, and view_lsd provides a URL for viewing results. However, run_lsd and use_trip could be slightly ambiguous since both involve executing LSD operations, but their descriptions clarify that run_lsd is for SQL queries while use_trip is for invoking trips, preventing major confusion.
Naming Consistency4/5
The tool names follow a consistent verb_noun pattern (e.g., run_lsd, search_trips, use_trip, view_lsd), all using snake_case with clear action verbs. There are no deviations in style, making them predictable and readable, though the pattern is simple and not highly structured.
Tool Count5/5
With 4 tools, the count is well-scoped for the LSD MCP server's purpose of interacting with LSD trips and SQL. Each tool serves a distinct function (executing, searching, invoking, and viewing), and there are no redundant or missing tools that would make the set feel too thin or bloated.
Completeness3/5
The tool set covers core operations for LSD interactions: executing SQL (run_lsd), discovering trips (search_trips), using trips (use_trip), and viewing results (view_lsd). However, there are notable gaps such as no update or delete operations for trips, and no tools for managing user credentials or handling errors, which could limit agent workflows in more complex scenarios.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
The Dappier MCP server connects LLMs and AI agents to real-time, rights-cleared, proprietary data from trusted sources across various domains. It provides specialized knowledge through real-time web search, financial stock market and crypto data access, AI-powered content recommendations from premium publishers, and structured outputs with sub-300ms response times, enabling AI systems to respond to current events and trends.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA server that enables interaction with PostgreSQL, MySQL, MariaDB, or SQLite databases through Claude Desktop using natural language queries.1-
- AlicenseBqualityDmaintenanceA server that integrates with Claude Desktop to enable real-time web research capabilities, allowing users to search Google, extract webpage content, and capture screenshots directly from conversations.31,743 npmMIT
- AlicenseNot gradedqualityDmaintenanceA server that enables AI assistants like Claude to safely run Python code and access websites, processing data for better AI understanding while providing helpful error messages.3GPL 3.0