Skip to main content
Glama
lsd-so

LSD MCP Server

by lsd-so

LSD MCP server

Image displaying MCP

Immediately gather an aggregation of high quality info directly from a website just by giving LSD the link via Claude MCP.

You will see Claude connect to the internet and:

  • Write LSD SQL

  • Self-correct LSD SQL

  • Run LSD SQL that's connected to cloud browsers

Demo

Here's a demo of what that looks like in action:

Getting trending repositories using LSD

We treated Claude to psychedelic therapy on LSD and now it can just do things. Here's a longer video on YouTube

Related MCP server: MCP-Python

Contents

Quickstart

Dependencies

To run the MCP server, you'll need both Python and uv installed. To use the MCP server, you'll need to download either the Claude desktop app or another MCP client.

To use LSD, you'll need to sign up and create an API key so your queries are privately associated to only your account. You can do so for free with a Google account.

Giving Claude LSD

  1. Clone this repository onto your computer

$ git clone https://github.com/lsd-so/lsd-mcp.git
$ cd lsd-mcp
  1. Update the values in the .env file with LSD_USER containing the email you have an account on LSD with and LSD_API_KEY containing the API key you obtained from the profile page.

LSD_USER=<your_email_here>
LSD_API_KEY=<api_key_from_your_profile_page>
  1. Give LSD to Claude

$ uv run mcp install app.py

Note: Every time you run mcp install, if you needed to update claude_desktop_config.json the first time, you will need to remember to update the path to uv each time you install the MCP server.

  1. Restart the Claude desktop app and, now, Claude should be able to do trippy things on LSD.

Claude on LSD

If it's the first time in a chat session where you'd like to have Claude use LSD, because we're not popular enough to get caught in Anthropic's crawls, you'll need to first leverage our custom prompt which feeds in our documentation as part of the assistance.

Using custom prompt

See the write_lsd_sql function if you're interested in how it works but it just boils down to a convenient rule we added to our SCAN keyword enabling a developer or LLM to retrieve the documentation for our language in markdown (if you'd like to run it yourself).

SCAN https://lsd.so/docs/database/language

Failed to start MCP server

Using custom prompt

If you encounter error messages when starting Claude desktop along the lines of the following message:

Failed to start MCP server: Could not start MCP server LSD: Error: spawn uv ENOENT

First time running an MCP server

If this is your first time using an MCP server on your computer than, to remedy the error shown above, follow the instructions under the Add the Filesystem MCP Server step to create a claude_desktop_config.json file that Claude desktop can know to refer to.

Missing executable

Additionally, if you've never done anything relating to Postgres on your computer, then you may encounter an error message containing something like the following:

Error: pg_config executable not found.

To fix, simply install postgres to your machine using an available package manager. If you're on a Mac, you can do so using brew.

$ brew install postgres

Incomplete path

Otherwise and maybe in addition to the issue shown above, in the location where claude_desktop_config.json is stored (is ~/Library/Application Support/Claude/claude_desktop_config.json if you're running on a Mac), modify the value of the command key under mcpServers -> LSD to contain the full path to running uv (run which uv in your terminal if you don't already know what it is).

{
  "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"
      ]
    }
  }
}

Once you've done that, restart Claude desktop and the problem should be resolved. If not, please file an issue.

What is MCP?

MCP, short for model context protocol, provides a communication layer between Claude and computer-accessible interfaces such as the filesystem or web APIs. If a limiting factor of LLMs was its detachment from the "real world" since it's just a text generating model, MCP allows users and developers to bring Claude to life.

What is LSD?

LSD SQL, a DSL for the web, enables developers to connect the internet to your applications as though it were a postgres compatible database. Rather than present a new semantic web ontology or make a new internet, it provides a dynamic declarative language that sits atop the existing one.

Designed to target browsers instead of an architecture, LSD allows for powerful parallelization while preserving simplicity with just-in-time tables meaning you can just get data without running a CREATE TABLE beforehand. Sign up for free with a Google account to start querying the internet!

Here's an example of something you can do with LSD, takes ~30 sec if first run

Contact

Reach out to pranav at lsd dot so if you have any questions.

Smithery

Installing via Smithery

To install LSD MCP Server for Claude Desktop automatically via Smithery:

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.

TDQS

B3/5.0
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.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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

  • 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
  • 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,567
    MIT
  • 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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lsd-so/lsd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server