Skip to main content
Glama
enesjakozh
lsd-so

LSD MCP Server

by lsd-so
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

LSD MCPサーバー

MCPを表示した画像

Claude MCP 経由で LSD にリンクを提供するだけで、Web サイトから高品質の情報の集合をすぐに直接収集できます。

Claude がインターネットに接続し、次の操作を実行できるようになります。

  • LSD SQLを書く

  • 自己修正LSD SQL

  • クラウドブラウザに接続されたLSD SQLを実行する

デモ

実際に動作している様子のデモを以下に示します。

LSDを使用してトレンドのリポジトリを取得する

クロードにLSDを使ったサイケデリック療法を施したら、今では何でもできるようになった。YouTubeにもっと長い動画があるよ

Related MCP server: MCP-Python

コンテンツ

クイックスタート

依存関係

MCPサーバーを実行するには、 PythonとUVの両方がインストールされている必要があります。MCPサーバーを使用するには、 Claudeデスクトップアプリまたは別のMCPクライアントをダウンロードする必要があります。

LSD を使用するには、サインアップしてAPI キーを作成する必要があります。これにより、クエリはあなたのアカウントにのみ非公開で関連付けられます。Googleアカウントをお持ちであれば、無料でご利用いただけます。

クロードにLSDを与える

  1. このリポジトリをコンピュータにクローンします

$ git clone https://github.com/lsd-so/lsd-mcp.git
$ cd lsd-mcp

  1. .envファイル内の値を、LSD のアカウントに使用しているメール アドレスを含むLSD_USERと、プロフィール ページから取得した API キーを含むLSD_API_KEYで更新します。

LSD_USER=<your_email_here>
LSD_API_KEY=<api_key_from_your_profile_page>

  1. クロードにLSDを与える

$ uv run mcp install app.py

注意: mcp install実行するたびに、最初にclaude_desktop_config.json更新する必要がある場合は、MCP サーバーをインストールするたびにuvへのパスを更新することを忘れないでください。

  1. Claude デスクトップ アプリを再起動すると、Claude は LSD で幻覚的なことを実行できるようになるはずです。

LSDを摂取したクロード

チャット セッションで初めて Claude に LSD を使ってもらいたい場合は、Anthropic のクロールに巻き込まれるほど人気がないため、まずはアシスタンスの一環としてドキュメントを入力するカスタム プロンプトを活用する必要があります。

カスタムプロンプトの使用

仕組みに興味がある場合はwrite_lsd_sql関数を参照してください。これは、開発者または LLM がマークダウンで言語のドキュメントを取得できるように、SCAN キーワードに追加した便利なルールに要約されます (自分で実行する場合)。

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 （モデルコンテキストプロトコル）は、 ClaudeとファイルシステムやWeb APIなどのコンピュータアクセス可能なインターフェースとの間の通信層を提供します。LLMの制約要因の一つは、テキスト生成モデルであるため「現実世界」から切り離されていることでしたが、MCPはユーザーと開発者がClaudeに命を吹き込むことを可能にします。

LSDとは何ですか？

LSD SQLはWeb用DSLであり、開発者はインターネットをまるでPostgres互換データベースのようにアプリケーションに接続できます。LSD SQLは、新しいセマンティックWebオントロジーを提示したり、新しいインターネットを構築したりするのではなく、既存のオントロジーの上に構築される動的な宣言型言語を提供します。

LSDは、アーキテクチャではなくブラウザをターゲットに設計されており、ジャストインタイムテーブルによるシンプルさを維持しながら強力な並列処理を実現します。つまり、事前にCREATE TABLEを実行することなくデータを取得できます。Googleアカウントで無料登録して、インターネットクエリを始めましょう！

LSDでできることの例です。初回実行には約30秒かかります。

接触

ご質問がある場合は、pranav at lsd dot so までお問い合わせください。

鍛冶屋

鍛冶屋のバッジ

Smithery経由でインストール

Smithery経由で Claude Desktop 用の LSD MCP サーバーを自動的にインストールするには:

npx -y @smithery/cli install @lsd-so/lsd-mcp --client claude

Available Tools

4 tools
run_lsdC

Runs LSD SQL using user credentials in .env

ParametersJSON Schema
NameRequiredDescriptionDefault
lsd_sql_codeYes

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
NameRequiredDescriptionDefault
queryYes

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
NameRequiredDescriptionDefault
trip_identifierYes

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
NameRequiredDescriptionDefault
lsd_sql_codeYes

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.

  1. 4 tool updates
    • First observedrun_lsd
    • First observedsearch_trips
    • First observeduse_trip
    • First observedview_lsd
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

Resources

Related MCP Connectors

  • Dappier
    com.dappier.mcp

    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.

    SearchFinanceWeb Scraping
    2
  • Remote Desktop CommanderOAuth
    app.desktopcommander

    Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer

    Shell AccessOS Automation
    2145
  • RampOAuth
    com.ramp.ramp-mcp-remote

    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.

    FinanceDatabasesSearch
    2
  • Artificial Wit AIOAuth
    com.artificialwit

    MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.

    ERP SystemsCRMKnowledge & Memory
    2

Related MCP Servers

  • MCP-Python

    rhabraken
    F
    license
    Not graded
    quality
    D
    maintenance
    A server that enables interaction with PostgreSQL, MySQL, MariaDB, or SQLite databases through Claude Desktop using natural language queries.
    1
    -

  • MCP Web Research Server

    jevy
    A
    license
    B
    quality
    D
    maintenance
    A 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.
    3
    1,743 npm
    MIT

  • MCP Server

    tcpipuk
    A
    license
    Not graded
    quality
    D
    maintenance
    A 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.
    3
    GPL 3.0

Appeared in Searches