germany-mcp-server

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes targeting different domains like traffic, weather, laws, and statistics, but there is some overlap between 'autobahn_warnungen' and 'nina_warnungen' (both cover warnings, though one is traffic-specific and the other is broader disasters) and between 'get_german_weather_warnings' and 'wetter_warnungen' (both provide weather warnings, but with different input parameters). Descriptions help clarify, but agents might occasionally confuse these pairs.
Naming Consistency3/5
Naming is mixed with no consistent pattern: some use snake_case (e.g., 'autobahn_baustellen'), others use camelCase (e.g., 'get_destatis_data'), and some are German compound words (e.g., 'strom_erzeugung'). Verbs vary from 'get_' to descriptive nouns, making it readable but inconsistent in style.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for a broad 'Germany' server covering multiple domains like traffic, weather, laws, and statistics. It feels comprehensive rather than bloated, though it borders on being heavy for a single server.
Completeness4/5
The server covers diverse German data domains well, including traffic, weather, laws, and statistics, with good CRUD-like operations (e.g., search, get). Minor gaps exist, such as no update/delete tools for laws or deeper parliamentary actions beyond search, but agents can work around these for most queries.
Average 3.4/5 across 16 of 16 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation (finding stations), it doesn't mention potential limitations like rate limits, authentication needs, data freshness, or what the return format looks like (e.g., list of stations with details). For a tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args' section. There's no unnecessary verbosity, though the 'Args' label could be more integrated (e.g., as part of the main text).
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 moderate complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameter basics but lacks behavioral context, usage guidance, and output details, leaving gaps for an AI agent to infer correctly.
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 includes an 'Args' section that explains the 'autobahn' parameter with an example ('A2', 'A7'), adding meaning beyond the schema which only provides a title and default value. However, with 0% schema description coverage and only one parameter documented, the baseline is met but not exceeded—it doesn't cover additional details like format constraints or valid Autobahn codes.
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 tool's purpose: 'E-Auto-Ladestationen entlang einer Autobahn finden' (find electric vehicle charging stations along a highway). It specifies both the verb ('finden') and resource ('Ladestationen'), though it doesn't explicitly differentiate from sibling tools like 'autobahn_baustellen' or 'autobahn_warnungen' which have different purposes.
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 doesn't mention sibling tools like 'autobahn_baustellen' or 'get_energy_prices' that might be relevant in related contexts, nor does it specify prerequisites or exclusions for usage.
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. It states it retrieves 'current' closures but doesn't specify data freshness, rate limits, authentication needs, error conditions, or what 'current' means (e.g., real-time, daily updates). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and one explaining the parameter. The structure is front-loaded with the core functionality. However, the second sentence could be integrated more smoothly rather than starting with 'Args:' which feels like schema repetition.
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 low complexity (single parameter, no output schema, no annotations), the description is minimally complete. It explains what the tool does and the parameter meaning, but lacks details on output format, error handling, or differentiation from siblings. For a simple query tool, this is borderline adequate but could be more informative.
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 adds meaningful context for the single parameter 'autobahn' by providing examples ('A5', 'A8') and clarifying it's an autobahn designation. However, with 0% schema description coverage and only one parameter, this is adequate but minimal. It doesn't explain the default value 'A1' mentioned in the schema or whether all German autobahns are supported.
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 tool's purpose: retrieving current closures on a specific autobahn. It specifies the verb ('Aktuelle Sperrungen') and resource ('auf einer Autobahn'), making the function unambiguous. However, it doesn't explicitly differentiate from its closest sibling 'autobahn_baustellen' (construction sites), which might have overlapping use cases.
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 doesn't mention sibling tools like 'autobahn_baustellen' (construction sites) or 'autobahn_warnungen' (warnings), which might be relevant for related road information. The only implied usage is when seeking closures on a specific highway.
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 full burden. It states the tool shows current activities but doesn't disclose behavioral traits like data freshness, rate limits, authentication needs, or what 'aktuell' means (e.g., last 24 hours, last week). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences that directly state the purpose and examples. It's front-loaded with the main function and uses clear language without waste. However, it could be slightly more efficient by combining ideas, so it's not a perfect 5.
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 no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It lacks details on what 'aktuell' entails, the format of returned activities, or any limitations. For a tool that likely returns dynamic data, more context on behavior and output is needed for an AI agent to use it 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%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline for 0 params is 4, as it avoids unnecessary detail and matches the schema's completeness.
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 what the tool does: 'Letzte parlamentarische Aktivitäten im Bundestag' (latest parliamentary activities in the Bundestag) with specific examples ('Debatten, Abstimmungen und Beschlüsse'). It distinguishes from siblings like 'bundestag_suche' (search) by focusing on current activities rather than searching. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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 doesn't mention when to choose this over 'bundestag_suche' or other tools, nor does it specify any prerequisites or exclusions. Usage is implied by the content ('aktuelle' suggests recency), but no explicit guidelines are given.
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. It describes what the tool does (shows traffic warnings) but lacks details on behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the output format looks like. For a tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded: it starts with the main purpose, lists warning types, and then provides parameter details. It's efficient with minimal waste, though the 'Args' section could be integrated more smoothly into the flow.
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 moderate complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and parameter semantics adequately but lacks behavioral transparency and usage guidelines. Without annotations or output schema, it should do more to explain what the tool returns or any operational constraints.
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 includes an 'Args' section that explains the single parameter 'autobahn' as 'Autobahn-Bezeichnung (z.B. "A3", "A9")' (motorway designation, e.g., 'A3', 'A9'), adding meaning beyond the input schema, which only provides a title and default value with 0% schema description coverage. This compensates well for the low coverage, though it doesn't detail constraints like valid formats beyond examples.
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 tool's purpose: 'Aktuelle Verkehrswarnungen auf einer Autobahn' (current traffic warnings on a motorway) and specifies the types of warnings: 'Staus, Unfälle und Verkehrsbehinderungen' (traffic jams, accidents, and traffic obstructions). This is specific verb+resource+scope, though it doesn't explicitly differentiate from sibling tools like 'autobahn_baustellen' (motorway construction sites) or 'autobahn_sperrungen' (motorway closures), which appear related.
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 doesn't mention sibling tools like 'autobahn_baustellen' or 'autobahn_sperrungen', which seem to cover related traffic information, nor does it specify any prerequisites or exclusions. Usage is implied by the description but not explicitly stated.
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. It mentions the data source (Bundesnetzagentur) and what information is shown (total consumption and trend), but doesn't disclose important behavioral aspects like whether this is real-time or historical data, update frequency, rate limits, authentication requirements, or what format the output takes. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. The first sentence immediately states the core purpose, followed by additional details about what's shown and the data source. Every sentence earns its place, with no wasted words or redundant information.
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 that this is a data retrieval tool with no annotations and no output schema, the description should provide more complete context. It doesn't explain what the output format looks like, whether the data is real-time or historical, update frequency, or any limitations. For a tool that presumably returns structured data about electricity consumption, this leaves significant gaps for an AI 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 tool has zero parameters, and the schema description coverage is 100% (though there are no parameters to describe). The description appropriately doesn't discuss parameters since none exist, which is correct for this tool. A baseline of 4 is appropriate for zero-parameter tools.
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 tool's purpose: to show current electricity consumption in Germany, including total consumption and trend using data from Bundesnetzagentur. It uses specific verbs ('shows') and identifies the resource ('electricity consumption in Germany'), but doesn't explicitly distinguish it from its sibling 'strom_erzeugung' (electricity generation).
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 doesn't mention when this tool is appropriate versus other energy-related tools like 'get_energy_prices' or 'strom_erzeugung', nor does it specify any prerequisites or exclusions for its use.
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 but offers minimal behavioral disclosure. It mentions searching but doesn't describe what the search returns (e.g., list of documents, summaries), pagination, rate limits, authentication needs, or error conditions. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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 efficiently structured with a clear purpose statement followed by a parameter explanation section. Every sentence adds value: the first establishes scope, the second specifies resource types, and the parameter details provide essential usage context without redundancy.
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 2 parameters with 0% schema coverage and no output schema, the description does an adequate job explaining parameter semantics but lacks completeness regarding behavioral aspects and output format. For a search tool, users need to know what kind of results to expect, which isn't addressed.
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 adds meaningful context for both parameters beyond the schema's 0% coverage. It explains 'suchbegriff' as a search term with examples ('Klimaschutz', 'Digitalisierung') and clarifies 'wahlperiode' values (20=current, 19=previous) with the default implied. This compensates well for the lack of schema descriptions.
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 tool searches for legislative drafts and proceedings in the German Bundestag, specifying the resources (Drucksachen, parlamentarische Vorgänge). It distinguishes from most siblings by focusing on parliamentary content, though it doesn't explicitly differentiate from 'bundestag_aktivitaeten' which might have overlapping 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 doesn't mention when to choose this over 'search_german_laws' or 'bundestag_aktivitaeten', nor does it specify any prerequisites, exclusions, or optimal use cases beyond the basic function.
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. It mentions the tool 'shows' warnings, implying a read-only operation, but doesn't disclose behavioral traits like data freshness, rate limits, authentication needs, or error handling. For a public API tool with no annotations, this leaves significant gaps in understanding how it behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the core purpose, provides examples, and cites the source in two concise sentences. Every sentence adds value without redundancy, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is moderately complete. It explains what the tool does and gives examples, but lacks details on output format, data scope (e.g., geographic limits), or behavioral context. For a simple read tool, this is adequate but has clear gaps in transparency.
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%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's unnecessary here. A baseline of 4 is appropriate as the schema fully covers the lack of parameters, and the description doesn't need to compensate.
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 tool's purpose: 'Aktuelle Katastrophen-Warnungen in Deutschland' (current disaster warnings in Germany) and lists specific examples like floods, storms, power outages, and fires. It distinguishes from siblings by focusing on NINA/BBK warnings rather than traffic, weather, or other data. However, it doesn't explicitly contrast with 'get_german_weather_warnings' or 'wetter_warnungen', which might overlap.
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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions the source (Bundesamt für Bevölkerungsschutz) but doesn't clarify when to choose this over 'get_german_weather_warnings' or 'wetter_warnungen' for weather-related alerts, or other sibling tools for different hazards. Usage is implied by the content but not explicitly stated.
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. It states what data is returned ('Ort, Richtung und Details' - location, direction, and details) which is helpful, but doesn't mention important behavioral aspects like whether this is real-time or cached data, rate limits, authentication requirements, error conditions, or data freshness. For a public API tool with no annotation coverage, this represents significant gaps.
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 appropriately concise with three sentences that each serve a purpose: stating the tool's function, describing the returned data, and explaining the parameter. It's front-loaded with the core purpose. The only minor inefficiency is the separation of the parameter explanation into an 'Args:' section rather than integrating it more naturally.
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 moderate complexity (retrieving dynamic construction data), no annotations, no output schema, and 0% schema description coverage, the description is minimally adequate. It covers the core purpose and parameter meaning but lacks important context about data format, freshness, limitations, and error handling. The absence of output schema means the description should ideally describe return values more thoroughly.
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 adds meaningful context for the single parameter 'autobahn' by explaining it's the highway designation with concrete examples ('A1', 'A7', 'A61'). Since schema description coverage is 0% (the schema only shows title and type without explanation), and there's only one parameter, this compensation is effective. The description doesn't mention the default value 'A1' shown in the schema, but provides the essential semantic understanding.
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 ('abrufen' - retrieve/fetch) and resource ('aktuelle Baustellen auf einer deutschen Autobahn' - current construction sites on a German highway). It distinguishes itself from siblings like 'autobahn_ladestationen' (charging stations) and 'autobahn_sperrungen' (closures) by focusing specifically on construction sites rather than other highway-related data.
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. While it's clear this tool retrieves construction sites, there's no mention of when to use it versus 'autobahn_sperrungen' (which might include construction-related closures) or 'autobahn_warnungen' (which might include construction warnings). No prerequisites, exclusions, or complementary tools are mentioned.
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 full burden. It describes what data is returned (pollen forecasts for specific types and days) but lacks critical behavioral details: whether this is a read-only operation, data freshness/update frequency, rate limits, authentication requirements, error conditions, or response format. For a data retrieval tool with no annotations, this is a significant gap.
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 efficiently structured: a clear purpose statement first, followed by specific pollen types and forecast periods, then parameter documentation. Every sentence adds value with no redundancy. The parameter documentation uses a clean 'Args:' section with practical examples.
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 moderate complexity (single parameter, no output schema, no annotations), the description covers the core functionality well but has gaps. It explains what data is returned and parameter usage adequately, but lacks information about response structure, error handling, and operational constraints. Without annotations or output schema, the description should ideally provide more behavioral context.
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 schema only has title and type), the description fully compensates by explaining the 'region' parameter meaningfully: it specifies it accepts German regions/states like 'Bayern', 'NRW', 'Berlin', and clarifies that an empty string returns all regions. This adds substantial semantic value beyond the bare schema.
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 tool's purpose: providing current pollen forecast predictions for German regions, listing specific pollen types (Ambrosia, birch, grasses, hazel) and forecast periods (today, tomorrow, day after tomorrow). It distinguishes itself from sibling tools by focusing on pollen forecasts rather than traffic, weather warnings, or other data. However, it doesn't explicitly differentiate from potential similar tools not in the sibling list.
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 usage context (when pollen forecasts are needed for German regions) but doesn't explicitly state when to use this tool versus alternatives. It mentions the region parameter can be left empty for all regions, which provides some usage guidance, but lacks explicit comparisons with sibling tools like weather-related ones.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the data source (Bundesnetzagentur/SMARD), which adds useful context about reliability and origin. However, it does not disclose other behavioral traits such as rate limits, update frequency, or potential errors, leaving gaps for a tool with no annotation support. This partial disclosure justifies a score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose and subsequent sentences adding relevant details (energy sources and data source). Every sentence earns its place without redundancy, making it efficient and well-structured for quick understanding.
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 low complexity (0 parameters, no output schema, no annotations), the description is moderately complete. It explains what data is shown and the source, but lacks details on output format, timeliness, or error handling. For a simple read-only tool, this is adequate but has clear gaps, scoring a minimum viable 3.
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 the schema description coverage is 100% (as there are no parameters to describe). The description does not need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as per the rules. No additional information is required or provided.
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 what the tool does: 'Aktuelle Stromerzeugung in Deutschland nach Energieträger' (current electricity generation in Germany by energy source). It specifies the verb 'zeigt' (shows) and the resource 'Stromerzeugung' (electricity generation), but does not explicitly differentiate from sibling tools like 'stromverbrauch' (electricity consumption) or 'get_energy_prices' (energy prices), which is why it scores 4 instead of 5.
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 sibling tools like 'stromverbrauch' for consumption data or 'get_energy_prices' for pricing, nor does it specify any context or exclusions for usage. The lack of explicit when/when-not statements or named alternatives results in a score of 2.
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?
With no annotations provided, the description carries full burden. It discloses the data source and scope (6000+ laws), supports abbreviations, and mentions default/max limits. However, it doesn't cover important behavioral aspects like rate limits, authentication needs, pagination, error handling, or what happens with partial/no matches. The description adds useful context but leaves gaps.
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 appropriately sized with three paragraphs: purpose, search capabilities, and parameter details. Each sentence adds value - no fluff. It could be slightly more front-loaded by moving the abbreviation example earlier, but overall structure is efficient.
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 search tool with 2 parameters, no annotations, and no output schema, the description provides adequate basics but has gaps. It covers what the tool does and parameter usage well, but lacks information about return format, error conditions, performance characteristics, or how results are ranked/returned. Given the complexity and lack of structured fields, it should do more.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: 'query' as search term or abbreviation with multiple examples, and 'limit' with default (10) and maximum (50) values. This adds substantial meaning beyond the bare schema. The only minor gap is lack of format details for abbreviations.
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 tool searches German federal laws and regulations by title, with specific mention of the source (gesetze-im-internet.de) and scope (6000+ laws). It distinguishes itself from siblings by focusing on legal search rather than transportation, weather, or parliamentary data. However, it doesn't explicitly contrast with 'bundestag_suche' which might also search legal documents.
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 usage for searching German laws by title or abbreviation, with examples provided. However, it doesn't explicitly state when to use this tool versus alternatives like 'bundestag_suche' (which might search parliamentary activities) or other legal research tools. No explicit exclusions or prerequisites are mentioned.
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. It states what the tool does (shows weather data) but lacks behavioral details such as whether it's read-only (implied but not stated), any rate limits, authentication needs, error handling, or what happens with invalid inputs. For a tool with no 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 is appropriately sized and front-loaded: the first sentence states the core purpose, followed by details on what data is shown and parameter usage. The 'Args:' section is clearly structured. Every sentence adds value with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description does a decent job but has gaps. It covers the purpose, basic usage, and parameter semantics well, but lacks details on behavioral traits (e.g., read-only status, errors) and output format. For a simple weather query tool, it's minimally adequate but could be more 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?
Schema description coverage is 0%, so the description must compensate. It does so effectively: it explains that 'ort' is a city name with examples ('Berlin', 'München', 'Hamburg'), and that 'lat' and 'lon' are optional alternatives to the city name, specifying they are latitude and longitude. This adds meaningful context beyond the bare schema, though it doesn't cover all possible edge cases (e.g., format of lat/lon).
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 tool's purpose: 'Aktuelles Wetter an einem Ort in Deutschland' (current weather at a location in Germany) and specifies it shows temperature, precipitation, wind, cloud cover, etc. It distinguishes from siblings like 'wetter_warnungen' (weather warnings) by focusing on current conditions rather than alerts, though it doesn't explicitly name alternatives. The verb 'zeigt' (shows) is 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 provides clear context for usage: it's for current weather in Germany, and specifies that either a city name OR lat/lon coordinates should be provided ('Entweder einen Stadtnamen ODER lat/lon angeben'). It doesn't explicitly state when not to use it or name alternatives like 'wetter_warnungen', but the context is sufficiently clear for basic decision-making.
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. It mentions data sources (Bundesnetzagentur/SMARD) and specific price types (Day-Ahead, EPEX Spot, BAFA), which adds some context. However, it lacks details on rate limits, authentication needs, response format, or whether this is a read-only operation, which is a significant gap for a tool with no 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 appropriately sized and front-loaded, starting with a clear purpose statement followed by parameter details. It uses bullet points for clarity, but could be slightly more concise by integrating the parameter explanation more seamlessly. Overall, it avoids unnecessary information and is well-structured.
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 moderate complexity (one parameter, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics well, but lacks details on behavioral aspects like response format, data freshness, or error handling. This leaves gaps that could hinder an AI agent's effective use of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed semantics for the single parameter 'type', explaining that 'electricity' or 'strom' retrieves electricity prices and 'gas' retrieves gas import prices. With 0% schema description coverage and only one parameter, this fully compensates by adding essential meaning beyond the basic schema, making the parameter usage clear.
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's purpose with specific verbs ('abrufen' - retrieve, 'Zeigt' - shows) and resources (German energy prices for electricity and gas). It distinguishes itself from siblings by focusing on energy prices rather than traffic, parliamentary, weather, or other data sources, making the purpose 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?
The description implies usage by specifying the types of energy data available (electricity and gas prices), but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites, exclusions, or comparisons with sibling tools is provided, leaving usage context inferred rather than explicit.
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?
With no annotations provided, the description carries the full burden. It discloses that data comes from the Federal Statistical Office via Eurostat, which adds context about source and reliability. However, it lacks details on rate limits, authentication needs, error handling, or response format (e.g., time series vs. single values), leaving behavioral gaps for a data retrieval tool.
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 statement, indicator list, data source note, and parameter details in a clear 'Args:' section. It is appropriately sized for a 2-parameter tool, though the indicator list is lengthy (7 items), which is necessary but slightly reduces conciseness. 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 no annotations and no output schema, the description is incomplete. It covers parameters well and mentions the data source, but lacks details on return values (e.g., format, units, time ranges), error cases, or usage constraints. For a statistical data tool with 2 parameters, this leaves gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so excellently: it explains both parameters ('indicator' and 'year'), lists all possible enum-like values for 'indicator' with clear meanings (e.g., 'bip' for nominal GDP in million EUR), and specifies the default behavior for 'year' (last 5 years if omitted). This adds substantial meaning beyond the bare 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's purpose: 'Offizielle deutsche Statistikdaten von Destatis abrufen' (retrieve official German statistical data from Destatis). It specifies the verb 'abrufen' (retrieve) and the resource 'Statistikdaten' (statistical data), distinguishing it from sibling tools like weather or traffic tools by focusing on economic/population statistics.
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 usage context by listing available indicators (e.g., population, GDP) and noting data sources, but it does not explicitly state when to use this tool versus alternatives like 'get_energy_prices' or 'strom_erzeugung'. No exclusions or prerequisites are mentioned, leaving usage guidance incomplete.
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?
With no annotations provided, the description carries the full burden. It explains the tool's behavior: retrieving current warnings, showing types of warnings, and handling location parameters. However, it lacks details on rate limits, authentication needs, error handling, or response format. The description doesn't contradict any annotations since none exist.
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 and appropriately sized. It starts with the core purpose, adds details about warning types, explains the location logic, and includes a parameter section. Every sentence adds value, though the parameter section could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers the purpose, usage, and parameters adequately but lacks details on behavioral aspects like response format, error conditions, or data freshness. For a tool with 3 parameters and no structured metadata, more context would be helpful.
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 schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'ort' is a city name with an example, 'lat' is latitude, and 'lon' is longitude. It clarifies that all parameters are optional and explains the default behavior (nationwide warnings if no location provided). This goes beyond the basic schema, though it doesn't cover all possible edge cases.
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's purpose: retrieving current DWD weather warnings for a location. It specifies the types of warnings (storms, thunderstorms, heat, etc.) and distinguishes it from sibling tools like 'get_german_weather_warnings' and 'nina_warnungen' by mentioning the DWD source and focusing on warnings rather than current weather or other alert systems.
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 clear context on when to use the tool: for weather warnings at a specific location or nationwide if no location is provided. It doesn't explicitly mention when not to use it or name alternatives, but the distinction from siblings like 'wetter_aktuell' (current weather) is implied by the focus on warnings.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves current warnings directly from DWD, implying real-time data and an external API call. However, it lacks details on rate limits, error handling, authentication needs, or response format, which are important for a tool fetching live data.
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 and front-loaded: the first sentence states the core purpose, followed by details on warning types and source, then parameter documentation. Every sentence adds value with no redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, source, parameter usage, and filtering logic. However, it lacks details on output format (e.g., structure of warnings) and behavioral aspects like data freshness or errors, which would enhance completeness for an API-based tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It fully documents the single parameter 'region', explaining it filters by federal state or region (e.g., 'Bayern', 'NRW'), with examples and noting that an empty string returns all warnings nationwide. This adds essential meaning beyond the basic 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's purpose: retrieving current weather warnings from the German Weather Service (DWD) for various hazard types like storms, thunderstorms, heavy rain, heat, etc. It specifies the source ('official warnings directly from DWD') and distinguishes it from sibling tools like 'nina_warnungen' or 'wetter_warnungen' by focusing on DWD-specific data.
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 clear context for when to use this tool: to get official weather warnings from DWD for Germany. It does not explicitly state when not to use it or name alternatives (e.g., 'nina_warnungen' for civil protection warnings), but the context is sufficiently clear given the tool's specific focus on DWD data.
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:

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

Score Badge

Copy to your README.md:

[![germany-mcp-server MCP server](https://glama.ai/mcp/servers/AiAgentKarl/germany-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/AiAgentKarl/germany-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/AiAgentKarl/germany-mcp-server'

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