Connects to GitHub repositories to clone, read, and write content, enabling document management and knowledge base generation across both public and private repositories
Provides management of local git repositories, enabling document processing and knowledge base generation from locally stored content
Utilizes OpenAI models for document classification, organization, summarization, and knowledge base generation through the OpenAI API
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lspace MCP Server search my knowledge base for recent AI discussions about TypeScript generics"
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.
"Books bend space and time... You stray into Lspace at your peril." - Terry Pratchett (Guards! Guards!)
Lspace eliminates context-switching friction by letting you capture insights from any AI session and instantly make them available across all your tools - turning scattered conversations into persistent, searchable knowledge.
Lspace is an open-source API backend and server that implements the Model Context Protocol (MCP). It enables developers to integrate intelligent knowledge base generation and management capabilities into their workflows, connecting AI agents and other tools to managed content repositories. (See modelcontextprotocol.io for more on MCP).
For comprehensive technical documentation, project details, and an example of a knowledge base built with Lspace, please see the official Lspace documentation repository.
This guide helps you set up the Lspace server and configure it for use with Model Context Protocol (MCP) clients like Cursor or Claude Desktop.
A. Prerequisites:
Node.js: LTS version recommended (includes npm). Download from nodejs.org.
npm: Comes with Node.js.
Git: Download from git-scm.com.
B. Clone, Install & Build Lspace Server: These steps prepare the Lspace server code to be executed by an MCP client.
Clone the Lspace server repository:
git clone https://github.com/Lspace-io/lspace-server.gitNavigate into the directory:
cd lspace-serverInstall dependencies:
npm installBuild the project (compiles TypeScript to JavaScript in the dist/ folder):
npm run buildThe main script for the MCP server will be lspace-mcp-server.js in the root of this directory after the build.
C. Configure Your Lspace Server: Before an MCP client can use Lspace, you need to configure Lspace itself:
Environment Variables (.env file):
Copy the example environment file:
cp .env.example .envEdit the new .env file.
Crucially, set your OPENAI_API_KEY.
Review and adjust other variables as needed (see comments in .env.example).
Lspace Repositories & Credentials (config.local.json file):
This file tells Lspace which repositories to manage and provides credentials (like GitHub PATs). It is not committed to Git.
Copy the example configuration file:
cp config.example.json config.local.jsonEdit config.local.json:
Add your GitHub PATs under credentials.github_pats. If you need detailed instructions on creating PATs, please see the Understanding GitHub Personal Access Tokens (PATs) for Lspace section below.
Define the local or GitHub repositories Lspace should manage under the repositories array.
Refer to the "Managing Repositories Manually (config.local.json)" section for detailed structure and examples.
D. Configuring Lspace in MCP Clients:
The lspace-mcp-server.js script (in your lspace-server directory) is what MCP clients will execute. You need to tell your MCP client how to find and run this script.
Important: In the client configurations below, replace /actual/absolute/path/to/your/lspace-server/ with the real absolute file path to the directory where you cloned and built the lspace-server.
Cursor: Cursor can be configured via a JSON file. You can set this up per-project or globally:
Project Configuration: Create a file at .cursor/mcp.json in your project's root directory.
Global Configuration: Create a file at ~/.cursor/mcp.json in your user home directory.
Example mcp.json for Cursor:
{
"mcpServers": {
"lspace-knowledge-base": { // You can choose any name here
"command": "node",
"args": ["/actual/absolute/path/to/your/lspace-server/lspace-mcp-server.js"],
"env": {
// .env file in lspace-server directory should be picked up automatically.
// Only add environment variables here if you need to override them
// specifically for Cursor, or if the .env file is not found.
// "OPENAI_API_KEY": "your_openai_key_if_not_in_lspace_env"
}
}
}
}Remember to replace the placeholder path in args.
Restart Cursor after creating or modifying this configuration.
Claude Desktop: Claude Desktop uses a central JSON configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\\Claude\\claude_desktop_config.json
If this file doesn't exist, Claude Desktop might create it when you go to Settings > Developer > Edit Config.
Example claude_desktop_config.json content:
{
"mcpServers": {
"lspace": { // You can choose any name here
"command": "node",
"args": ["/actual/absolute/path/to/your/lspace-server/lspace-mcp-server.js"]
// "env": { ... } // Similar environment variable considerations as with Cursor
}
}
}Ensure you replace the placeholder path in args.
Restart Claude Desktop after saving changes to this file.
After configuring your MCP client, it should be able to start and communicate with your Lspace server, allowing you to use Lspace tools and access your configured knowledge bases from within the client.
Related MCP server: MCP Memory Server
Lspace requires GitHub Personal Access Tokens (PATs) to interact with your GitHub repositories on your behalf. This includes operations like cloning repositories, reading content, and importantly, writing new content (e.g., generated knowledge base articles, processed raw inputs) by committing and pushing changes.
Why PATs? PATs are a secure way to grant Lspace access to your GitHub account without needing your password. You can control the permissions (scopes) granted to each PAT and revoke them at any time.
Creating a GitHub PAT for Lspace:
Go to your GitHub Developer settings.
Click on "Personal access tokens" and then "Tokens (classic)". For finer-grained control, you might explore "Fine-grained tokens", but "Tokens (classic)" are generally simpler for this type of application.
Click "Generate new token" (and then "Generate new token (classic)").
Give your token a descriptive name, like "lspace-server-access".
Set an expiration period for the token.
Select Scopes: For Lspace to fully manage your repositories, including reading, writing, committing, and pushing, you must select the repo scope. This scope grants full control of public and private repositories.
(Illustrative image link, actual UI may vary)
Click "Generate token".
Important: Copy the generated token immediately. You will not be able to see it again. Store it securely.
Using PATs in Lspace (config.local.json):
In your config.local.json file, you'll define an alias for your PAT under the credentials.github_pats section and then reference this pat_alias in your GitHub repository configurations. See the "Managing Repositories Manually (config.local.json)" section for more details.
Example credentials block in config.local.json:
{
"credentials": {
"github_pats": [
{
"alias": "my_lspace_pat",
"token": "ghp_YOUR_COPIED_GITHUB_TOKEN_HERE"
}
// You can add more PATs with different aliases if needed
]
},
// ... rest of your repositories configuration ...
}Self-hostable service for git operations, search, and LLM integration.
Lspace MCP Server: Implements the Model Context Protocol (MCP) via lspace-mcp-server.js, allowing AI agents and other tools to interact with Lspace capabilities programmatically. (See modelcontextprotocol.io for more on MCP).
Multi-repository management with support for multiple git providers (local, GitHub).
AI Orchestration for automated document classification, organization, and summarization.
Knowledge Base Generation for creating a Wikipedia-like synthesis of repository content.
Dual-structure repositories with raw documents and a synthesized knowledge base.
Timeline tracking for document operations.
Extensible architecture for custom integrations.
Lspace utilizes a dual-structure repository architecture:
Raw Document Storage (/.lspace/raw_inputs/):
Original documents uploaded by users or ingested via the MCP server/API.
AI-assisted categorization and organization.
Metadata enhancement and structured formatting.
Operations tracked in /.lspace/timeline.json.
Knowledge Base Synthesis (Repository Root):
AI-generated, Wikipedia-like structure from raw documents.
An entry page (typically README.md in the repository root) provides an overview.
Topic pages synthesizing information across multiple documents.
Cross-references and links back to source documents.
Beyond the Quick Start, here are more details on configuration:
config.local.json)This file is critical for defining repository connections (local paths, GitHub repo details) and credentials (like GitHub PATs).
See the "Managing Repositories Manually (config.local.json)" section for its structure.
Prompts guiding the LLM for document processing and knowledge base generation are centralized in src/config/prompts.ts. Modify these to customize AI behavior.
If you need the RESTful API endpoints (e.g., for web application integration or direct HTTP calls) in addition to or instead of the MCP server:
Ensure your .env and config.local.json are set up as described above.
Build the project: npm run build
Run the development server:
npm run devOr, for a production deployment:
npm startThese scripts typically start the full application defined in src/index.ts, which may include both REST API and MCP functionalities. The lspace-mcp-server.js script is a dedicated entry point optimized for MCP-only interactions.
config.local.json)You can manage the repositories Lspace connects to by directly editing your local config.local.json file. This file is not committed to version control (it's in .gitignore). An example template, config.example.json, is provided in the repository.
Always make your changes in config.local.json.
The basic structure of the file includes a list of credentials (for services like GitHub) and a list of repositories.
{
"credentials": {
"github_pats": [
{
"alias": "your_github_pat_alias",
"token": "ghp_yourgithubpersonalaccesstoken"
}
]
},
"repositories": [
{
"name": "My Local Project",
"type": "local",
"path": "/path/to/your/local/git/repository",
"path_to_kb": ".",
"id": "your_unique_id_for_this_repo"
},
{
"name": "My Awesome GitHub Project",
"type": "github",
"owner": "your-github-username-or-org",
"repo": "your-repository-name",
"branch": "main",
"pat_alias": "your_github_pat_alias",
"path_to_kb": ".",
"id": "another_unique_id"
}
]
}Ensure the repository is a valid Git repository.
Add a new object to the repositories array in config.local.json (see example above).
name: A human-readable name.
type: Must be "local".
path: The absolute path to your local Git repository.
path_to_kb (Optional): Relative path to the knowledge base root within the repo (e.g., docs/kb). Defaults to . (repository root).
id (Optional): A unique UUID. If omitted, one will be generated.
Ensure you have a GitHub Personal Access Token (PAT) with repo scope.
Add your PAT to the credentials.github_pats section (see example above).
Add a new object to the repositories array (see example above).
name, type ("github"), owner, repo, branch, pat_alias, path_to_kb, id as described.
After editing config.local.json, restart the Lspace MCP server or API server for changes to take effect. Lspace will then attempt to clone new GitHub repositories into the directory specified by REPO_BASE_PATH (or its default cloned-github-repos) and make all configured repositories available.
This project is licensed under the Business Source License 1.1 (BSL 1.1).
This generally means:
You can freely use, modify, and self-host the software for personal projects, research, and internal non-commercial use.
Commercial use (e.g., offering a paid service using this software) is restricted and requires a separate commercial license from Robin Spottiswoode, or use of an official Lspace Cloud hosted service (if available).
After one (1) year from the public release date of each version, that version of the software will automatically convert to the Apache License 2.0, a permissive open-source license.
For the full license text, please see the LICENSE file in the repository.
🚀 CREATE: Add content for automatic knowledge base generation. This is the PRIMARY tool for adding ANY content to lspace. Example: repositoryId='b3fcb584-5fd9-4098-83b8-8c5d773d86eb', inputType='text_snippet', content='My documentation text', title='New Guide'
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | The actual content text (for text_snippet) or file content (for file_upload). For files, use base64 encoding for binary data. | |
| fileName | No | File name (REQUIRED for file_upload type). Example: 'my-document.md' | |
| inputType | Yes | Content type: 'text_snippet' for text, 'file_upload' for files, 'web_url' to fetch from URL. | |
| metadata | No | Optional metadata like tags, categories, etc. | |
| repositoryId | Yes | The ID of the Lspace repository. Use 'lspace_list_repositories' first to get repository IDs. | |
| title | No | Optional title for the content. Example: 'Installation Guide', 'Meeting Notes' | |
| url | No | The URL to fetch content from (REQUIRED for web_url type). Example: 'https://example.com/doc' | |
| user | No | Optional user identifier. Example: 'john.doe' |
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 indicates this is a creation/mutation tool ('CREATE: Add content'), which implies it modifies data. However, it lacks details on permissions, error handling, rate limits, or what happens after content is added (e.g., processing time, confirmation). The example helps but doesn't cover behavioral traits comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with an emoji for visual emphasis, a clear purpose statement, and a practical example—all in two sentences. Every element serves a purpose: the first sentence defines the tool's role, and the second provides actionable context. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, mutation operation) and lack of annotations or output schema, the description is moderately complete. It covers the primary use case and provides an example, but for a tool that likely triggers backend processing (e.g., 'automatic knowledge base generation'), it should mention expected outcomes, processing behavior, or error scenarios to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal value beyond the schema by providing a concrete example with parameter values (e.g., repositoryId='b3fcb584-5fd9-4098-83b8-8c5d773d86eb'), but doesn't explain parameter interactions or semantics not already in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Add content') and resource ('for automatic knowledge base generation'), explicitly identifying it as the PRIMARY tool for adding ANY content to lspace. It distinguishes itself from siblings by emphasizing its role as the main content addition mechanism, unlike browsing, searching, or listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: it's the PRIMARY tool for adding ANY content to lspace, with a clear example. It implicitly distinguishes from siblings by focusing on content creation rather than retrieval (e.g., lspace_search_knowledge_base) or management (e.g., lspace_list_repositories).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
📖 BROWSE: Read existing knowledge base files/directories (read-only). Automatically syncs with remote before browsing to ensure latest content. Example: To list files in 'Lspace Official Docs' root, use repositoryId='b3fcb584-5fd9-4098-83b8-8c5d773d86eb', operation='list_directory', path='.'
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation type: 'list_directory' to see files/folders, 'read_file' to read file contents. Use 'lspace_add_content' for content creation. | |
| path | Yes | Path relative to repository root. Use '.' for root directory, 'folder/file.txt' for specific files. | |
| repositoryId | Yes | The ID of the Lspace repository. Use 'lspace_list_repositories' first to get repository IDs. |
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 effectively describes key behaviors: read-only operation, automatic syncing before browsing, and the tool's purpose for reading files/directories. However, it doesn't mention potential limitations like rate limits, error handling, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key behavioral details and a concrete example. Every sentence adds value: the first states the purpose and read-only nature, the second explains automatic syncing, and the third provides a practical usage example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage guidelines, and key behavior. However, without an output schema, it doesn't describe return values (e.g., what 'list_directory' or 'read_file' returns), leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema, providing only an example that illustrates parameter usage without adding new semantic information. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Read existing knowledge base files/directories') and resource ('knowledge base'), distinguishing it from siblings like 'lspace_add_content' (creation) and 'lspace_search_knowledge_base' (searching). The emoji and 'BROWSE' reinforce the read-only browsing function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('read-only' browsing) and when not to ('Use lspace_add_content for content creation'), providing clear alternatives. It also mentions prerequisites ('Automatically syncs with remote before browsing') and references sibling tools ('lspace_list_repositories' to get repository IDs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ℹ️ SETUP: Get detailed configuration for a specific repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryName | Yes | The unique name of the repository. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get'), which implies it's likely safe and non-destructive, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'detailed configuration' entails in terms of output format. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It uses an emoji for visual clarity and is front-loaded with the key action and resource. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral aspects like what 'detailed configuration' includes or usage context. Without annotations or output schema, the description should do more to compensate, but it meets a minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'repositoryName' clearly documented as 'The unique name of the repository.' The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed configuration') and target resource ('for a specific repository'), making the purpose understandable. It distinguishes from siblings like 'lspace_list_repositories' by focusing on a single repository's details rather than listing all repositories. However, it doesn't explicitly mention what 'detailed configuration' includes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'SETUP' implying this might be used for initial configuration checks, but it doesn't specify when to use this tool versus alternatives like 'lspace_list_repositories' for overviews or other tools for content management. No explicit when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
📜 HISTORY: List all changes made to the knowledge base in human-friendly format. Shows both file uploads and knowledge base generations separately. Example: repositoryId='b3fcb584-5fd9-4098-83b8-8c5d773d86eb'
| Name | Required | Description | Default |
|---|---|---|---|
| changeType | No | Filter by type of change: 'file_upload', 'knowledge_base_generation', or 'both' | |
| limit | No | Maximum number of changes to return (default: 20) | |
| repositoryId | Yes | The ID of the Lspace repository. Use 'lspace_list_repositories' first to get repository IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool lists changes in a 'human-friendly format' and separates file uploads from knowledge base generations, which adds behavioral context. However, it lacks details on permissions, rate limits, or response format, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, uses an emoji for visual clarity, and includes a concise example. Every sentence earns its place without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers the tool's purpose and basic behavior but lacks details on output format, error handling, or integration with sibling tools, which could help an agent use it more effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by mentioning repositoryId in an example, but does not provide additional meaning or usage context beyond what the schema already specifies for parameters like changeType or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('List all changes') and resource ('knowledge base'), and distinguishes it from siblings by specifying it shows history in 'human-friendly format' with both file uploads and knowledge base generations separately, unlike other tools like lspace_list_repositories or lspace_search_knowledge_base.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to see history of changes) and includes an example with repositoryId, but does not explicitly state when not to use it or name alternatives among siblings, such as lspace_browse_knowledge_base for current content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
📋 SETUP: List all repositories currently managed by Lspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While it indicates this is a listing operation, it doesn't describe important behavioral traits such as whether the list is paginated, sorted, or filtered; what format the output takes; or any rate limits or authentication requirements. The description is too minimal for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with an emoji prefix for visual clarity. It's front-loaded with the key action and resource, with no wasted words. Every element (the emoji, 'SETUP' context, and core description) serves a purpose in communicating the tool's function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective use. It doesn't explain what the output looks like (e.g., a list of repository names, IDs, or metadata), any limitations (e.g., only active repositories), or behavioral aspects like error handling. For a tool with zero structured metadata, the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. It could potentially mention that no filtering or options are available, but this isn't strictly necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all repositories') and resource ('repositories currently managed by Lspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'lspace_get_repository_info', which might provide more detailed information about individual repositories rather than a comprehensive list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with '📋 SETUP:' and 'currently managed by Lspace', suggesting this is for inventory or setup purposes. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'lspace_browse_knowledge_base' or 'lspace_search_knowledge_base', leaving some ambiguity about the best use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🔍 SEARCH: Query the knowledge base using natural language. Automatically syncs with remote before searching to ensure latest content. Example: repositoryId='b3fcb584-5fd9-4098-83b8-8c5d773d86eb', queryText='What are the testing procedures?'
| Name | Required | Description | Default |
|---|---|---|---|
| queryText | Yes | Natural language query about the knowledge base content. Examples: 'What are the main topics?', 'How do I configure X?', 'Tell me about testing procedures' | |
| repositoryId | Yes | The ID of the Lspace repository to query. Use 'lspace_list_repositories' first to get repository IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses automatic syncing with remote content before searching (ensuring freshness) and provides an example of parameter usage. However, it doesn't mention rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear emoji icon, capitalized action word, and a single explanatory sentence followed by a concrete example. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters, 100% schema coverage, and no output schema, the description is adequate but could be more complete. It explains the core behavior and provides an example, but doesn't describe return format, pagination, or error cases, which would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by showing an example parameter combination, but doesn't explain semantics or constraints not already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query the knowledge base using natural language' with a specific verb ('search') and resource ('knowledge base'). It distinguishes from siblings like 'lspace_browse_knowledge_base' by emphasizing natural language querying, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning automatic syncing with remote content and provides an example, but lacks explicit guidance on when to use this tool versus alternatives like 'lspace_browse_knowledge_base' or 'lspace_list_knowledge_base_history'. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🔄 UNDO: Revert knowledge base changes using human-friendly commands. Can undo file uploads, KB generations, or both. Examples: 'undo changes for test.txt', 'undo last 3 changes', 'remove test.txt completely'
| Name | Required | Description | Default |
|---|---|---|---|
| changeId | No | Specific change ID from 'lspace_list_knowledge_base_history' | |
| filename | No | Target a specific file. Example: 'test.txt', 'meeting-notes.md' | |
| lastNChanges | No | Undo the last N changes. Example: 1 for last change, 3 for last 3 changes | |
| regenerateAfterRevert | No | For knowledge_base_generation reverts, trigger automatic regeneration (default: false) | |
| repositoryId | Yes | The ID of the Lspace repository. Use 'lspace_list_repositories' first to get repository IDs. | |
| revertType | No | What to revert: 'file_upload' (remove file), 'knowledge_base_generation' (keep file, regenerate KB), 'both' (remove everything) |
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 the tool can 'revert knowledge base changes' and lists types of changes (file uploads, KB generations, or both), which implies mutation behavior. However, it lacks details on permissions, reversibility, side effects, or response format, leaving gaps in transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose and followed by concise examples. Every sentence earns its place by reinforcing usage without redundancy, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, mutation operation) and lack of annotations or output schema, the description is moderately complete. It covers the tool's purpose and usage examples but does not fully address behavioral aspects like error handling or return values, leaving room for improvement in contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by hinting at human-friendly commands in examples, but does not provide additional syntax or format details for parameters. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('revert') and resource ('knowledge base changes'), and distinguishes it from siblings by focusing on undo functionality. It specifies what types of changes can be undone (file uploads, KB generations, or both), which differentiates it from tools like 'lspace_list_knowledge_base_history' (which only lists changes) or 'lspace_add_content' (which adds content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by listing examples of undo commands (e.g., 'undo changes for test.txt', 'undo last 3 changes'), implying it's for reverting changes in a knowledge base. However, it does not explicitly state when not to use it or mention alternatives (e.g., using other tools for non-undo operations), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0lspace_add_contentlspace_browse_knowledge_baselspace_get_repository_infolspace_list_knowledge_base_historylspace_list_repositorieslspace_search_knowledge_baselspace_undo_knowledge_base_changesEach tool has a distinct purpose with clear boundaries: add_content for creation, browse for reading files, get_repository_info for configuration, list_history for change tracking, list_repositories for setup, search for querying, and undo for reverting changes. No overlap exists between these functions, making tool selection straightforward.
All tools follow a consistent 'lspace_verb_noun' pattern with snake_case throughout (e.g., lspace_add_content, lspace_browse_knowledge_base). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
With 7 tools, the server is well-scoped for managing a knowledge base system. This count covers core operations like CRUD (add, browse, undo), setup (list repositories, get info), and advanced features (search, history) without being overwhelming or insufficient for the domain.
The tool set provides comprehensive coverage for knowledge base management, including creation, reading, searching, history tracking, and undo functionality. A minor gap exists in direct update or delete operations for specific content, but agents can work around this using undo or re-adding content.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Your versioned memory across every AI tool — context maps, personal memory, and tasks over MCP.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
An MCP memory server. One memory your agents share — across models, devices and apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lspace-io/lspace-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
