Skip to main content
Glama
enesjakozh
lsd-so

LSD MCP Server

by lsd-so
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Servidor LSD MCP

Imagen que muestra MCP

Recopile de inmediato una recopilación de información de alta calidad directamente desde un sitio web con solo proporcionarle a LSD el enlace a través de Claude MCP.

Verás a Claude conectarse a Internet y:

  • Escribir LSD SQL

  • LSD SQL de autocorrección

  • Ejecute LSD SQL que esté conectado a los navegadores en la nube

Manifestación

Aquí hay una demostración de cómo se ve esto en acción:

Obtener repositorios de tendencias usando LSD

Le dimos a Claude terapia psicodélica con LSD y ahora puede hacer cosas. Aquí hay un video más largo en YouTube.

Related MCP server: MCP-Python

Contenido

Inicio rápido

Dependencias

Para ejecutar el servidor MCP, necesitará tener instalados Python y uv . Para usarlo, deberá descargar la aplicación de escritorio Claude u otro cliente MCP .

Para usar LSD, deberá registrarse y crear una clave API para que sus consultas se asocien de forma privada únicamente a su cuenta. Puede hacerlo gratis con una cuenta de Google .

Dándole LSD a Claude

  1. Clona este repositorio en tu computadora

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

  1. Actualice los valores en el archivo .env con LSD_USER que contiene el correo electrónico con el que tiene una cuenta en LSD y LSD_API_KEY que contiene la clave API que obtuvo de la página de perfil.

LSD_USER=<your_email_here>
LSD_API_KEY=<api_key_from_your_profile_page>

  1. Dale LSD a Claude

$ uv run mcp install app.py

Nota: cada vez que ejecuta mcp install , si necesita actualizar claude_desktop_config.json por primera vez , deberá recordar actualizar la ruta a uv cada vez que instale el servidor MCP.

  1. Reinicia la aplicación de escritorio de Claude y ahora Claude debería poder hacer cosas alucinantes con LSD.

Claude con LSD

Si es la primera vez en una sesión de chat en la que te gustaría que Claude use LSD, debido a que no somos lo suficientemente populares como para quedar atrapados en los rastreos de Anthropic, primero deberás aprovechar nuestro mensaje personalizado que se incluye en nuestra documentación como parte de la asistencia.

Uso de un mensaje personalizado

Consulta la función write_lsd_sql si te interesa saber cómo funciona, pero se reduce a una regla conveniente que agregamos a nuestra palabra clave SCAN que permite que un desarrollador o LLM recupere la documentación de nuestro lenguaje en formato Markdown ( si deseas ejecutarlo tú mismo ).

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

No se pudo iniciar el servidor MCP

Uso de un mensaje personalizado

Si encuentra mensajes de error al iniciar el escritorio de Claude similares al siguiente mensaje:

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

Primera vez que se ejecuta un servidor MCP

Si es la primera vez que utiliza un servidor MCP en su computadora, para solucionar el error que se muestra arriba, siga las instrucciones del paso Agregar el servidor MCP del sistema de archivos para crear un archivo claude_desktop_config.json al que Claude Desktop pueda hacer referencia.

Falta el ejecutable

Además, si nunca ha hecho nada relacionado con Postgres en su computadora, es posible que aparezca un mensaje de error que contenga algo como lo siguiente:

Error: pg_config executable not found.

Para solucionarlo, simplemente instala postgres en tu equipo usando un gestor de paquetes disponible. Si usas una Mac, puedes hacerlo usando brew .

$ brew install postgres

Ruta incompleta

De lo contrario, y tal vez además del problema mostrado anteriormente, en la ubicación donde se almacena claude_desktop_config.json (es ~/Library/Application Support/Claude/claude_desktop_config.json si está ejecutando en una Mac), modifique el valor de la clave command en mcpServers -> LSD para que contenga la ruta completa para ejecutar uv (ejecute which uv en su terminal si aún no sabe qué es).

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

Una vez hecho esto, reinicie el escritorio de Claude y el problema debería estar resuelto. De lo contrario, informe el problema .

¿Qué es MCP?

MCP, abreviatura de protocolo de contexto de modelo , proporciona una capa de comunicación entre Claude e interfaces accesibles por computadora, como el sistema de archivos o las API web . Si bien un factor limitante de los LLM era su desconexión con el mundo real, al ser solo un modelo generador de texto, MCP permite a usuarios y desarrolladores dar vida a Claude.

¿Qué es el LSD?

LSD SQL, un DSL para la web, permite a los desarrolladores conectar internet a sus aplicaciones como si fuera una base de datos compatible con Postgres . En lugar de presentar una nueva ontología de web semántica o crear una nueva internet , proporciona un lenguaje declarativo dinámico que se basa en el existente.

Diseñado para navegadores en lugar de una arquitectura , LSD permite una potente paralelización a la vez que conserva la simplicidad con tablas justo a tiempo, lo que significa que puedes obtener datos sin ejecutar CREATE TABLE previamente. ¡Regístrate gratis con una cuenta de Google para empezar a consultar en internet!

Aquí hay un ejemplo de algo que puedes hacer con LSD, toma aproximadamente 30 segundos si se ejecuta por primera vez.

Contacto

Comuníquese con pranav@lsd.com si tiene alguna pregunta.

Herrería

insignia de herrería

Instalación mediante herrería

Para instalar LSD MCP Server para Claude Desktop automáticamente a través de 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.

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