Waldur MCP Server

Official

by waldur

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![waldur-mcp-server MCP server](https://glama.ai/mcp/servers/waldur/waldur-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/waldur/waldur-mcp-server)

Score Badge

Copy to your README.md:

[![waldur-mcp-server MCP server](https://glama.ai/mcp/servers/waldur/waldur-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/waldur/waldur-mcp-server)

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