Skip to main content
Glama

get_menstrual_cycle_day_view

Read-only

Retrieve the menstrual-cycle day view for a specified calendar date to check cycle status and related daily details.

Instructions

生理周期日视图。与官方客户端 get_menstrual_cycle_day_view 一一对应。参数和日期限制沿用官方接口。Return the menstrual-cycle day view for a calendar date.

Input Schema

NameRequiredDescriptionDefault
today_dateYes
calendar_dateYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds only that it mirrors the official client and that date restrictions follow the official interface — it never says what those restrictions are (range limits, timezone, cycle-boundary behavior), so the added context is a pointer rather than a disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short, but the content is split across Chinese and English restatements of the same fact, and '与官方客户端 get_menstrual_cycle_day_view 一一对应' spends a sentence saying nothing an agent can act on. The actionable part (the return value) is not front-loaded.

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?

For a two-required-param tool with 0% schema coverage and no output schema, the description should at minimum define the date formats and explain why today_date is needed. It leaves both open and only gestures at unspecified 'date restrictions', so an agent cannot confidently construct a call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and neither parameter has any title beyond its name. The description clarifies 'calendar_date' loosely as the date of the view but says nothing about format (ISO? epoch?), and 'today_date' — required for an ostensibly read-only day view — is entirely unexplained.

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?

States a specific verb+resource: returns the menstrual-cycle day view for a calendar date. It is distinguishable from the sibling get_menstrual_cycle_summary by the word 'day', though the description never explicitly contrasts the two.

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 when-to-use guidance at all, and no mention of when to prefer get_menstrual_cycle_summary over this day view. The only hint is '参数和日期限制沿用官方接口', which defers constraints to an external document rather than stating them.

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