A
licenseNot graded
qualityA
maintenanceDaily Bitcoin/crypto cycle scoring, on-chain indicators, strategy insights, on-demand backtests. Bearer + x402 pay-per-call
MIT
Biorhythm MCP Server by RoxyAPI
by com.roxyapi
Server Details
Biorhythm cycles, forecasts, critical days and compatibility for AI agents, one API key.
Ownership verified
- Status
- Healthy
- Uptime
- 100.0% over 43 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.2/5.0
Scored across 6 tools
Disambiguation4/5
Each tool targets a distinct biorhythm use case: reading, phases, forecast, critical days, daily summary, and compatibility. There is mild overlap between reading, phases, and daily since all report cycle values, but the descriptions clearly separate completeness, payload weight, and intended interface.
Naming Consistency5/5
All six tools follow the exact same `post_biorhythm_<noun>` convention. The naming is perfectly predictable and makes the purpose of each tool immediately clear from the suffix.
Tool Count5/5
Six tools is well-scoped for a biorhythm API and each tool earns its place by covering a different consumer need. There is no redundancy or excessive expansion.
Completeness5/5
The surface covers the core biorhythm domain comprehensively: full readings, lightweight phase checks, forecasts, critical days, daily briefings, and compatibility scoring. No obvious missing operation would prevent a typical biorhythm integration from succeeding.
Available Tools
6 toolspost_biorhythm_compatibilityCalculate compatibility - Biorhythm alignment between two peopleARead-onlyInspect
Calculate biorhythm compatibility between two people by overlaying their cycle profiles on a target date. Returns per-cycle alignment scores (0-100) for physical, emotional, and intellectual cycles, an overall compatibility score, relationship rating, strengths, challenges, practical advice, and a daily sync snapshot showing the absolute difference in each primary cycle. Perfect for dating apps, relationship platforms, team-building tools, and couples coaching applications.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| person1 | Yes | ||
| person2 | Yes | ||
| targetDate | No | Date to evaluate compatibility on in YYYY-MM-DD format. Defaults to today (UTC). Compatibility varies by day since biorhythm cycles are continuous. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| advice | Yes | |
| cycles | Yes | |
| rating | Yes | |
| person1 | Yes | |
| person2 | Yes | |
| dailySync | Yes | |
| strengths | Yes | |
| challenges | Yes | |
| targetDate | Yes | |
| overallScore | Yes |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds some algorithmic detail (overlaying cycle profiles on a target date) but does not disclose additional behavioral traits like authentication needs, rate limits, or edge-case handling. It does not contradict the 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 a single paragraph that front-loads the core purpose ('Calculate biorhythm compatibility...') and then enumerates outputs and use cases. It is informative without being overly verbose, though it could be improved with bullet points for the long list of outputs.
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?
An output schema exists, so return values are formally covered. The description adds use cases and enumerates the key outputs, making it complete for an agent to decide when to call it. It does not mention any missing prerequisites or edge cases, but given the tool's simplicity, the coverage is adequate.
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 60%, and the schema itself provides descriptions for all parameters (lang, compact, birthDate, targetDate). The tool description does not add any parameter-specific meaning beyond the schema, but given the schema already carries the load, a baseline score 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 verb 'calculate' and the specific resource 'biorhythm compatibility between two people', distinguishing it from sibling tools that focus on single-person or aspect-specific analyses. It lists concrete outputs (physical, emotional, intellectual scores, etc.) 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use-case context (dating apps, relationship platforms, team-building, couples coaching) and implies the tool is for two-person compatibility, which differentiates it from siblings. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_biorhythm_critical_daysFind critical days - Zero crossing detection for any date rangeARead-onlyInspect
Find all critical days (zero crossings) within a date range up to 180 days. Returns each critical day with cycle name, period, direction (ascending or descending), severity (single, double, or triple), and advisory text. Highlights rare double critical days where two primary cycles cross zero simultaneously and extremely rare triple critical days where all three primary cycles cross zero on the same date. Ideal for calendar integrations, push notification systems, alert engines, and wellness scheduling tools.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| endDate | No | End date of the search range in YYYY-MM-DD format. Defaults to startDate + 90 days. Maximum range: 180 days. | |
| birthDate | Yes | Birth date of the person in YYYY-MM-DD format. | |
| startDate | No | Start date of the search range in YYYY-MM-DD format. Defaults to today (UTC). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| endDate | Yes | |
| birthDate | Yes | |
| startDate | Yes | |
| criticalDays | Yes | |
| totalCriticalDays | Yes | |
| tripleCriticalDay | Yes | |
| doubleCriticalDays | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavior: it returns cycle name, period, direction, severity, and advisory text, and it highlights rare double and triple critical days. This gives the agent a clear picture of what the tool produces without relying on the 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 three sentences with the primary purpose front-loaded. Each sentence adds value: scope, output contents, and especially notable edge cases. No filler or repetition.
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?
For a read-only lookup tool with rich schema coverage and an output schema, the description is complete: it states the range cap, the output fields, the severity taxonomy, and the practical use cases. An agent has enough to select and invoke this tool 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?
Schema description coverage is 100%, so the input schema fully documents birthDate, startDate, endDate, lang, and compact. The description's mention of the 180-day range reinforces the schema but does not add parameter-level meaning beyond it. Baseline 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 opens with a specific verb and resource: 'Find all critical days (zero crossings) within a date range.' It names the exact output content and clearly differentiates this from sibling tools like daily, forecast, phases, compatibility, and reading by focusing on zero-crossing critical-day detection.
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 gives clear context for when to use the tool: date-range-based zero-crossing detection up to 180 days, ideal for calendar integrations, notifications, alert engines, and wellness scheduling. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_biorhythm_dailyGet daily biorhythm - Seeded reading for daily check-in featuresARead-onlyInspect
Get a daily biorhythm reading with seeded randomness for consistent "biorhythm of the day" features. Same seed and same date always produce the same reading, perfect for daily push notifications, morning briefings, and wellness app check-ins. Returns energy rating, overall phase, a spotlight on one featured cycle, quick-read values for all three primary cycles, a daily message, and actionable advice. The spotlight cycle is deterministically selected by the seed, creating variety across users while maintaining consistency for each individual.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date for the reading in YYYY-MM-DD format. Defaults to today (UTC). Useful for viewing past daily readings or pre-generating future ones. | |
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| seed | No | Optional seed for reproducible readings. Same seed + same date = same reading every time. Pass any unique identifier (userId, email hash, session token). Omit for anonymous daily readings. | |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| seed | Yes | |
| advice | Yes | |
| quickRead | Yes | |
| spotlight | Yes | |
| dailyMessage | Yes | |
| energyRating | Yes | |
| overallPhase | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral detail beyond that: same seed plus same date always yields the same reading, the spotlight cycle is deterministically selected, and the output includes a consistent set of fields. This gives an agent confidence about reproducibility and side-effect-free behavior without contradicting the annotations.
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 three sentences, front-loads the core operation, and each sentence earns its place: what it does, why the seed matters, and what the response contains. There is no filler or redundant restating of the tool name.
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?
With a full output schema, read-only annotations, zero required parameters, and a description covering purpose, use cases, determinism, and returned content, nothing essential is missing. An agent has enough context to select and invoke this tool 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 description coverage is 100%, so the baseline is 3, but the description adds value by explaining the seed's deterministic effect on the spotlight cycle and tying the seed to per-user consistency. It reinforces the date and lang defaults without repeating schema mechanics, which helps an agent understand why and how to set parameters.
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 opens with a specific verb and resource: 'Get a daily biorhythm reading with seeded randomness.' It clearly defines the tool's scope as a seeded, daily-reading generator and distinguishes it from siblings like post_biorhythm_forecast or post_biorhythm_phases by emphasizing the daily check-in use case and deterministic seed behavior. The list of returned fields further anchors what the tool does.
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 names concrete scenarios: daily push notifications, morning briefings, and wellness app check-ins. It does not explicitly list exclusions or alternative sibling tools, so it stops short of full when-to-use/when-not-to-use guidance, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_biorhythm_forecastGet biorhythm forecast - Multi-day cycle predictions with best and worst daysARead-onlyInspect
Generate a biorhythm forecast for a date range up to 90 days. Returns daily cycle values for physical, emotional, intellectual, and intuitive cycles, daily energy ratings, critical day identification, and a summary with best day, worst day, average energy, and period-level guidance. Ideal for wellness apps, productivity planners, scheduling tools, and calendar integrations that need forward-looking biorhythm data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| endDate | No | End date of the forecast range in YYYY-MM-DD format. Defaults to startDate + 30 days. Maximum range: 90 days. | |
| birthDate | Yes | Birth date of the person in YYYY-MM-DD format. | |
| startDate | No | Start date of the forecast range in YYYY-MM-DD format. Defaults to today (UTC). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| endDate | Yes | |
| summary | Yes | |
| birthDate | Yes | |
| startDate | Yes | |
| totalDays | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds what data is returned but nothing about rate limits, auth, or other behavioral nuances. It does not contradict annotations and adds moderate context beyond the structured fields.
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 three sentences, front-loaded with the core function and then details. It avoids redundancy and marketing fluff, though the use-case sentence adds some value but is not strictly necessary. It is concise and well-structured.
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?
With an output schema present and annotations covering safety, the description is largely complete. It explains the range, outputs, and use cases. It does not mention defaults like startDate defaults to today, but that is in the schema. Given the tool's complexity and available structured data, this is adequate.
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 schema already documents all parameters. The description adds little beyond restating the date range limit ('up to 90 days') which is already in the schema. No additional parameter meaning is provided beyond what the schema gives, so baseline 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 states a specific verb (generate) and resource (biorhythm forecast for a date range), and lists the exact outputs (daily cycle values, energy ratings, critical day identification, summary with best/worst day). It clearly distinguishes from siblings like post_biorhythm_daily (single day) and post_biorhythm_compatibility (pairwise) by emphasizing the multi-day range and summary components.
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 ideal use cases ('wellness apps, productivity planners...') which implies when to use it, but it does not explicitly state when not to use it or mention alternatives. It lacks explicit exclusions or comparisons to sibling tools, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_biorhythm_phasesGet phase info - Lightweight cycle status for dashboards and widgetsARead-onlyInspect
Get current phase information for all 10 biorhythm cycles without the full interpretation payload. Returns value, phase name, phase label, day position within cycle, cycle period, days until next critical crossing, and short-term trend for each cycle. Includes a compact summary string. Designed as a lightweight endpoint for dashboards, widgets, status bars, and quick-check interfaces that need biorhythm phase data without editorial text.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| birthDate | Yes | Birth date of the person in YYYY-MM-DD format. | |
| targetDate | No | Date to get phase information for in YYYY-MM-DD format. Defaults to today (UTC). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| phases | Yes | |
| summary | Yes | |
| birthDate | Yes | |
| targetDate | Yes | |
| daysSinceBirth | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing the lightweight/compact nature, the exclusion of editorial interpretation, and the presence of a compact summary string. It does not add unrelated details like auth or rate limits, which are not critical here.
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 tight sentences with no filler. The first sentence front-loads the core purpose and key differentiator, the second enumerates the returned fields, and the third names the intended audience. Every sentence earns its place.
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?
With an output schema present and safety annotations already covering read-only behavior, the description sufficiently covers what the tool does, what it returns, and when to use it. An agent has everything needed to invoke and interpret this endpoint 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?
Schema description coverage is 100%, so the schema already fully documents parameters like birthDate, targetDate, lang, and compact. The description adds no parameter-specific guidance beyond what the schema provides, which aligns with the baseline score of 3.
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: 'Get current phase information for all 10 biorhythm cycles.' It clearly differentiates from siblings by emphasizing the lightweight payload, 'without the full interpretation payload,' which distinguishes it from fuller endpoints like post_biorhythm_reading or post_biorhythm_forecast.
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 a clear intended-use context: dashboards, widgets, status bars, and quick-check interfaces that need phase data without editorial text. It stops short of explicitly naming alternatives or stating when not to use it, but the use-case framing is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_biorhythm_readingGet biorhythm reading - Complete cycle analysis for any dateARead-onlyInspect
Calculate a complete biorhythm reading for a given birth date and target date. Returns all 10 cycle values (physical, emotional, intellectual, intuitive, aesthetic, awareness, spiritual, passion, mastery, wisdom), phase detection with 8 distinct states, energy rating (1-10), overall phase assessment, editorial-grade interpretation, actionable advice, and critical day alerts. Perfect for wellness apps, dating platforms, productivity tools, and AI chatbot integrations that need structured biorhythm data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English. | en |
| compact | No | Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens. | |
| birthDate | Yes | Birth date of the person in YYYY-MM-DD format. This is the anchor for all biorhythm cycle calculations. | |
| targetDate | No | Date to calculate the reading for in YYYY-MM-DD format. Defaults to today (UTC) if omitted. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| advice | Yes | |
| cycles | Yes | |
| birthDate | Yes | |
| targetDate | Yes | |
| energyRating | Yes | |
| overallPhase | Yes | |
| criticalAlerts | Yes | |
| daysSinceBirth | Yes | |
| interpretation | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by detailing the return payload (cycle values, phases, energy rating, advice, alerts), which helps set expectations. It does not contradict annotations. However, it does not disclose any potential edge cases (e.g., date validation, timezone handling) or operational behaviors beyond the fact that it calculates and returns data.
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 two sentences: the first delivers the core purpose and outputs, the second lists target audiences. It is concise and front-loaded, with no filler. The use-case sentence is slightly marketing-oriented but still useful. It could be trimmed, but overall it is efficient and well-structured.
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 presence of an output schema (as indicated by context signals) and rich parameter descriptions, the description provides a strong overview of what the tool returns, including the full list of cycle names, phase states, and additional outputs like advice and alerts. It does not mention error handling or edge cases, but these are not strictly required when an output schema exists. The description is sufficient for an agent to understand the tool's scope.
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 each parameter (lang, compact, birthDate, targetDate) already has a thorough description. The tool description only repeats 'birth date and target date' without adding new semantic detail. It does not explain the 'compact' or 'lang' parameters beyond what the schema provides, so it does not meaningfully enhance parameter understanding. Baseline 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 tool calculates a complete biorhythm reading for given birth and target dates, and enumerates the specific outputs (10 cycles, phase detection, energy rating, etc.). It is not a tautology and the verb 'Calculate' plus resource 'biorhythm reading' is specific. However, it does not explicitly differentiate itself from sibling tools like post_biorhythm_daily or post_biorhythm_forecast, relying instead on the word 'complete' to imply broader scope.
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 gives context by listing ideal use cases ('wellness apps, dating platforms, productivity tools, AI chatbot integrations'), which implies when it might be used. But it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. There is no guidance like 'for a single-day summary use post_biorhythm_daily instead'. This leaves some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
- Changed
post_biorhythm_compatibility1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "advice": { + "type": "string" + }, + "challenges": { + "items": { + "type": "string" + }, + "type": "array" + }, + "cycles": { + "additionalProperties": { + "properties": { + "alignment": { + "type": "number" + }, + "description": { + "type": "string" + }, + "difference": { + "type": "number" + }, + "person1Value": { + "type": "number" + }, + "person2Value": { + "type": "number" + }, + "phase": { + "enum": [ + "in_sync", + "complementary", + "neutral", + "opposing" + ], + "type": "string" + } + }, + "required": [ + "person1Value", + "person2Value", + "difference", + "alignment", + "phase", + "description" + ], + "type": "object" + }, + "type": "object" + }, + "dailySync": { + "properties": { + "emotionalDiff": { + "type": "number" + }, + "intellectualDiff": { + "type": "number" + }, + "physicalDiff": { + "type": "number" + } + }, + "required": [ + "physicalDiff", + "emotionalDiff", + "intellectualDiff" + ], + "type": "object" + }, + "overallScore": { + "type": "number" + }, + "person1": { + "properties": { + "birthDate": { + "type": "string" + } + }, + "required": [ + "birthDate" + ], + "type": "object" + }, + "person2": { + "properties": { + "birthDate": { + "type": "string" + } + }, + "required": [ + "birthDate" + ], + "type": "object" + }, + "rating": { + "type": "string" + }, + "strengths": { + "items": { + "type": "string" + }, + "type": "array" + }, + "targetDate": { + "type": "string" + } + }, + "required": [ + "person1", + "person2", + "targetDate", + "overallScore", + "rating", + "cycles", + "strengths", + "challenges", + "advice", + "dailySync" + ], + "type": "object" +}
- Changed
post_biorhythm_critical_days1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "birthDate": { + "type": "string" + }, + "criticalDays": { + "items": { + "properties": { + "advisory": { + "type": "string" + }, + "cycle": { + "enum": [ + "physical", + "emotional", + "intellectual" + ], + "type": "string" + }, + "date": { + "type": "string" + }, + "direction": { + "enum": [ + "ascending", + "descending" + ], + "type": "string" + }, + "period": { + "type": "number" + }, + "severity": { + "enum": [ + "single", + "double", + "triple" + ], + "type": "string" + } + }, + "required": [ + "date", + "cycle", + "period", + "direction", + "severity", + "advisory" + ], + "type": "object" + }, + "type": "array" + }, + "doubleCriticalDays": { + "items": { + "type": "string" + }, + "type": "array" + }, + "endDate": { + "type": "string" + }, + "startDate": { + "type": "string" + }, + "totalCriticalDays": { + "type": "number" + }, + "tripleCriticalDay": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "birthDate", + "startDate", + "endDate", + "totalCriticalDays", + "criticalDays", + "doubleCriticalDays", + "tripleCriticalDay" + ], + "type": "object" +}
- Changed
post_biorhythm_daily1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "advice": { + "type": "string" + }, + "dailyMessage": { + "type": "string" + }, + "date": { + "type": "string" + }, + "energyRating": { + "type": "number" + }, + "overallPhase": { + "enum": [ + "high_energy", + "mixed", + "recovery", + "critical" + ], + "type": "string" + }, + "quickRead": { + "properties": { + "emotional": { + "type": "number" + }, + "intellectual": { + "type": "number" + }, + "physical": { + "type": "number" + } + }, + "required": [ + "physical", + "emotional", + "intellectual" + ], + "type": "object" + }, + "seed": { + "type": "string" + }, + "spotlight": { + "properties": { + "cycle": { + "enum": [ + "physical", + "emotional", + "intellectual" + ], + "type": "string" + }, + "message": { + "type": "string" + }, + "phase": { + "enum": [ + "peak", + "high", + "rising", + "critical_ascending", + "critical_descending", + "falling", + "low", + "trough" + ], + "type": "string" + }, + "value": { + "type": "number" + } + }, + "required": [ + "cycle", + "value", + "phase", + "message" + ], + "type": "object" + } + }, + "required": [ + "date", + "seed", + "energyRating", + "overallPhase", + "spotlight", + "quickRead", + "dailyMessage", + "advice" + ], + "type": "object" +}
- Changed
post_biorhythm_forecast1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "birthDate": { + "type": "string" + }, + "days": { + "items": { + "properties": { + "criticalCycles": { + "items": { + "type": "string" + }, + "type": "array" + }, + "date": { + "type": "string" + }, + "daysSinceBirth": { + "type": "number" + }, + "emotional": { + "type": "number" + }, + "energyRating": { + "type": "number" + }, + "intellectual": { + "type": "number" + }, + "intuitive": { + "type": "number" + }, + "isCritical": { + "type": "boolean" + }, + "physical": { + "type": "number" + } + }, + "required": [ + "date", + "daysSinceBirth", + "physical", + "emotional", + "intellectual", + "intuitive", + "energyRating", + "isCritical", + "criticalCycles" + ], + "type": "object" + }, + "type": "array" + }, + "endDate": { + "type": "string" + }, + "startDate": { + "type": "string" + }, + "summary": { + "properties": { + "averageEnergy": { + "type": "number" + }, + "bestDay": { + "type": "string" + }, + "criticalDayCount": { + "type": "number" + }, + "periodAdvice": { + "type": "string" + }, + "worstDay": { + "type": "string" + } + }, + "required": [ + "bestDay", + "worstDay", + "criticalDayCount", + "averageEnergy", + "periodAdvice" + ], + "type": "object" + }, + "totalDays": { + "type": "number" + } + }, + "required": [ + "birthDate", + "startDate", + "endDate", + "totalDays", + "summary", + "days" + ], + "type": "object" +}
- Changed
post_biorhythm_phases1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "birthDate": { + "type": "string" + }, + "daysSinceBirth": { + "type": "number" + }, + "phases": { + "additionalProperties": { + "properties": { + "dayInCycle": { + "type": "number" + }, + "daysUntilCritical": { + "type": "number" + }, + "phase": { + "enum": [ + "peak", + "high", + "rising", + "critical_ascending", + "critical_descending", + "falling", + "low", + "trough" + ], + "type": "string" + }, + "phaseLabel": { + "type": "string" + }, + "totalDays": { + "type": "number" + }, + "trend": { + "enum": [ + "rising", + "falling", + "peaking", + "bottoming" + ], + "type": "string" + }, + "value": { + "type": "number" + } + }, + "required": [ + "value", + "phase", + "phaseLabel", + "dayInCycle", + "totalDays", + "daysUntilCritical", + "trend" + ], + "type": "object" + }, + "type": "object" + }, + "summary": { + "type": "string" + }, + "targetDate": { + "type": "string" + } + }, + "required": [ + "birthDate", + "targetDate", + "daysSinceBirth", + "phases", + "summary" + ], + "type": "object" +}
- Changed
post_biorhythm_reading1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "advice": { + "type": "string" + }, + "birthDate": { + "type": "string" + }, + "criticalAlerts": { + "items": { + "properties": { + "advisory": { + "type": "string" + }, + "cycle": { + "enum": [ + "physical", + "emotional", + "intellectual", + "intuitive", + "aesthetic", + "awareness", + "spiritual", + "passion", + "mastery", + "wisdom" + ], + "type": "string" + }, + "direction": { + "enum": [ + "ascending", + "descending" + ], + "type": "string" + }, + "type": { + "enum": [ + "zero_crossing" + ], + "type": "string" + } + }, + "required": [ + "cycle", + "type", + "direction", + "advisory" + ], + "type": "object" + }, + "type": "array" + }, + "cycles": { + "additionalProperties": { + "properties": { + "dayInCycle": { + "type": "number" + }, + "daysUntilCritical": { + "type": "number" + }, + "daysUntilPeak": { + "type": "number" + }, + "daysUntilTrough": { + "type": "number" + }, + "interpretation": { + "type": "string" + }, + "phase": { + "enum": [ + "peak", + "high", + "rising", + "critical_ascending", + "critical_descending", + "falling", + "low", + "trough" + ], + "type": "string" + }, + "phaseLabel": { + "type": "string" + }, + "rawValue": { + "type": "number" + }, + "trend": { + "enum": [ + "rising", + "falling", + "peaking", + "bottoming" + ], + "type": "string" + }, + "value": { + "type": "number" + } + }, + "required": [ + "value", + "rawValue", + "phase", + "phaseLabel", + "dayInCycle", + "daysUntilPeak", + "daysUntilTrough", + "daysUntilCritical", + "trend", + "interpretation" + ], + "type": "object" + }, + "type": "object" + }, + "daysSinceBirth": { + "type": "number" + }, + "energyRating": { + "type": "number" + }, + "interpretation": { + "type": "string" + }, + "overallPhase": { + "enum": [ + "high_energy", + "mixed", + "recovery", + "critical" + ], + "type": "string" + }, + "targetDate": { + "type": "string" + } + }, + "required": [ + "birthDate", + "targetDate", + "daysSinceBirth", + "cycles", + "energyRating", + "overallPhase", + "interpretation", + "advice", + "criticalAlerts" + ], + "type": "object" +}
6 tool updates
- Changed
post_biorhythm_compatibility2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_biorhythm_critical_days2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_biorhythm_daily2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_biorhythm_forecast2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_biorhythm_phases2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
- Changed
post_biorhythm_reading2 fields changed- changed
Input schema / properties / lang / descriptionPrevious value: -"Response language (ISO 639-1). Supported: en, tr, de, es, hi, pt, fr, ru. Defaults to en. Languages without translations yet return English."New value: +"Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English." - changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "tr", - "de", - "es", - "hi", - "pt", - "fr", - "ru" -]New value: +[ + "en", + "tr", + "de", + "es", + "hi", + "pt", + "fr", + "ru", + "zh-Hans", + "zh-Hant" +]
6 tool updates
- Changed
post_biorhythm_compatibility2 fields changed- added
Input schema / examplesAdded value: +[ + { + "person1": { + "birthDate": "1990-07-15" + }, + "person2": { + "birthDate": "1992-03-22" + } + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_biorhythm_critical_days2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthDate": "1990-07-15" + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_biorhythm_daily2 fields changed- added
Input schema / examplesAdded value: +[ + {} +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_biorhythm_forecast2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthDate": "1990-07-15" + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_biorhythm_phases2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthDate": "1990-07-15" + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
- Changed
post_biorhythm_reading2 fields changed- added
Input schema / examplesAdded value: +[ + { + "birthDate": "1990-07-15" + } +] - changed
Input schema / properties / compact / descriptionPrevious value: -"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."New value: +"Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {\"__cols\":[names],\"__rows\":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens."
6 tool updates
- Changed
post_biorhythm_compatibility1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_biorhythm_critical_days1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_biorhythm_daily1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_biorhythm_forecast1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_biorhythm_phases1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
- Changed
post_biorhythm_reading1 field changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false."New value: +"Set true to receive the exact same data in a token-optimized shape that is cheaper for you to read: whitespace is stripped and every array of same-shaped objects is encoded columnar as {\"__cols\":[field names],\"__rows\":[[values]]}, so each field name is sent once instead of once per row. Fully lossless (no field or value is dropped or changed) and typically 40 to 52 percent fewer tokens on large results. Prefer true whenever token or inference cost matters. Default false returns standard indented JSON."
6 tool updates
- Changed
post_biorhythm_compatibility1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_biorhythm_critical_days1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_biorhythm_daily1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_biorhythm_forecast1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_biorhythm_phases1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
- Changed
post_biorhythm_reading1 field changed- added
Input schema / properties / compactAdded value: +{ + "default": false, + "description": "Return the same data in a token-optimized compact shape (minified, with same-shaped arrays encoded columnar) to reduce LLM token cost. Lossless: no fields are dropped. Default false.", + "type": "boolean" +}
6 tool updates
- First observed
post_biorhythm_compatibility - First observed
post_biorhythm_critical_days - First observed
post_biorhythm_daily - First observed
post_biorhythm_forecast - First observed
post_biorhythm_phases - First observed
post_biorhythm_reading
Related MCP Connectors
Аccess to personalized Enigmata astrological forecasts (day/week/month/thematic) for AI assistants
Vedic kundli, panchang, dashas, nakshatras and KP charts for AI agents, one API key.
City geocoding and timezone resolution for birth data, for AI agents, one API key.
Astrology transit forecasts, timelines and significant-date feeds for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to query live space weather, aurora forecasts, earthquake feeds, and the Helios Oracle over HTTPS with no API keys.MIT
- AlicenseBqualityCmaintenanceReal-time crypto, stock, and prediction-market data for agents — prices, indicators, funding rates, DeFi TVL, macro calendar, and an AI momentum score. Configure one Base wallet key and it just works. No signup, no dashboard, no subscription.22208 npmMIT
zarq-risk-intelligenceofficial
AlicenseNot gradedqualityDmaintenanceReal-time crypto risk scoring for AI agents. Trust Score, crash probability, and distance-to-default for 205 tokens. Free, no API key needed.MIT
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.