What can you do with this server?

The Waldur MCP server enables Claude Desktop to interact with a Waldur instance to manage data and users. You can: * Run read-only SQL queries * List customers, projects, resources, invoices, and offerings * Create invitations for users to join projects or organizations (customers) by email, with customizable roles and messages

How do I use Waldur MCP Server?

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., "@Waldur MCP Server list my current projects" 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.

en es ja ko zh

Waldur MCP Server

Official

by waldur

Overview Schema Related Servers Score Discussions

Python

Remote

Waldur MCP server

Waldur MCP server enables integration between Waldur instance and Claude Desktop by implementing the Model Context Protocol (MCP). This allows Claude to interact with your Waldur instance directly.

Quickstart

Install Claude Desktop for your platform from the Claude Desktop releases page
Install Python 3.13 or higher.
Install uv package manager.

Installation

To install the package:

pip install waldur-mcp-server

Or with uv:

uv pip install waldur-mcp-server

Generate Waldur Token

Log in to your Waldur instance
Navigate to Username > Credentials > API Token
Generate a new token with appropriate token lifetime - you'll need it for configuration

Claude Desktop MCP Server Configuration

On Windows: %APPDATA%\Claude\claude_desktop_config.json

On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "waldur-mcp-server": {
      "command": "uv",
      "args": [
        "--directory",
        "C:\\waldur_service",
        "run",
        "waldur-mcp-server"
      ],
      "env": {
        "WALDUR_API_URL": "https://your-waldur-instance",
        "WALDUR_TOKEN": "your-token"
      }
    }
  }
}

{
  "mcpServers": {
    "waldur-mcp-server": {
      "command": "uvx",
      "args": [
        "waldur-mcp-server"
      ],
      "env": {
        "WALDUR_API_URL": "https://your-waldur-instance",
        "WALDUR_TOKEN": "your-token"
      }
    }
  }
}

Debugging

On macOS, log files are located at ~/Library/Logs/Claude/mcp.log

If you encounter a spawn uvx ENOENT error, verify that your PATH environment variable includes the Python installation directory where uv is installed. Alternatively, you can specify the full path to uvx in the configuration file, for example: ~/Library/Frameworks/Python.framework/Versions/3.13/bin/uvx

Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector.

You can launch the MCP Inspector via npm with this command:

npx @modelcontextprotocol/inspector uv --directory C:\\waldur_service run waldur-mcp-server

When debugging, you'll need to set the required environment variables. Upon launching, the Inspector will display a URL that you can access in your browser to begin debugging.

Common issues

Invalid token: Verify token permissions and expiration
Connection issues: Check WALDUR_API_URL is accessible

Available Tools

7 tools

create_invitationB

Invite users to project or organization by email

Args: scope_type: Whether to invite users to organization or project scope_name: Name of the organization or project to invite users to role: Role to assign to invited users emails: List of email addresses to invite extra_invitation_text: Custom message to include in the invitation

ParametersJSON Schema

Name	Required	Description	Default
`scope_type`	Yes
`scope_name`	Yes
`role`	Yes
`emails`	Yes
`extra_invitation_text`	No

TDQS

B3.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 full burden for behavioral disclosure. While it implies a write operation ('Invite'), it doesn't address permissions needed, whether invitations are revocable, rate limits, or what happens if emails are invalid. The description provides minimal behavioral context beyond the basic action.

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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose, though the parameter explanations could be slightly more concise. The front-loaded purpose statement is effective.

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?

For a mutation tool with 5 parameters, no annotations, and no output schema, the description provides adequate functional coverage but lacks important contextual details about permissions, error conditions, and behavioral expectations. It explains what the tool does but not how it behaves in edge cases.

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?

With 0% schema description coverage, the description compensates well by explaining all 5 parameters in the Args section, clarifying what each represents (e.g., 'scope_type: Whether to invite users to organization or project'). It adds meaningful context beyond the bare schema, though it doesn't specify enum values for scope_type.

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 specific action ('Invite users') and target resources ('to project or organization by email'), distinguishing it from sibling tools that focus on listing or querying operations. It provides a verb+resource combination that is precise and unambiguous.

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, prerequisites, or exclusions. It lacks context about when invitations are appropriate or how this differs from other user management tools, offering only basic functional information.

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

list_customersC

List all customers

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/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. 'List all customers' implies a read-only operation but doesn't specify permissions, rate limits, pagination, or output format. For a tool with zero annotation coverage, this is a significant gap in transparency about how it behaves and what to expect.

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 with just three words, front-loading the core action and resource without any waste. Every word earns its place by directly stating the tool's purpose, making it efficient and well-structured for its simplicity.

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 lack of annotations and output schema, the description 'List all customers' is incomplete. It doesn't explain what 'all' entails (e.g., pagination, filters), the return format, or any behavioral constraints. For a tool with no structured data to rely on, this leaves critical gaps in understanding its operation and 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 input schema has 0 parameters with 100% description coverage, meaning no parameters need documentation. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for 0 parameters, as the schema fully covers the lack of inputs without requiring compensation from the description.

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 'List all customers' clearly states the verb ('List') and resource ('customers'), providing a basic understanding of the tool's function. However, it lacks specificity about scope or format and doesn't differentiate from sibling tools like 'list_invoices' or 'list_projects' beyond the resource name. This makes it vague rather than specific.

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. There is no mention of context, prerequisites, or exclusions, and it doesn't reference sibling tools like 'query' that might offer overlapping functionality. This leaves the agent with no usage direction beyond the basic purpose.

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

list_invoicesC

List all invoices

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/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. 'List all invoices' implies a read-only operation but doesn't specify whether it requires authentication, how results are returned (e.g., pagination, sorting), or any rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 'List all invoices' is extremely concise and front-loaded, consisting of a single, clear sentence with zero waste. It efficiently communicates the core action without unnecessary elaboration, making it easy for an agent to parse quickly.

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 lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what 'all invoices' entails (e.g., scope, format of returned data), behavioral traits like error handling, or how it fits with sibling tools. For a tool with minimal structured data, more context is needed.

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 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides, so it meets the baseline of 4 for tools with no parameters, as it doesn't mislead or omit necessary details.

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 'List all invoices' clearly states the verb ('list') and resource ('invoices'), making the basic purpose understandable. However, it lacks specificity about scope (e.g., time range, status filters) and doesn't differentiate from sibling tools like 'list_customers' or 'list_projects', which follow a similar pattern. It's adequate but vague.

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. There are no explicit instructions on context, prerequisites, or exclusions, and it doesn't mention sibling tools like 'query' that might offer overlapping functionality. This leaves the agent with minimal direction.

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

list_offeringsC

List all offerings

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/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. 'List all offerings' implies a read-only operation, but it does not specify any behavioral traits such as pagination, rate limits, authentication needs, or what 'all' entails (e.g., active only, all statuses). This is a significant gap 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description 'List all offerings' is extremely concise and front-loaded, consisting of a single, clear sentence with zero wasted words. It efficiently communicates the core action without unnecessary elaboration, making it easy for an agent to parse quickly.

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 simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It lacks context about what 'offerings' are, how results are returned (e.g., format, pagination), and any limitations or dependencies. For a list operation, this minimal information may lead to incorrect assumptions by the agent.

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 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, but since there are no parameters, this is acceptable. The baseline for 0 parameters is 4, as the description need not compensate for missing param info.

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 'List all offerings' clearly states the verb ('List') and resource ('offerings'), making the purpose understandable. However, it lacks specificity about what 'offerings' are (e.g., products, services, plans) and does not differentiate from sibling tools like 'list_customers' or 'list_resources', leaving ambiguity about scope.

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 does not mention any context, prerequisites, or exclusions, such as whether it's for browsing available items or if other tools like 'query' might be more appropriate for filtered searches. This leaves the agent with minimal usage direction.

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

list_projectsC

List all projects

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/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. 'List all projects' implies a read operation, but it doesn't specify whether this is paginated, requires authentication, has rate limits, or what the return format is. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 'List all projects' is extremely concise with zero waste—it's a single, front-loaded phrase that directly states the action and resource. Every word earns its place, making it efficient for an agent to parse.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'projects' entails, the return format, or any behavioral traits like pagination or errors. For a tool that likely returns a list of items, more context is needed to guide the agent effectively.

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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline score of 4 is appropriate as it doesn't introduce confusion or redundancy.

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 'List all projects' clearly states the verb ('List') and resource ('projects'), making the purpose understandable. However, it lacks specificity about scope or filtering, and doesn't differentiate from sibling tools like 'list_customers' or 'list_resources' beyond the resource name.

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. The description doesn't mention context, prerequisites, or exclusions, and with sibling tools like 'query' that might overlap in functionality, the agent receives no help in tool selection.

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

list_resourcesC

List all resources

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'List all resources' implies a read-only operation, but it doesn't specify whether this is paginated, sorted, filtered, or what format/resources are returned. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 at three words, front-loaded with the core action, and has zero wasted text. Every word ('List all resources') directly contributes to understanding the tool's purpose without redundancy.

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 simplicity (0 parameters, no output schema), the description is minimal but inadequate. It doesn't explain what 'resources' are, how they're returned, or how this differs from similar list_* tools. For even a simple tool, more context is needed to be complete.

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 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no filtering or arguments by stating 'all resources'. This aligns well with the schema, earning a baseline 4 for zero-parameter tools.

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 'List all resources' clearly states the action (list) and target (resources), but it's vague about what 'resources' specifically refers to and doesn't differentiate from sibling tools like list_customers or list_projects. It avoids tautology by not just repeating the tool name, 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?

The description provides no guidance on when to use this tool versus alternatives like query or other list_* siblings. It doesn't mention any context, prerequisites, or exclusions, leaving the agent with no usage direction beyond the basic purpose.

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

queryC

Run a read-only SQL query

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It states 'read-only', which implies safety, but doesn't disclose other behavioral traits such as permissions needed, rate limits, error handling, or what the query returns. This is inadequate for a tool that executes arbitrary SQL.

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—a single sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan, though this brevity contributes to gaps in other dimensions.

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 executing SQL queries, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks critical context like return format, error cases, or usage prerequisites, making it insufficient for safe and effective tool invocation.

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 adds no information about the 'sql' parameter beyond what the schema provides (a required string). No details on SQL dialect, allowed operations, or constraints are given, leaving significant gaps.

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 action ('run') and resource ('SQL query'), specifying it's read-only. However, it doesn't differentiate from sibling tools like list_customers or list_invoices, which might also be read-only queries but with different scopes.

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 like the list_* siblings. It mentions 'read-only' but doesn't specify contexts or exclusions, leaving the agent to guess based on tool names alone.

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.

7 tool updatesv1.0.0Jan 2, 2026
- First observedcreate_invitation
- First observedlist_customers
- First observedlist_invoices
- First observedlist_offerings
- First observedlist_projects
- First observedlist_resources
- First observedquery

Install Server

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

TDQS

B3.2/5.0

Disambiguation4/5

Most tools have distinct purposes: list_customers, list_invoices, list_offerings, list_projects, and list_resources each target different Waldur entities, while create_invitation and query serve unique functions. However, the five list_* tools could potentially be confused for similar listing operations, though their descriptions clarify distinct scopes.

Naming Consistency5/5

Tool names follow a highly consistent pattern: six tools use verb_noun format (e.g., create_invitation, list_customers), and the seventh (query) aligns with a simple verb style. All names are in snake_case, making them predictable and readable across the set.

Tool Count4/5

With 7 tools, the count is reasonable for a management server, covering core listing operations and key actions like invitations and queries. It feels slightly thin for comprehensive Waldur management, but each tool serves a clear purpose without bloat.

Completeness2/5

The tool set is severely incomplete for Waldur management, focusing heavily on listing operations with only one creation tool (create_invitation) and a generic query. Missing are essential CRUD operations for customers, invoices, offerings, projects, and resources (e.g., create, update, delete), leaving significant gaps that will hinder agent workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

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

mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
62
hithereiamaliff-mcp-datagovmy BOAuth
ai.smithery
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Government Data Open Data
23

Related MCP Servers

MCP Server
Autonomous Agents Developer Tools
la-rebelion
A
license
Not graded
quality
D
maintenance
MCP Server simplifies the implementation of the Model Context Protocol by providing a user-friendly API to create custom tools and manage server workflows efficiently.
Updated 2 years ago (2025-01-13 19:45 UTC)
21
4
MIT
MCP Server
Autonomous Agents Developer Tools
agentico-dev
A
license
Not graded
quality
D
maintenance
MCP Server provides a simpler API to interact with the Model Context Protocol by allowing users to define custom tools and services to streamline workflows and processes.
Updated 2 years ago (2025-02-07 17:24 UTC)
16
3
MIT
MCP Server Weaviateofficial
Databases Vector Databases
weaviate
F
license
Not graded
quality
D
maintenance
The MCP Server for Weaviate facilitates integration with Weaviate using a customizable Python-based server, enabling interaction with Weaviate databases and OpenAI APIs via configurable URL and API keys.
Updated 3 months ago (2026-05-26 15:59 UTC)
162
-
AccelMCP
Developer Tools Agent Orchestration
t-ogawa-dev
F
license
Not graded
quality
B
maintenance
An MCP server with HTTP/stdio support, a web admin panel for managing services, capabilities, and user permissions with Bearer token authentication, enabling relay and access control for MCP tools.
Updated 2 months ago (2026-06-24 15:57 UTC)
-

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/waldur/waldur-mcp-server'

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

Waldur MCP server

Quickstart

Installation

Generate Waldur Token

Claude Desktop MCP Server Configuration

Debugging

Common issues

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

MCP Server Weaviateofficial

Latest Blog Posts

MCP directory API