wsl-envidat-mcp

Server Quality Checklist

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

Latest release: v0.2.5
Disambiguation3/5
Several thematic tools (wsl_get_avalanche_data, wsl_get_naturgefahren_data, wsl_get_forest_data) overlap significantly, as avalanche data is also part of natural hazards. Additionally, wsl_search can replicate these queries, creating multiple ambiguous paths to similar data.
Naming Consistency4/5
Most names follow a clear verb_noun pattern (get_*, list_*, search). However, 'wsl_catalog_stats' breaks the pattern (noun_noun), and there is a mix of English verbs with German nouns (e.g., 'get_naturgefahren_data'), which is a minor inconsistency.
Tool Count5/5
With 10 tools, the server is well-scoped for a data catalog. It covers catalog overview, thematic queries, search, metadata retrieval, and organization listing—no unnecessary bloat or insufficiency.
Completeness4/5
The tool surface covers core read operations: search, metadata retrieval, organization listing, and thematic filters. Minor gaps exist (e.g., no explicit biodiversity query), but these are covered by the flexible search tool, making it functionally complete.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no behavioral context beyond stating it returns data, which is already obvious from the purpose. No contradiction, but no additional value.
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 well-structured with a clear opening sentence, bullet lists for content, and separate usage notes. It is not overly long and each section adds value. However, the usage guidelines could be integrated more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be detailed), the description adequately covers purpose, parameter semantics, and application context. It does not mention pagination or data limits, but for a single-parameter query tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that the 'params' parameter controls 'Anzahl Ergebnisse und Format' (number of results and format), which adds meaning beyond the schema (which only has a generic description for SimpleQueryInput). However, it does not detail constraints like the maximum limit of 20, so compensation is partial.
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 that the tool returns datasets on natural hazards in Switzerland, listing specific types (avalanches, landslides, etc.). It distinguishes from more specific siblings like wsl_get_avalanche_data by covering multiple hazard types. However, it could be more precise about the exact nature of the returned data (e.g., events with date/location).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by listing relevant applications (Raumplanung, Katastrophenschutz, etc.), which helps the agent decide when to use it. However, it does not explicitly state when not to use it or compare with specific sibling tools for disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by listing specific data sources and monitoring programs, giving behavioral context beyond safety flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a bullet list of specific datasets. It is front-loaded with the primary purpose but could be trimmed without losing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter) and presence of an output schema, the description provides a good overview of the data domains covered, helping the agent decide relevance.
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 coverage is 0%, and the description only restates the parameter name and basic purpose ('Anzahl Ergebnisse und Format') with no additional semantics. The enum values and constraints in the schema are not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Swiss forest data and enumerates specific datasets (e.g., Landesforstinventar, Sanasilva). The name and sibling tools (e.g., wsl_get_avalanche_data) make the domain unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance. However, the tool name and sibling list imply it is for forest-related queries, providing implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's claim of returning data is consistent. It adds no additional behavioral details beyond the annotations, which is acceptable given the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The additional 'Args' and 'Returns' sections provide structure, though some words are unnecessary. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter) and presence of an output schema, the description could be more complete about the return format. It only says 'string of recent datasets' without details on structure or fields, leaving gaps for the agent.
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?
With 0% schema description coverage, the description should provide meaningful parameter details. It only lists 'limit' and 'response_format' without explaining their purpose (e.g., limit controls count, response_format chooses output type). This adds minimal value beyond the schema names.
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 it returns the most recently published or updated EnviDat datasets, which is a specific verb+resource. Sibling tools like wsl_get_dataset focus on a single dataset, making this distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's useful for regular monitoring workflows and discovering new research data, providing context for use. However, it does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and safe. Description adds value by listing the specific data types included, providing context beyond annotations.
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?
Bullet list and args/returns section are efficient, but there is some redundancy with the title. Overall good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers data types and content well. Output schema exists, so missing return structure details are compensated.
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 coverage is 0%, description only says 'Anzahl Ergebnisse und Format' which is minimal. Does not explain limit range or response_format options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves avalanche and snow data from SLF, listing specific contents. It distinguishes itself from siblings like wsl_get_forest_data by topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for avalanche/snow data, but no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, already clarifying the operation is safe. The description adds value by specifying the returned content (description, contact, dataset overview) and providing an example, which enriches understanding beyond the annotation's simple safety hints.
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 well-structured with a purpose sentence, what it provides, an example, and parameter explanations. It is slightly verbose but each sentence adds value, and the docstring format aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not detail return values. It covers purpose, parameters, and an example. However, it does not mention any error conditions (e.g., invalid slug) or specify the output format, nor does it reference siblings. Slightly more completeness would be ideal.
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?
Although schema description coverage is 0% at the top level, the description explicitly lists and explains both parameters (name and include_datasets) with examples and clear German labels, compensating for the lack of inline schema descriptions. The docstring format adds clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns details of a WSL research unit including its datasets, with specific verb 'gibt ... zurück' and resource 'Forschungseinheit'. It distinguishes from sibling tools like wsl_list_organizations by focusing on details of a single organization, and provides a concrete example ('slf').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing details of a specific organization via slug, but does not explicitly state when to use this versus alternatives like wsl_list_organizations for listing all organizations or wsl_get_dataset for a single dataset. No when-not or direct comparisons to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds that it returns a string of statistics, but provides no further behavioral details beyond what annotations convey, so the description adds moderate value.
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 short and front-loaded with the core purpose. However, it includes both German and English text, which is slightly redundant. Each sentence earns its place, but could be made more concise by using one language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema, and low complexity, the description fully covers what the tool does, what it returns (a string of statistics), and its use case. No additional information 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?
There are no parameters, so the description does not need to add parameter details. The baseline for zero-parameter tools is 4, and the description clearly explains what the tool returns, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an overview of the EnviDat catalog, listing domains, organizations, and data volume. It is explicitly described as an entry point, distinguishing it from sibling tools that focus on specific data types or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is useful as an entry point to see what's available and how the catalog is structured, implying it should be used before more specific queries. However, it does not explicitly mention when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description only adds that it supports prefix search. No contradictions with annotations.
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 concise and well-structured, with a brief purpose statement, usage hint, and parameter/return documentation. It could be slightly more compact but is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and the presence of an output schema, the description fully covers what the tool does, when to use it, and what parameters are needed. No gaps remain.
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 description explains the function of each parameter (query and limit) beyond what the schema provides, compensating for the 0% schema description coverage. It adds clarity on usage and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tags in the EnviDat catalog, using a specific verb and resource. It is distinct from sibling tools like wsl_search, which searches for datasets, not tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions it is useful for finding search terms to use in wsl_search, providing clear usage context. However, it does not specify when not to use it or mention alternatives beyond wsl_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, non-destructive, idempotent, and open-world. The description adds valuable behavioral context: empty results return related tags as suggestions, and 'OR' is a stop word in Solr syntax. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for use case, important notes, and example. Every sentence is informative, no fluff, and front-loaded with the core purpose. Excellent balance of detail and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidelines, behavioral traits, constraints, and examples. It mentions empty result fallback and response format options. However, it does not describe the structure of returned results (e.g., fields in output), which would be helpful for an agent. Given the schema covers input well and annotations provide safety, it's still quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema itself contains detailed descriptions for all subfields (query, domain, organization, bbox, limit, offset, response_format), providing high coverage. The tool description only gives a high-level summary of the filters, adding minimal extra value beyond the schema. The constraint that at least one filter must be set is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a unified search in the WSL EnviDat catalog, combining keyword, curated research domain, organization, and bounding box. It distinguishes from sibling tools by being the general search across all EnviDat, while siblings like wsl_get_avalanche_data are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a <use_case> section listing specific scenarios (e.g., Swiss environmental research, climate impact research) and <important_notes> requiring at least one filter and explaining Solr syntax and empty result behavior. However, it does not explicitly state when to use this tool versus the more specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safe, non-destructive behavior. The description adds value by specifying the return format (slug and dataset count) and the return type (str), complementing the annotations.
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 concise and front-loaded with the main action. The returns line partially repeats the purpose, but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the purpose, use case, and output summary completely, making it fully informative for the tool's complexity.
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 no parameters, so schema description coverage is 100%. The description adds meaning by explaining the return value and use case, which suffices for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all WSL research units with their dataset count, and explicitly differentiates from the sibling tool wsl_get_organization by positioning it as a preliminary overview for identifying relevant organizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating it is useful for identifying relevant organizations for subsequent queries with wsl_get_organization. It does not mention when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by noting that it returns non-public resource metadata if present, which is an important behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: a main sentence, followed by use_case, important_notes, and example sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and the description explains the return type (metadata and resources including download URLs) and includes an example, the description is complete for an agent to understand what the tool does and what it returns.
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?
Although the schema description coverage is reported as 0%, the schema actually includes descriptions for both parameters. The tool description adds context by linking id_or_slug to search results and providing an example, which enhances understanding beyond the schema alone.
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 it returns complete metadata and resources of an EnviDat dataset, specifies the use case as a detail view after search, and lists outputs like DOI, license, authors, and download links. It distinguishes itself from sibling tools like wsl_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's a follow-up step after wsl_search and provides important notes on how to obtain the id_or_slug parameter from search results (field 'name') and that it returns non-public resource metadata if available, giving clear when-to-use and how-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/malkreide/wsl-envidat-mcp'

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