Skip to main content
Glama
Sign In
io.github.qso-graph/eme-mcp

io.github.qso-graph/eme-mcp

by qso-graph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Eme Degradation

eme_degradation
Read-onlyIdempotent

Calculate current or forecast Earth-Moon-Earth degradation to see how far moon conditions fall below the best case, optionally using your grid locator for topocentric results.

Instructions

How much worse than the best case the moon is, now or at a given time.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "eme_degradation"
  }
}

Input Schema

NameRequiredDescriptionDefault
whenNoUTC time (ISO 8601). Default now.
locatorNoYour grid square, for a topocentric range. Optional.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare this read-only, idempotent and non-destructive, so the safety profile is covered. The description adds a little framing by saying the value is relative to a best case, but it does not explain what the degradation baseline is or how to interpret large vs small values, leaving the semantics of the number unclear even with an output schema present.

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?

It is a single front-loaded sentence with no filler, and the default-now behavior is stated up front. Brevity is a virtue here, though it crosses slightly into under-specification of the core concept.

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 — two optional parameters and a published output schema — so the definition does not need much. Still, an agent is left unsure what quantity is returned and how it relates to sibling EME tools, which is the main gap for correct selection.

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 both `when` and `locator` fully documented, so the schema does the heavy lifting. The description only echoes the time dimension ("now or at a given time") and says nothing about the optional topocentric locator, adding essentially no meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys a specific concept — a degradation metric of the moon relative to a best case — but the phrasing "how much worse than the best case the moon is" is cryptic and never names the actual computed quantity or its units. It also gives no cue distinguishing it from siblings such as eme_path_loss or eme_moon_window, which an agent could easily confuse with it.

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?

There is no when-to-use guidance beyond "now or at a given time," which merely restates the optional time parameter. Nothing tells the agent when this metric is preferable to eme_path_loss or eme_moon_window, and no prerequisites or exclusions are mentioned.

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

Deploy Server

Other Tools