What can you do with this server?

This server provides an authoritative LSL (Linden Scripting Language) reference for AI coding assistants, helping prevent hallucinated functions, wrong signatures, and unsupported syntax. It offers the following tools: * lookup_function(name) — Look up a specific LSL function by name to get its full record: signature, parameters, return type, delay, energy cost, caveats, examples, related functions, and known AI pitfalls. Includes fuzzy matching and did_you_mean suggestions when no exact match is found. * search_functions(query, limit?) — Full-text search across LSL function names and descriptions using natural language or keywords. Returns a ranked summary list. * get_pitfalls(category?, ai_source?) — Retrieve a curated database of known LSL mistakes made by AI coding assistants, filterable by category (e.g. nonexistent_functions, unsupported_syntax) or by AI tool source. * check_code(code) — Scan raw LSL source code for known AI-generated mistakes, including hallucinated function names, unsupported syntax (ternary operators, switch statements), and reserved words used as variable names. Returns line numbers and fix suggestions. * list_events(name?) — List all valid LSL event signatures, or look up a specific event by name to verify it exists and get its parameter details. * get_constants(category?, name?) — Browse or look up LSL constants by category (e.g. permissions, prim_params) or by exact name (e.g. NULL_KEY, PERMISSION_TAKE_CONTROLS).

How do I use lsl-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lsl-mcp check this LSL script for common pitfalls" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

lsl-mcp

by Treeeeeeeeeeeeee

Overview Schema Related Servers Score Discussions

Python

Local

lsl-mcp

A Model Context Protocol (MCP) server providing accurate LSL (Linden Scripting Language) reference data to AI coding assistants. Grounded in the official Second Life wiki, with a curated database of AI-specific pitfalls.

Motivation

AI coding assistants (Claude Code, Kiro, etc.) frequently produce incorrect LSL — hallucinated function names, unsupported syntax, and wrong signatures. This server gives those tools a live, authoritative reference to query against rather than relying on training data.

Related MCP server: PAELLADOC

Design Goals

Portable LSL only — no Firestorm-specific syntax
AI-aware — pitfalls are categorised and tagged by which tool produced them
Git-tracked — JSON is the source of truth; SQLite is always derivable
Incrementally maintainable — new pitfalls are captured via CLI as they are discovered

Project Structure

lsl-mcp/
├── server.py              # MCP server entrypoint
├── db/
│   ├── schema.sql         # Table definitions
│   └── lsl.db             # SQLite database (gitignored)
├── data/
│   ├── functions/         # One JSON file per LSL function (source of truth)
│   ├── pitfalls.json      # Language pitfalls collection (source of truth)
│   └── constants.json     # LSL constants
├── scripts/
│   ├── scrape_wiki.py     # Populates data/functions/ from the LSL wiki
│   ├── load_db.py         # Imports JSON data into lsl.db
│   └── add_pitfall.py     # CLI tool for adding new pitfalls
├── tools/
│   ├── lookup.py          # lsl_lookup_function, lsl_search
│   ├── pitfalls.py        # lsl_get_pitfalls, lsl_check_code
│   └── reference.py       # lsl_list_events, lsl_constants
└── pyproject.toml

Requirements

Python 3.11+
uv (recommended) or pip

Initial Setup

1. Install dependencies

Using uv (recommended):

uv sync

Using pip:

pip install -e .

For development (includes pytest):

uv sync --dev
# or
pip install -e ".[dev]"

2. Scrape the LSL wiki

Populates data/functions/ with one JSON file per function. Approximately 700 functions; takes several minutes due to polite request throttling.

python scripts/scrape_wiki.py

Test a single function first:

python scripts/scrape_wiki.py --function llListen --dry-run

2. Initialise the database

Creates db/lsl.db from db/schema.sql and loads all JSON data.

python scripts/load_db.py

3. Connect to Claude Code

# using uv (recommended)
claude mcp add --transport stdio lsl -- uv run /path/to/lsl-mcp/server.py

# using python directly
claude mcp add --transport stdio lsl -- python /path/to/lsl-mcp/server.py

Or add a .mcp.json to your project root for project-wide sharing:

{
  "mcpServers": {
    "lsl": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "/path/to/lsl-mcp/server.py"]
    }
  }
}

Verify the server is connected:

claude mcp list

MCP Tools

Tool	Description
`lookup_function(name)`	Exact or fuzzy match on function name. Returns full record including signature, parameters, caveats, and known AI pitfalls. Falls back to `did_you_mean` on miss.
`search_functions(query, limit?)`	Full-text search across function names and descriptions. Returns ranked summary list.
`get_pitfalls(category?, ai_source?)`	Returns all pitfall entries, optionally filtered by category or source tool.
`check_code(code)`	Scans raw LSL source for known AI-generated mistakes. Returns line numbers and suggestions.
`list_events(name?)`	Returns all valid LSL event signatures, or looks up one by name.
`get_constants(category?, name?)`	Returns constants by category or direct name lookup.

Recommended AI workflow

Before starting an LSL task:
    get_pitfalls()               ← full briefing on known mistakes

While writing LSL:
    lookup_function("llFoo")     ← verify signature before use
    list_events("touch_start")   ← verify event name and parameters
    get_constants("permissions")  ← browse constants by category

Before presenting code to the user:
    check_code(generated_lsl)    ← catch mistakes before they reach the user

Pitfall Categories

Category	Description
`reserved_words`	LSL type names or keywords used as variable identifiers
`nonexistent_functions`	Hallucinated function names with no LSL equivalent
`unsupported_syntax`	Syntax valid in other languages but a compile error in LSL
`scoping`	Permission/access scope issues that silently block operations
`type_coercion`	Implicit casting that LSL does not perform
`state_behavior`	Unexpected behavior around state changes
`performance`	Functions with hidden sleeps or inefficient patterns

Adding a Pitfall

When an AI tool produces incorrect LSL, capture it:

python scripts/add_pitfall.py \
  --category nonexistent_functions \
  --title "llStringReplace does not exist in LSL" \
  --bad "llStringReplace(src, old, new)" \
  --good "llReplaceSubString(src, pattern, replacement, count)" \
  --ai-source kiro \
  --notes "llStringReplace is a plausible-sounding hallucination, likely confused with string replace conventions in other languages."

Then sync the database and commit:

python scripts/load_db.py --only pitfalls
git add data/pitfalls.json
git commit -m "pitfall(func_001): llStringReplace does not exist [kiro]"

Claude-assisted capture

Describe the mistake to Claude in plain language. Claude will format it into the correct schema and emit the exact CLI command to run. You verify, run it, and commit. Claude never writes to the database directly — the CLI is the deterministic protocol.

`--dry-run`

Preview what would be written without touching any files:

python scripts/add_pitfall.py --category unsupported_syntax --title "..." --dry-run

Refreshing Wiki Data

Re-scrape all functions and reload:

python scripts/scrape_wiki.py --overwrite
python scripts/load_db.py --only functions

Re-scrape a single function:

python scripts/scrape_wiki.py --function llReplaceSubString
python scripts/load_db.py --only functions

Database

db/lsl.db is gitignored — it is always fully derivable from the JSON sources via load_db.py. Only data/ and db/schema.sql are version-controlled.

To rebuild from scratch:

python scripts/load_db.py --reset

Pitfall ID Format

IDs are assigned automatically by add_pitfall.py based on category:

Category	Prefix	Example
`reserved_words`	`lang`	`lang_001`
`nonexistent_functions`	`func`	`func_001`
`unsupported_syntax`	`syn`	`syn_001`
`scoping`	`scope`	`scope_001`
`type_coercion`	`type`	`type_001`
`state_behavior`	`state`	`state_001`
`performance`	`perf`	`perf_001`

Known Pitfalls

ID	Category	Issue	Source
`type_001`	`type_coercion`	Boolean NOT `!` does not work on strings	claude-code
`state_001`	`state_behavior`	Cached owner key not updated after ownership transfer	claude-code
`lang_001`	`reserved_words`	`key` used as variable name	kiro
`func_001`	`nonexistent_functions`	`llStringReplace` does not exist	kiro
`syn_001`	`unsupported_syntax`	Ternary operator not supported	both
`syn_002`	`unsupported_syntax`	Switch statements not supported	both
`scope_001`	`scoping`	Transfer-only permissions silently prevent script edits	kiro
`perf_001`	`state_behavior`	`llSetPrimitiveParams` has forced 0.2s sleep; use `llSetLinkPrimitiveParamsFast`	both

Testing

# Run all tests
python3 -m pytest

# Verbose output
python3 -m pytest -v

# Single module
python3 -m pytest tests/test_pitfalls.py

Tests use an in-memory SQLite fixture database built from db/schema.sql — no real lsl.db or network access required. The conftest.py fixture patches DB_PATH in all tool modules automatically.

Test file	Coverage
`test_lookup.py`	`lsl_lookup_function`, `lsl_search`
`test_pitfalls.py`	`lsl_get_pitfalls`, `lsl_check_code`
`test_reference.py`	`lsl_list_events`, `lsl_constants`
`test_add_pitfall.py`	ID generation logic in `add_pitfall.py`

gitignore

db/lsl.db
data/functions/
data/scrape_errors.json
__pycache__/
*.pyc
.venv/

data/functions/ is gitignored because it is fully regenerable from the wiki. Only data/pitfalls.json and data/constants.json are committed — these contain hand-curated data that cannot be scraped.

Available Tools

6 tools

check_codeA

Scan an LSL code snippet for known AI-generated pitfalls.

Checks for nonexistent function calls, unsupported syntax (ternary operators, switch statements), reserved words used as variable names, and other patterns from the pitfalls database.

Call this on any LSL you generate before presenting it to the user. Returns line numbers and suggestions for each issue found.

Args: code: Raw LSL source code as a string.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explains what the tool checks (pitfalls) and that it returns line numbers and suggestions. However, it does not disclose if the tool is read-only or if it has side effects, but for a scanning tool this is acceptable. The description adds value beyond the input schema.

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 concise (approximately 8 lines) with no wasted words. It front-loads the purpose and usage guidance, then lists checks and parameter details in a clear, structured manner.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should detail the return structure. It mentions 'line numbers and suggestions' but does not specify the format (e.g., list of objects). While the tool is simple, this omission could confuse an AI agent when interpreting results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'code' has no description in the schema. The description adds 'Raw LSL source code as a string,' which clarifies the expected input. While it could specify constraints like max length, the current description is sufficient for correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'scan', the resource 'LSL code snippet', and the specific purpose of finding AI-generated pitfalls. It lists specific checks like nonexistent functions and unsupported syntax, which distinguishes it from sibling tools that are informational (e.g., lookup_function, get_constants).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use the tool: 'Call this on any LSL you generate before presenting it to the user.' This provides clear guidance without ambiguity, covering the primary use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_constantsA

Return LSL constants, optionally filtered by category or name.

Call with no arguments to see available categories and total count. Use category to browse a group (e.g. "permissions", "prim_params"). Use name for a direct lookup (e.g. "NULL_KEY", "PERMISSION_TAKE_CONTROLS").

Args: category: Optional category filter. See response for valid categories. name: Optional exact constant name. Takes precedence over category.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No
`name`	No

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description adequately explains behavior: default returns categories/count, category filters, name overrides category. It lacks mention of error handling for invalid inputs but covers core mechanics.

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 concise with a clear summary followed by usage scenarios and structured Arg section. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description covers all scenarios: no args, category, name, and precedence. It provides complete guidance for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description fully compensates by explaining both parameters: category as a filter, name as exact lookup with precedence over category. This adds essential meaning beyond the schema's bare types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns LSL constants with optional filtering by category or name. It distinctly separates from siblings like 'check_code' and 'get_pitfalls' by specifying the exact resource and operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit instructions are given: call with no arguments to see categories, use category for browsing, use name for direct lookup with precedence. This clarifies when to use each parameter and contrasts with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pitfallsA

Return known LSL pitfalls for AI coding assistants.

Call with no arguments for a full briefing before starting an LSL task. Filter by category or by which AI tool produced the mistake.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No
`ai_source`	No

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It describes the tool as returning pitfalls, implying a read-only operation. However, it doesn't disclose potential side effects, rate limits, or authentication needs. The description is adequate but not rich in behavioral details.

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 concise with a clear purpose statement, usage guidance, and parameter details. It is front-loaded with the main intent and contains no superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only two optional parameters and no output schema, the description provides sufficient context: purpose, usage, and parameter options. It doesn't describe the return format, but for a list of pitfalls, this is likely acceptable. Overall, it is complete enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description compensates by listing allowed values for category and ai_source in the Args section. It explains that category can be one of several enumerated values and ai_source can be 'kiro', 'claude-code', or 'both', adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns known LSL pitfalls for AI coding assistants. It specifies the verb 'Return' and the resource 'known LSL pitfalls'. It also differentiates from sibling tools like check_code and get_constants by focusing specifically on pitfalls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends calling with no arguments for a full briefing before starting an LSL task. It also explains how to filter by category or ai_source. While it doesn't explicitly state when not to use it, the usage advice is clear and contextual.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_eventsA

Return valid LSL event signatures.

Call with no arguments to get all events and verify an event name exists. Call with a name to get the full signature and parameter details.

Args: name: Optional event name, e.g. "listen" or "touch_start". Omit to return all events.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description adequately conveys a read-only query operation and explains the two distinct behaviors. No side effects or destructive actions are indicated, and the description provides sufficient behavioral context for an agent.

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 extremely concise, using three well-structured sentences and a clear arg specification. Every sentence adds value without redundancy, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no output schema and one optional parameter, the description covers all necessary aspects: purpose, two usage modes, and parameter behavior. It could be slightly more specific about the return format, but overall it is complete and actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing a natural language explanation, including an example ('listen', 'touch_start'), and explicitly states what happens when the parameter is omitted versus provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states tool returns LSL event signatures and explicitly differentiates between listing all events and retrieving details for a specific event. This sets it apart from siblings like lookup_function (for functions) and check_code (for code checking).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage instructions for both calling modes: with no argument to list all events, or with a name to get full signature details. Does not explicitly contrast with siblings, but the context from sibling names and the description makes the intended use obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_functionA

Look up an LSL function by name.

Returns the full function record: signature, parameters, return type, delay, energy cost, caveats, examples, related functions, and any known AI-specific pitfalls associated with this function.

Falls back to fuzzy matching if the exact name is not found, and returns a 'did_you_mean' list when no match exists at all — helping catch hallucinated function names.

Args: name: Function name, e.g. "llListen" or "llReplaceSubString".

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses fuzzy matching, 'did_you_mean' list, and full return record (signature, parameters, etc.), fully informing the agent of behavior without annotations.

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?

Concise with clear bullet-like listing of return fields; every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a single-parameter tool without output schema; covers return content, fallback, and examples adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Provides concrete examples like 'llListen' and 'llReplaceSubString,' adding value beyond the schema, though schema coverage is 0%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Look up an LSL function by name,' distinguishing it from sibling 'search_functions' by emphasizing exact lookup and fuzzy fallback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Indicates use for exact names with fallback and 'did_you_mean' for non-matches, but doesn't explicitly contrast with 'search_functions' or specify when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_functionsA

Full-text search across LSL function names and descriptions.

Use when you know roughly what a function does but not its exact name. Returns a ranked summary list — call lookup_function for the full record.

Args: query: Keywords or natural language, e.g. "listen channel message" or "set prim texture face". limit: Maximum results to return (default 10, max 25).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

TDQS

A4.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully bears the burden of behavioral disclosure. It mentions 'returns a ranked summary list' but does not describe the search algorithm, ranking criteria, pagination, error handling, or structure of the summary. For a tool with zero annotation coverage, this is insufficient.

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 appropriately sized: a one-line purpose statement, a two-line usage guideline, and two-line parameter descriptions (with examples). Every sentence is necessary and front-loaded with the most important info. No fluff or irrelevant details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and no annotations, the description lacks details about the return format (structure of summary list, fields included). It also doesn't mention rate limits, error cases, or behavior when no results found. However, the param descriptions are good and the usage guidance is clear. It is somewhat incomplete but functional.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 provides meaningful explanations: for 'query' it says 'Keywords or natural language, e.g. "listen channel message" or "set prim texture face".' for 'limit' it says 'Maximum results to return (default 10, max 25).' These add significant meaning beyond the schema's mere titles and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Full-text search across LSL function names and descriptions.' It uses specific verb (search) and resource (LSL function names/descriptions) and explicitly distinguishes from sibling 'lookup_function' by saying it returns a ranked summary list and to use lookup_function for the full record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use when you know roughly what a function does but not its exact name.' and 'returns a ranked summary list — call lookup_function for the full record.' This explicitly tells when to use and when not to use, with an alternative named.

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. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 16, 2026
- First observedcheck_code
- First observedget_constants
- First observedget_pitfalls
- First observedlist_events
- First observedlookup_function
- First observedsearch_functions

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct aspect of LSL development: code checking, constants, pitfalls database, events, function lookup by name, and full-text search. No two tools have overlapping purposes, and descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., check_code, lookup_function). The naming is predictable and easy to understand.

Tool Count5/5

With 6 tools, the server is well-scoped for assisting with LSL code. Each tool provides essential functionality without unnecessary bloat. The count feels appropriate for the domain.

Completeness5/5

The tool set covers the core needs for LSL development: checking for pitfalls, exploring constants, events, and functions. Missing features like syntax guidance are mitigated by detailed returns from lookup_function and search_functions.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
ChiR24-unreal_mcp_serverOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Developer Tools App Automation Software Architecture
2856
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
slimaOAuth
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21

Related MCP Servers

MCP Server Example
Developer Tools Code Execution Autonomous Agents
alejandro-ao
A
license
B
quality
D
maintenance
An educational implementation of a Model Context Protocol server that demonstrates how to build a functional MCP server for integrating with various LLM clients like Claude Desktop.
Updated a year ago (2025-04-29 10:58 UTC)
1
163
MIT
PAELLADOC
Developer Tools Documentation Access Autonomous Agents
jlcases
A
license
Not graded
quality
F
maintenance
A Model Context Protocol (MCP) server that implements AI-First Development framework principles, allowing LLMs to interact with context-first documentation tools and workflows for preserving knowledge and intent alongside code.
Updated 4 months ago (2026-05-19 16:14 UTC)
338
AGPL 3.0
RL-MCP
RAG Systems Agent Orchestration Databases
rlefko
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides AI models with structured access to external data and services, acting as a bridge between AI assistants and applications, databases, and APIs in a standardized, secure way.
Updated a year ago (2025-05-31 18:35 UTC)
2
-
Gravitas-Core-MCP
Coding Agents Autonomous Agents
ahmed-coding
A
license
B
quality
C
maintenance
Production-grade, autonomous Model Context Protocol (MCP) server that elevates AI models from stateless code generators into persistent, self-verifying software engineers.
Updated 7 months ago (2026-02-11 05:04 UTC)
21
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Treeeeeeeeeeeeee/second-life-mcp-server'

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