LSD MCP Server
LSD MCP 서버

클로드 MCP를 통해 LSD에 링크를 제공하는 것만으로 웹사이트에서 고품질 정보를 즉시 수집할 수 있습니다.
클로드가 인터넷에 연결되는 모습을 볼 수 있습니다.
LSD SQL 작성
자체 수정 LSD SQL
클라우드 브라우저에 연결된 LSD SQL을 실행하세요
데모
실제로 어떤 모습인지 보여주는 데모는 다음과 같습니다.

클로드에게 LSD 환각 치료를 해줬더니 이제 정말 효과가 있더라고요. YouTube에 더 긴 영상이 있습니다.
Related MCP server: MCP-Python
내용물
빠른 시작
종속성
MCP 서버를 실행하려면 Python 과 uv가 모두 설치되어 있어야 합니다. MCP 서버를 사용하려면 Claude 데스크톱 앱 이나 다른 MCP 클라이언트를 다운로드해야 합니다.
LSD를 사용하려면 가입하고 API 키를 생성 해야 합니다. 그러면 쿼리가 본인 계정에만 비공개로 연결됩니다. Google 계정이 있으면 무료로 이용할 수 있습니다.
클로드에게 LSD를 주다
이 저장소를 컴퓨터에 복제하세요
지엑스피1
.env파일의 값을 LSD 계정이 있는 이메일이 포함된LSD_USER와 프로필 페이지에서 얻은 API 키가 포함된LSD_API_KEY로 업데이트합니다.
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 경로를 업데이트해야 합니다.
클로드 데스크톱 앱을 다시 시작하면 이제 클로드가 LSD를 복용한 상태에서 이상한 행동을 할 수 있을 것입니다.
LSD를 사용하는 클로드
Anthropic의 크롤링에 걸릴 만큼 인기가 많지 않기 때문에 채팅 세션에서 처음으로 클로드가 LSD를 사용하기를 원한다면 먼저 도움말의 일부로 설명서를 제공하는 사용자 지정 프롬프트를 활용해야 합니다.

write_lsd_sql 함수의 작동 방식에 관심이 있다면 살펴보세요. 하지만 핵심은 개발자나 LLM이 마크다운에서 언어에 대한 문서를 검색할 수 있도록 하는 SCAN 키워드에 추가한 편리한 규칙 일 뿐입니다( 직접 실행하고 싶다면 ).
SCAN https://lsd.so/docs/database/languageMCP 서버를 시작하지 못했습니다.

Claude desktop을 시작할 때 다음 메시지와 같은 오류 메시지가 나타나는 경우:
Failed to start MCP server: Could not start MCP server LSD: Error: spawn uv ENOENTMCP 서버를 처음 실행합니다
컴퓨터에서 처음으로 MCP 서버를 사용하는 경우 위에 표시된 오류를 해결하려면 파일 시스템 MCP 서버 추가 단계의 지침에 따라 Claude Desktop에서 참조할 수 있는 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 (모델 컨텍스트 프로토콜) 는 Claude 와 파일 시스템 이나 웹 API 와 같은 컴퓨터 접근 가능 인터페이스 간의 통신 계층을 제공합니다. LLM의 한계점이 텍스트 생성 모델에 불과하여 "실제 세계"와의 분리였다면, MCP는 사용자와 개발자가 Claude에 생명을 불어넣을 수 있도록 지원합니다.
LSD란 무엇인가?
웹용 DSL 인 LSD SQL을 사용하면 개발자가 마치 Postgres 호환 데이터베이스 처럼 인터넷을 애플리케이션에 연결할 수 있습니다. 새로운 시맨틱 웹 온톨로지를 제시하거나 새로운 인터넷을 만드는 대신, 기존 언어를 기반으로 하는 동적 선언적 언어를 제공합니다.
아키텍처 가 아닌 브라우저를 대상으로 설계된 LSD는 JIT(Just-In-Time) 테이블 방식으로 단순성을 유지하면서도 강력한 병렬 처리를 지원합니다. 즉, CREATE TABLE을 미리 실행하지 않고도 데이터를 바로 가져올 수 있습니다. Google 계정으로 무료로 가입하고 인터넷 검색을 시작해 보세요!
LSD로 할 수 있는 일의 예는 다음과 같습니다. 처음 실행하면 약 30초가 걸립니다.
연락하다
질문이 있으시면 pranav@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
| Name | Required | Description | Default |
|---|---|---|---|
| lsd_sql_code | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_identifier | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| lsd_sql_code | Yes |
TDQS
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.
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.
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.
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.
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.
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
Scored across 4 tools
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.
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.
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.
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
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
- AlicenseBqualityFmaintenanceA server facilitating web search functionality by utilizing Perplexity AI's API, designed to integrate with the Claude desktop client for enhanced search queries.1308MIT
- 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