Skip to main content
Glama

Cosmic Chemistry

by co.cosmicchemistry
OverviewDiscussionsAdmin

The Moon today

moon_today
Read-onlyIdempotent

Use this when someone asks where the Moon is right now, today or on another date: its sign (Vedic and Western), its nakshatra, its phase, or when the next full moon or new moon comes ("what sign is the Moon in today", "moon phase today", "next full moon", "today’s nakshatra", "what sign is the Moon in on 3 November"). Needs no birth details. Send the town to get the times as local clock times there; without one they are in UTC. Do not use for a person’s own Moon sign at birth: use moon_sign_nakshatra for that.

Input Schema

NameRequiredDescriptionDefault
dateNoOptional: a date as YYYY-MM-DD, for the Moon at midday that day. Leave out for right now.
placeNoOptional: the town, so the times come as local clock times there.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / date
      Added value: +{
+  "description": "Optional: a date as YYYY-MM-DD, for the Moon at midday that day. Leave out for right now.",
+  "type": "string"
+}
    • addedInput schema / properties / place
      Added value: +{
+  "description": "Optional: the town, so the times come as local clock times there.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful behavior: no birth details required, that supplying a town converts times to local clock time, and that omitting it yields UTC. It stops short of noting output format or whether 'next full moon' can be beyond the queried date, but the added context is solid.

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?

Single front-loaded paragraph that leads with the use case before examples and the exclusion. The parenthetical example queries are slightly verbose but they double as disambiguation cues, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description names the returnable facts (sign, nakshatra, phase, next full/new moon) and both timezone behaviors. Combined with annotations covering safety, an agent has everything needed to call it correctly.

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 coverage is 100%, so baseline is 3, but the description adds the UTC-default fallback when 'place' is omitted, which the schema does not state. It also reinforces that date yields the Moon at midday while omission means right now. Meaningful value 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?

States a specific verb+resource (where the Moon is, its sign/nakshatra/phase/next full-new moon) and scopes it to right now or a given date. It explicitly separates itself from moon_sign_nakshatra, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering queries, states 'Needs no birth details', and names the exclusion plus the correct alternative: 'Do not use for a person's own Moon sign at birth: use moon_sign_nakshatra for that.' When-to-use, when-not, and alternative are all explicit.

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

All Cosmic Chemistry toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources