met-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct weather data need: geocoding, hourly forecasts, nowcasting, alerts, solar events, ocean conditions, station lookup, and historical observations. The only potentially overlapping pair (get_forecast vs get_nowcast) is clearly separated by forecast horizon and description.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern, with get_ as the dominant prefix and find_/geocode_ as clear exceptions that still follow the same grammatical structure. This makes the tool surface highly predictable.
Tool Count5/5
Eight tools is well-scoped for a weather data server: each tool handles a specific data type or lookup step without redundancy. The count is large enough to cover the domain but small enough to avoid overwhelming an agent.
Completeness5/5
The tool set covers the full observation-to-forecast lifecycle: geocoding to obtain coordinates, station discovery for historical data, current conditions, short-term nowcast, forecast, alerts, ocean conditions, and solar events. No critical gaps are apparent for the stated weather domain.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to fall back on, the description carries the full burden of behavioral disclosure. It captures the core operation but omits at least one behavior implied by the schema: the ability to return multiple matches for an ambiguous name like 'Bergen.' It also doesn't disclose ordering ('Bergen, Norway' disambiguates, but the description doesn't mention it), potential for empty results, or rate limits. The description is true but under-specified.
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?
Two tight sentences, zero filler. The first sentence carries the functional weight; the second is a short bridge to the workflow it serves. Nothing to cut, and no fluff to trim.
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 tool this simple—2 params, no nested object—the description covers the core contract adequately. The missing piece is the multi-match behavior: an agent calling this with a generic 'Bergen' might not realize it can receive several candidate coordinates and would benefit from a hint about result order or how to disambiguate (e.g., 'the first result is the most likely match').
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?
Schema coverage for the 2 params is 100%: both 'name' and 'count' are documented inline with types, defaults, and examples, so the description doesn't need to re-explain them. It does miss a chance to clarify that 'count' controls the multi-match limit, but per the rubric, baseline 3 applies when schema coverage is high. No deduction needed.
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?
Clear verb+resource: "Find latitude and longitude for a place name" precisely states what the tool does. While the verb 'Find' is generic, the resource is specific enough that an agent won't confuse it with the sibling tools, which all handle weather 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 second sentence, 'Use the coordinates with the other tools,' offers only a weak procedural hint and not actual decision guidance. No mention of when to choose this over siblings, no exclusions, no edge cases like ambiguous place names. The sibling tools are all so clearly weather-specific that an agent can infer the geocoding role of this tool, but the description itself doesn't lay it out.
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 lists the three data types but omits units (e.g., meters, degrees Celsius), update frequency, data resolution, or boundary behavior for out-of-range coordinates. It also does not describe the response format, which is especially important since there is no output schema.
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 to the point, using two sentences with no filler. It conveys the tool's purpose and scope efficiently, though it could sacrifice brevity for a bit more behavioral detail.
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 simple 3-parameter tool with full schema coverage, the description includes the core provided data and geographic scope. However, it lacks explicit usage guidance, units, and response details, making it only marginally sufficient for an agent to call it correctly in diverse scenarios.
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 documents all three parameters with clear descriptions (latitude, longitude, hours) and constraints (ranges, default), giving 100% coverage. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
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 resource (ocean forecast) and the specific data provided (wave height, wave direction, sea temperature). It also limits geographic scope to the Norwegian coast, which differentiates it from a general forecast tool, though it does not explicitly name siblings.
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 gives a geographic coverage hint ('Covers the Norwegian coast and nearby seas') but does not explicitly state when to use this tool over get_forecast or get_nowcast, nor does it mention any exclusions or prerequisites. The agent is left to infer whether this is marine-focused.
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, the description carries the full burden. It mentions 'works worldwide' but omits behavioral details such as how times are formatted, the effect of utc_offset on returned times, handling of polar day/night, or error conditions. The description understates the tool's behavior.
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 a single, concise sentence that front-loads the core outputs and adds a scope note. No filler or redundancy exists.
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?
The tool is relatively simple, but the description omits details like the return format (e.g., time strings) and how utc_offset influences results. Given no output schema, the agent lacks clarity on what to expect. The description is adequate but not fully 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?
Schema description coverage is 100%, so all parameters are documented. The description adds minimal value beyond restating 'coordinate and date'; it does not elaborate on utc_offset or the relationship between parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns sunrise, sunset, and solar noon for a given coordinate and date, and notes global coverage. This clearly differentiates it from weather-based sibling tools like get_forecast or get_historical_weather.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives. It does not mention that it is specific to solar events, nor does it advise against using weather tools for this purpose. The lack of exclusion or alternative routing leaves the agent to infer usage.
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 does state the data source and coverage limitations ('best coverage in the Nordics'), which is useful. However, it omits any mention of response format, potential errors, rate limits, or whether the forecast includes specific metrics (temperature, wind, etc.), leaving the agent to assume standard behavior.
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?
Two sentences with no superfluous content. The primary purpose and scope are front-loaded, and the coverage note is placed second. Every word adds value.
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?
For a simple read-only forecast tool with fully documented parameters, the description is nearly complete. It explains the source, scope, and the nature of the data (hourly forecast). The lack of an output schema and behavioral details (like units or error handling) is a minor gap given the low complexity, but the description is sufficient for an agent to understand the tool's core function.
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 already provides clear descriptions for all three parameters ('latitude/longitude in decimal degrees', 'hours ahead to include'). The description adds the 'hourly' context which reinforces the `hours` parameter meaning, but adds little beyond that. With 100% schema coverage, a baseline of 3 is appropriate.
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 action ('Get'), the resource ('hourly weather forecast'), and the source ('MET Norway (Yr)') for a coordinate. It differentiates from sibling tools like get_nowcast (short-term) and get_historical_weather (past) by its explicit 'forecast' and 'hourly' scope. The global coverage hint adds further distinction.
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 context ('Works worldwide, best coverage in the Nordics') that implies general forecast use, but it does not explicitly state when to use this tool vs alternatives like get_nowcast, get_weather_alerts, or get_sun_events. No exclusions or decision criteria are provided, so the agent must infer usage from the tool names alone.
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 of behavioral disclosure. It states the core behavior (daily historical observations, source archive, age of data) but does not mention response format, units, pagination, or any potential limitations. While not misleading, it is sparse. For a simple read-only tool, this is adequate but not thorough, justifying a 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?
Two sentences with zero fluff. It front-loads the purpose ('Daily historical observations') and then provides a practical usage tip about finding station IDs. Every word earns its place; this is ideal conciseness.
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?
The tool is simple (4 params, no nested objects, no output schema). The description covers the core purpose and points to the sibling tool for station IDs, but it does not describe what the response looks like beyond 'observations'. Since there is no output schema, the agent must infer the return structure. Given the elements parameter and defaults, the response likely includes temperature, precipitation, and wind, but this is not explicitly stated. The description is adequate but could be more complete with a hint about the returned data shape.
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?
Schema description coverage is 100%, with all four parameters documented. The description adds only the suggestion to 'Find station ids with find_weather_stations', which essentially repeats the schema's hint for station_id. No additional meaning is added for 'from', 'to', or 'elements'. As per baseline, when schema covers everything, a 3 is appropriate since description adds minimal extra value.
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 'Daily historical observations from a weather station', which is a specific verb+resource. It distinguishes from siblings like get_forecast and get_nowcast by emphasizing 'historical', and mentions the Frost archive for context. An agent can immediately tell this is the historical data tool vs. the forecast or nowcast ones.
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 that this tool is for historical data, differentiating it from forecast/nowcast tools. It also explicitly instructs to find station ids via find_weather_stations, which is an alternative for obtaining a required parameter. However, it does not explicitly state when NOT to use this tool (e.g., 'use get_forecast for future data'), but the historical label is clear enough. So it has clear context but no explicit exclusions.
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 must carry the full behavioral disclosure. It states the data is radar-based and minute-by-minute, and it clearly warns that it is Nordic region only. However, it does not describe the return format (e.g., units of precipitation, a series vs. a single value), nor does it explicitly state that the operation is read-only (though that is implied). This is adequate for a simple read tool but leaves the response shape unspecified, which is a gap given no output schema.
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 two short sentences that front-load the most critical information: the precision (minute-by-minute), the duration (next 2 hours), the data source (radar), and the geographic scope (Nordic region only). The rhetorical question at the end encapsulates the purpose without extra verbosity. Every word serves a purpose.
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 tool with only two parameters and no output schema, the description conveys the core functionality and limitations well. However, because there is no output schema, the description should at least hint at what the tool returns (e.g., precipitation intensity in mm/h or a binary umbrella recommendation). The current wording leaves the return structure ambiguous, which an agent might need to know for downstream formatting. This is a noticeable completeness gap.
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 already fully describes latitude and longitude with ranges and degrees. The description adds meaningful semantic value by constraining usage to the Nordic region, implying that coordinates outside this region will not produce valid results. This is a functional addition beyond the schema's generic descriptions, though it does not add units or formats that are already provided.
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 specifies the resource (minute-by-minute precipitation), its temporal horizon (next 2 hours), data source (radar-based), geographic scope (Nordic region only), and the exact user question it answers ('do I need an umbrella right now?'). This distinguishes it from siblings like get_forecast (longer-term) and get_historical_weather (past). The verb 'get' and resource name 'nowcast' match the tool name and title.
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 clear context: the tool is for very short-term precipitation (2 hours) and is restricted to the Nordic region. However, it does not explicitly mention when to use this tool instead of get_forecast or get_historical_weather, nor does it state any exclusions beyond the geographic constraint. The time horizon implies a boundary, but the lack of explicit alternative routing leaves some inference required.
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 transparency burden. It discloses the data source (Frost) and hints at the return shape through the example id SN50540, but it does not state ordering by distance, output format, or count semantics.
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?
Two concise, information-dense sentences. The purpose is front-loaded and the actionable downstream usage follows without any padding or repetition.
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?
For a simple three-parameter lookup tool with no output schema, the description provides enough to call and use it: location inputs, a station id format, and a downstream tool. It stops short of explicitly stating the list return shape, but that omission is not critical.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds little parameter-level detail beyond the schema, but the schema already fully documents latitude, longitude, and count.
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 states a specific action and resource: 'Find the nearest official weather stations (Frost).' It also gives an example station id and points to get_historical_weather, which clearly differentiates this station-lookup tool from the weather-data sibling tools.
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?
It provides clear context: use this tool to obtain a station id, then pass that id to get_historical_weather. It does not explicitly list exclusions for sibling tools like get_forecast, so it lacks full when-not-to-use guidance.
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, the description carries the behavioral burden. It discloses the language of alert text (Norwegian) and the behavior when coordinates are omitted. It does not disclose response format, potential rate limits, or whether results are paginated. Since some key behaviors are missing, a 3 is appropriate.
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?
Three concise sentences with zero waste. The core purpose is front-loaded, followed by scope and a critical usage hint. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers the essential: what it returns (alerts), source (MET Norway), geography, language, and how to query all vs. filtered. It lacks explicit differentiation from alternatives and response format details, but these are less critical for a simple list tool. I rate 4.
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 100%, so baseline is 3. The description adds meaningful semantic context: 'Omit coordinates to get all current alerts' explains the optionality and effect of omitting parameters, which enriches the parameter meaning 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 states a specific verb and resource: 'Official danger warnings (wind, flood, ice, forest fire...) from MET Norway.' It clearly distinguishes from siblings like get_forecast and get_nowcast by focusing on native weather alerts rather than forecasts. The geographic scope is explicit.
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 usage context: covers Norway and its waters, and instructive guidance to omit coordinates to get all alerts. However, it does not explicitly name alternative tools or state when not to use this tool, so exclusions are absent. Thus 4 for clear context without explicit alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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