Life Path, Expression, karmic debt and Chaldean numerology readings for AI agents.
Scored across 20 tools
Each tool targets a distinct numerology calculation or reference (e.g., life path, expression, soul urge, personal year) with clear parameter differences and unique outputs; no two tools are interchangeable.
All tool names follow a strict snake_case verb_noun pattern (get_* or post_*) with the domain prefix 'numerology_' and descriptive suffixes, making the set highly predictable.
20 tools is on the higher side, but each corresponds to a specific, non-redundant numerology computation or lookup, so the set feels granular rather than bloated; slightly heavy for a single MCP server.
The surface covers core numbers, cycles, compatibility, karmic analysis, both major systems (Pythagorean and Chaldean), and reference meanings, with a comprehensive chart tool that aggregates many features; no obvious gaps in the domain.
Get the classical Chaldean meaning of a compound number, also called a fadic number, from 10 to 52 as Cheiro defines it. A compound number is the unreduced two-digit total behind a name or date, read beside its single-digit root. The response returns the root, the nature (fortunate, unfortunate or mixed), the full interpretation in the language set by lang, and the symbolic name where Cheiro gives one, such as The Wheel of Fortune for 10 or The Crown of the Magi for 21; a number from 33 up that repeats a lower one carries a sameAs pointer to it. Built for Chaldean numerology references, name analysis tools and AI agents.
| 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 |
| number | Yes | Compound number from 10 to 52. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| root | Yes | |
| nature | Yes | |
| number | Yes | |
| sameAs | No | |
| meaning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint true, destructiveHint false), so the bar is lower. The description still adds real behavioral context: the nature classification (fortunate/unfortunate/mixed), language-driven interpretation, the symbolic-name field, and the non-obvious sameAs pointer for repeating numbers 33+.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and range, then response detail. Dense but mostly earning its place; the trailing 'Built for Chaldean numerology references, name analysis tools and AI agents' is mild audience filler rather than actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema and annotations already carry return shape and safety, and the description still supplies the domain concept (fadic number vs root) and edge-case behavior (sameAs). Nothing essential is missing for a correct call, though explicit sibling routing would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 number, lang and compact fully. The description reinforces the numeric range and the role of lang, but adds essentially nothing about parameter syntax or interaction beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource (get Chaldean meaning of a compound number) and pins the scope precisely to the 10–52 fadic range, explaining what a compound number is versus its single-digit root. It does not explicitly name the sibling get_numerology_meanings_number, so an agent must infer the split between the two, but the resource itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'read beside its single-digit root' hints that this complements a single-digit lookup, and the closing sentence names audiences (references, name analysis tools, agents) rather than conditions. There is no explicit when-to-use-this-instead-of-X guidance against the many sibling numerology tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full numerology meaning of any number 1 to 9 or the master numbers 11, 22 and 33. The response returns the archetype title, keywords, a core description, strengths, challenges, career, relationships and spirituality in the language set by lang, the same reading every core number endpoint returns for that number. Built for numerology reference pages, custom calculators, educational apps and AI agents.
| 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 |
| number | Yes | Numerology number (1-9, 11, 22, 33) | |
| 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. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes |
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 genuine value beyond that by enumerating what comes back (archetype title, keywords, core description, strengths, challenges, career, relationships, spirituality) and guaranteeing consistency with the other core-number endpoints. It omits any note on rate limits or partial-translation behavior in the body, though the schema covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the domain and return contents in two tight sentences. The trailing 'Built for numerology reference pages, custom calculators, educational apps and AI agents' is marketing filler that does not help an agent invoke the tool, costing it the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not detail return structure, yet it still summarizes the payload fields usefully. Domain bounds, language behavior and consistency semantics are all covered; only invocation-level guidance relative to siblings is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including the lang enum, the number pattern, and the compact columnar-shape explanation, so the schema carries the parameter burden. The description only restates that output follows 'the language set by lang' with no added format or constraint detail, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (numerology meaning) and bounds the input domain to 1-9 plus master numbers 11/22/33, which cleanly separates it from get_numerology_compound_number. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'the same reading every core number endpoint returns for that number' implies this is the canonical core-number lookup, but there is no explicit when-to-use/when-not guidance and no named alternatives among the many post_numerology_* calculation siblings. The audience list ('reference pages, calculators, educational apps') is context, not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Birth Day number from the day of the month a person was born, 1 to 31, with Pythagorean numerology. The 11th, 22nd and 29th keep the master numbers 11 and 22, other two-digit days reduce to one digit, and the 13th, 14th, 16th and 19th are flagged as karmic debt with their meaning. The response returns the calculation and a full interpretation of the special talents the day brings in the language set by lang. Built for birthday features, talent and career discovery tools, and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Day of birth (1-31) | |
| 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. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| calculation | Yes | |
| hasKarmicDebt | Yes | |
| karmicDebtNumber | No | |
| karmicDebtMeaning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive), and the description adds real behavioral detail: the master-number preservation for 11/22/29, the one-digit reduction rule, and the karmic-debt flagging for 13/14/16/19. It also discloses that the response carries a full interpretation. It omits any rate-limit or auth context, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences that lead with the calculation and its reduction rules, which is the most decision-relevant content. The trailing 'Built for birthday features, talent and career discovery tools, and AI agents' is audience filler rather than routing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be fully re-explained, and params plus annotations are well covered. The remaining gap is that the definition does not tell the agent how this calculation relates to sibling tools such as karmic_debt or life_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds framing for 'day' as the birth day of month (1-31) and ties 'lang' to the language of the returned interpretation, complementing the schema's own notes. 'compact' is left entirely to its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate the Birth Day number') with precise scope: the day of month 1-31 under Pythagorean numerology. The Birth Day number is clearly distinct from sibling calculations like life_path, soul_urge or karmic_debt, so an agent can identify the correct tool without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives audience context ('Built for birthday features, talent and career discovery tools') but never states when to choose this over the many sibling numerology tools, nor any exclusion or prerequisite. Usage is only implied by naming the specific calculation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate four numerology Bridge numbers from a full birth name and birth date: Life Path and Expression, Expression and Soul Urge, Soul Urge and Personality, and Expression and Personality. Each bridge is the distance between two core numbers, from 0 to 8, where 0 means the two are already in harmony, and comes with guidance for closing the gap in the language set by lang. Built for personal development, coaching and personality analysis tools and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day (1 to 31) | |
| 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 |
| year | Yes | Birth year between 100 and 2100. Used to calculate the Life Path number via Pythagorean reduction. | |
| month | Yes | Birth month (1 to 12) | |
| 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. | |
| fullName | Yes | Full birth name as it appears on the birth certificate, first, middle and last names separated by spaces. Used to calculate the Expression, Soul Urge and Personality numbers. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. |
| Name | Required | Description |
|---|---|---|
| expressionSoulUrge | Yes | |
| lifePathExpression | Yes | |
| soulUrgePersonality | Yes | |
| expressionPersonality | Yes |
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 genuine behavioral context beyond that: the output range (0 to 8), the meaning of 0 (already in harmony), and that each bridge ships with gap-closing guidance in the selected language. It stops short of describing execution or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with the verb and the concrete bridge enumeration, which is the most useful information. The trailing sentence about target audiences ('personal development, coaching and personality analysis tools and AI agents') is soft filler that does not earn its place, costing it a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return shape needn't be explained, and annotations cover safety; the description fills the remaining gap by defining the bridge concept and its range. It is nearly complete, though a note on input constraints (e.g. name transliteration) delegated entirely to the schema would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 six parameters thoroughly (including lang's BCP 47 enum and fullName's transliteration rules). The description only gestures at 'full birth name and birth date' and references lang, adding little beyond the structured data. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Calculate') and resource ('numerology Bridge numbers') and enumerates the exact four bridges produced (Life Path/Expression, Expression/Soul Urge, Soul Urge/Personality, Expression/Personality). This clearly distinguishes it from sibling tools like post_numerology_life_path or post_numerology_expression, which compute the individual core numbers rather than the distances between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies context ('Built for personal development, coaching and personality analysis tools') but never states when to choose this tool over the many sibling core-number tools, nor any exclusions or prerequisites. Usage is only implied, so it sits at the minimum-viable tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a business or brand name with Chaldean numerology, the system practitioners use for trade names. The name is read word by word, and the response returns the compound number and root with every step, the planetary ruler, a business rating, the industries the number favors, whether the compound is one of the fortunate compounds Cheiro names, and guidance, in the language set by lang. The roots 1, 3, 5 and 6 rate excellent, 2 and 9 good, 7 and 8 caution and 4 avoid. Built for naming tools, brand agencies and founder apps; the rating is positioning guidance, not a guarantee.
| 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 |
| name | Yes | The business or brand name to evaluate. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| root | Yes | |
| total | Yes | |
| planet | Yes | |
| rating | Yes | |
| summary | Yes | |
| compound | Yes | |
| guidance | Yes | |
| industries | Yes | |
| calculation | Yes | |
| compoundMeaning | Yes | |
| favorableCompound | Yes |
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 real context beyond that: the exact fields returned (compound number, root, planetary ruler, rating, favored industries, fortunate-compound flag, guidance), the language behavior, and the rating semantics (1/3/5/6 excellent, 4 avoid). It stops short of pagination or rate-limit details, which are not needed for a read-only calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the core operation and then layers on output contents and rating semantics, and every sentence carries information. It is on the long side for a single-parameter calculator, but there is little outright filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, yet the description still supplies the interpretive layer (what the rating numbers mean, the fortune classification) that schema data alone cannot convey. Nothing an agent needs to invoke it correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so name, lang, and compact are all documented in the schema itself, and the description does not add syntax or format detail beyond what is there. Its only parameter-level contribution is confirming that 'lang' governs the guidance text, which the schema already states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (analyze) and resource (business/brand name) and names the Chaldean system explicitly, which distinguishes it from generic siblings like post_numerology_chaldean and get_numerology_compound_number. An agent can tell what this tool computes and for what input without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the audience ('naming tools, brand agencies and founder apps') and the domain ('the system practitioners use for trade names'), which implies when it applies, but it never states when to prefer this over post_numerology_chaldean or any sibling. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a complete Chaldean numerology reading for a name, following Cheiro. The Destiny or name number, the Soul Urge from the vowels and the Personality from the consonants each come with the compound number from 10 to 52, the single-digit root and the classical compound interpretation, and a longer name is read name by name with every step shown in its calculation. The response adds the planetary ruler and meaning of the Destiny root, a caution flag for the roots 4 and 8, and a summary, in the language set by lang. Built for Chaldean numerology calculators, name analysis tools and AI agents.
| 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 |
| name | Yes | The name to analyze. Chaldean tradition uses the name a person is most known by, not necessarily the full legal birth name. It needs at least one vowel (A, E, I, O, U) and one consonant, since the Soul Urge is read from the vowels and the Personality from the consonants; Y counts as a consonant. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| caution | Yes | |
| destiny | Yes | |
| summary | Yes | |
| soulUrge | Yes | |
| personality | Yes | |
| numberMeaning | Yes |
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 nonetheless adds real behavioral context: the compound range 10-52, name-by-name reading with each step shown, a caution flag for roots 4 and 8, script-to-Latin normalisation, and language-dependent output. It does not describe latency, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The verb-and-resource lead is front-loaded and the output inventory is packed efficiently into two sentences. The closing 'Built for Chaldean numerology calculators, name analysis tools and AI agents' is audience marketing that does not help an agent decide or call, so it is not fully waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate returns, yet it summarizes the reading's contents and its language dependence, and the 100%-covered schema handles parameters. The only meaningful gap is guidance on choosing this tool over the overlapping single-aspect siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are fully documented in the schema (including the detailed name-script rules and compact columnar shape). The description adds only a light restatement via 'in the language set by lang', so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Calculate) and resource (complete Chaldean numerology reading for a name), and the Cheiro/Chaldean qualifier differentiates it from the many Pythagorean-style siblings like post_numerology_soul_urge and post_numerology_personality. It stops short of naming an alternative, so an agent must infer sibling routing from the tradition label alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the scope: this is the complete-reading tool, useful when the whole Destiny/Soul Urge/Personality bundle is wanted. There is no explicit when-to-use, no when-not-to-use, and no pointer to the narrower single-aspect siblings that produce overlapping values, leaving the selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete numerology chart from a full birth name and birth date in one call. It returns the six core numbers (Life Path, Expression, Soul Urge, Personality, Birth Day and Maturity) with their calculations and full interpretations, the four Pinnacles and four Challenges with their ages, Karmic Lessons, karmic debt in all five positions, Hidden Passion, Subconscious Self, Cornerstone, Capstone and First Vowel, the Birth Day profile for the exact day, lucky associations, the Maturity activation status, the Personal Year with the current Personal Month, and a written summary, in the language set by lang. The Personal Year uses currentYear or the current UTC year, while the Personal Month and the age behind the Maturity status read the current UTC date. Built for full numerology readings, PDF reports, onboarding profiles and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day (1-31) | |
| 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 |
| year | Yes | Birth year between 100 and 2100. Supports historical figures like Einstein (1879) and Shakespeare (1564). | |
| month | Yes | Birth month (1-12) | |
| 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. | |
| fullName | Yes | Full birth name as it appears on the birth certificate. Used for every letter-based number in the chart: Expression, Soul Urge, Personality, Karmic Lessons, Hidden Passion, Subconscious Self and the special letters. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. | |
| currentYear | No | Calendar year for the Personal Year, defaults to the current UTC year. It moves the Personal Year only: the nested personalMonth and maturityStatus.currentAge always read the current UTC date. |
| Name | Required | Description |
|---|---|---|
| profile | Yes | |
| summary | Yes | |
| coreNumbers | Yes | |
| maturityStatus | Yes | |
| birthDayProfile | No | |
| luckyAssociations | No | |
| additionalInsights | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/destructiveHint, so the description must carry the rest, and it does add real behavioral facts: date-dependency (Personal Year from currentYear or UTC year; Personal Month and Maturity age from the current UTC date) and language fallback to English when a translation is missing. It does not cover response size, latency, or error behavior, so it falls short of the top mark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the middle sentence is a very long enumeration of every returned field (six core numbers, Pinnacles, Challenges, Karmic Lessons, Hidden Passion, etc.), which an output schema already covers. That bulk is redundant for tool selection and dilutes the actionable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an aggregate chart-generation tool with a full output schema, the description covers inputs, scope, date handling, and language behavior well enough that an agent could invoke it correctly without opening the schema. Nothing essential for calling it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 every parameter, including lang fallback, currentYear semantics, and fullName script handling. The description largely restates these ('in the language set by lang', the currentYear/UTC behavior), adding marginal meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a complete numerology chart from a full birth name and birth date in one call') and the word 'complete' implicitly separates it from the single-number siblings like post_numerology_life_path or post_numerology_expression. An agent can tell this is the aggregate 'everything at once' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names intended scenarios ('full numerology readings, PDF reports, onboarding profiles and AI agents') and 'in one call' hints at the tradeoff versus the many single-number siblings. However, it never explicitly says to prefer this over the individual number tools when the whole chart is needed, so the routing decision is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate numerology compatibility between two people from their Life Path, Expression and Soul Urge numbers. Send each person as a full birth name with a birth date, or as precomputed numbers, and mix the two modes freely across the pair. The response returns an overall score from 50 to 100 with its rating, a score and description for each number pair, and the strengths, challenges and advice for the relationship, in the language set by lang. Built for dating apps, matchmaking, relationship coaching and AI companions.
| 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 |
| Name | Required | Description |
|---|---|---|
| advice | Yes | |
| rating | Yes | |
| lifePath | Yes | |
| soulUrge | Yes | |
| strengths | Yes | |
| challenges | Yes | |
| expression | Yes | |
| overallScore | Yes |
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 side-effect-free computation. The description adds the score range (50-100), the rating, per-pair breakdown and strengths/challenges/advice, but much of that overlaps the output schema and no limits, latency, or failure modes are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core computation before input modes and output shape. The trailing audience sentence ('Built for dating apps, matchmaking...') is mild positioning filler but still aids routing, so only minor trimming is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be re-explained, annotations cover the safety profile, and the description covers input modes, mixing behavior, scoring range and language handling for a nested two-object parameter set. The unmentioned compact flag is the only real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema description coverage, the description compensates by mapping the input modes directly to parameters: name-based input yields Expression and Soul Urge, birth-date input yields Life Path, and the two can be mixed per person. It also confirms lang controls output language, though the compact parameter is never addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate numerology compatibility between two people') and names the exact inputs (Life Path, Expression, Soul Urge). This is clearly distinguishable from the single-number siblings like post_numerology_life_path or post_numerology_chart, since compatibility is a pairwise operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two invocation modes ('full birth name with a birth date, or as precomputed numbers, and mix the two modes freely'), which is useful input guidance, and lists target audiences. However, it never states when to choose this tool over alternatives such as post_numerology_dual or the individual-number endpoints, so alternative selection is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the numerology Number of the Day, one of 1 to 9, 11, 22 or 33, with its full interpretation. The same seed returns the same number for the same date, so a user keeps one number all day, and the date defaults to today in UTC. The response returns the number, its type, a daily message and the archetype, keywords, strengths, challenges, career, relationships and spirituality reading in the language set by lang. Built for Number of the Day widgets, push notifications and daily content.
| 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 number 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. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| seed | Yes | |
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| dailyMessage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds real behavioral value: identical seed+date is deterministic, date defaults to today in UTC, and missing translations fall back to English.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the resource and its value domain before moving to determinism and use cases. No filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and return values need not be restated, the description's summary of the returned reading fields and the language fallback rule make the daily-determination behavior fully unambiguous. Nothing needed to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 date, lang, seed and compact in detail. The description restates the seed/determinism and lang-language behavior but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get the numerology Number of the Day") and pins the domain values (1-9, 11, 22, 33), which separates it from siblings like post_numerology_personal_day or post_numerology_life_path. An agent can identify the target tool without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context ("Built for Number of the Day widgets, push notifications and daily content") and explains the daily-seed determinism and UTC default. It does not explicitly name when to prefer a sibling such as post_numerology_personal_day, so routing still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a name number in both Pythagorean and Chaldean numerology in one call and compare them. The Pythagorean side returns the Expression or Destiny number with master numbers 11, 22 and 33 kept; the Chaldean side returns the compound number from 10 to 52, the root, its planetary ruler and the compound interpretation; each shows its calculation name by name. An agreement flag and a plain-language note show whether the two systems point to the same single-digit energy, in the language set by lang. Built for system comparison tools, name analysis features and AI agents.
| 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 |
| name | Yes | The name to analyze in both systems. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| note | Yes | |
| chaldean | Yes | |
| agreement | Yes | |
| pythagorean | Yes |
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 real behavioral detail (master numbers 11/22/33 preserved, Chaldean compound range 10-52, agreement-flag semantics), but much of it restates return content that the output schema already provides, and it says nothing about rate limits, cost, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, which is good, but the body is one long run-on sentence packing system-by-system return details, flag semantics and audience notes. It is informative yet dense, with lower-value tail content ('Built for system comparison tools... AI agents') that does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what is computed in each system and how the two are reconciled, and an output schema exists to carry return structure details. The only meaningful gap is routing guidance against the 20 sibling numerology tools, which is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 name, lang and compact thoroughly. The description only echoes the lang behavior ('in the language set by lang') without adding syntax, constraints, or edge cases beyond what the schema states, which is the expected baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Calculate a name number') plus a specific resource and scope ('in both Pythagorean and Chaldean numerology in one call and compare them'). This clearly distinguishes it from single-system siblings such as post_numerology_chaldean and post_numerology_expression without requiring the schema to be opened.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the dual-system framing ('compare them') and a target-audience line about system comparison tools, but there is no explicit when-to-use/when-not rule and no named alternative (e.g. use post_numerology_chaldean for Chaldean alone). An agent can infer the case, but must infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Expression number, also called the Destiny number, from a full birth name with Pythagorean numerology. Every letter is valued and the name is reduced name by name, with master numbers 11, 22 and 33 kept and a karmic debt of 13, 14, 16 or 19 flagged with its meaning. The response lists every letter value and returns a full interpretation of natural talents, career, relationships and spiritual path in the language set by lang. Built for name numerology apps, career and personal brand tools, and AI agents.
| 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. | |
| fullName | Yes | Full birth name (first, middle, last). A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| calculation | Yes | |
| hasKarmicDebt | Yes | |
| karmicDebtNumber | No | |
| karmicDebtMeaning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive), so the bar is lower. The description adds real behavioral detail: master numbers 11/22/33 retained, karmic debt 13/14/16/19 flagged with meaning, letter-by-letter output, and name-by-name reduction. It doesn't mention rate limits or error cases, but discloses the processing rules an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core calculation before behavioral details and audience. Efficient and well-ordered, though the closing 'Built for...' sentence is arguably marketing filler rather than agent-usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and the description's disclosure of master numbers, karmic debt, and letter-level output is sufficient. The missing usage-guidance against 19 siblings is the main gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all three parameters including lang enum, compact flag semantics, and fullName script-handling rules. The description adds only that lang controls the interpretation language, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Calculate) and resource (Expression/Destiny number) with the exact method (Pythagorean, from full birth name). This distinguishes it from siblings like post_numerology_life_path, post_numerology_soul_urge, and post_numerology_chaldean (a different system).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Built for name numerology apps, career and personal brand tools') but never states when to use this tool versus alternatives. With ~20 siblings covering different numerology calculations, no explicit routing guidance is a clear gap, though the calculation basis (full birth name) implicitly differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect Karmic Debt numbers 13, 14, 16 and 19 across the five core numbers that carry them: Life Path, Expression, Soul Urge, Personality and Birth Day. Send a birth date, a full birth name, or both, and only the positions those inputs reach are read; each debt is listed once with its challenge and resolution guidance in the language set by lang. Built for spiritual growth apps, karmic readings, coaching tools and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | Birth day (checks Birth Day on its own, and Life Path with year and month) | |
| 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 |
| year | No | Birth year (checks Life Path) | |
| month | No | Birth month (checks Life Path) | |
| 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. | |
| fullName | No | Full birth name (checks Expression, Soul Urge, Personality). A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. |
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| meanings | Yes | |
| debtNumbers | Yes | |
| hasKarmicDebt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds meaningful behavior beyond that, namely that only the positions reachable from the supplied inputs are evaluated, that each debt is reported once, and that each carries challenge and resolution guidance. It does not discuss rate limits or auth, but for a safe read-only endpoint this is solid added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the detection scope and followed by input behavior and return content. The closing 'Built for spiritual growth apps, karmic readings, coaching tools and AI agents' is audience marketing that does not help an agent invoke the tool, which keeps it out of 5 territory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover the safety profile, so the description does not need to document return shapes; it still usefully explains the partial-input evaluation rule and per-debt guidance content. Nothing essential is missing, though it omits any note on how results behave when no debt is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter docs are unusually thorough (each field already states which numerological positions it triggers, plus the lang fallback-to-English rule), so the description's note that inputs may be combined adds little that the schema does not already say. Baseline 3 is appropriate when the schema carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Detect) and a precise resource (Karmic Debt numbers 13, 14, 16, 19) scoped to five named core numbers. This distinguishes it cleanly from siblings such as post_numerology_karmic_lessons and the single-position tools without requiring the schema to be opened.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear invocation context: 'Send a birth date, a full birth name, or both, and only the positions those inputs reach are read,' which tells the agent both what to supply and that partial inputs are legal (consistent with zero required params). It never names an alternative tool or states when not to use this one, 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.
Analyze the Karmic Lessons of a full birth name with Pythagorean numerology: the numbers 1 to 9 that no letter of the name carries. Each missing number is returned with its lesson, a fuller explanation and practical guidance for developing it, in the language set by lang, beside the count of letters behind every number present. Built for spiritual growth apps, coaching tools, full numerology reports and AI agents.
| 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. | |
| fullName | Yes | Full birth name to analyze for missing numbers. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. |
| Name | Required | Description |
|---|---|---|
| lessons | Yes | |
| missingNumbers | Yes | |
| presentNumbers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already covering the safety profile, the description still adds value by disclosing the return content (each missing number with lesson, explanation and practical guidance, plus letter counts for present numbers) and the language-fallback behavior. It stops short of describing response shape or any limits, but the annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool's actual behavior is front-loaded in the first sentence, and the second sentence is short. The closing audience list ('built for...') is mildly promotional and the least load-bearing part, but overall it is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values need not be explained since an output schema exists, and all three parameters are fully documented by the schema. The description covers purpose, inputs and outputs adequately for a read-only, non-parameter-heavy analysis tool; only explicit sibling disambiguation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents lang, compact and fullName. The description only restates that language comes from lang and has to compensate for nothing; it adds no syntax, format or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (analyze Karmic Lessons of a full birth name) and defines the scope precisely: 'the numbers 1 to 9 that no letter of the name carries.' This is enough to distinguish it conceptually from siblings, though it never explicitly contrasts with the nearby post_numerology_karmic_debt, leaving a small risk of confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the audience list ('spiritual growth apps, coaching tools, full numerology reports and AI agents'), which describes who consumes it rather than when an agent should pick this tool over an alternative like karmic_debt. No exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a Life Path number from a birth date with Pythagorean numerology. The Life Path is the core number of a numerology chart, read from the birth year, month and day alone, with master numbers 11, 22 and 33 kept and a karmic debt of 13, 14, 16 or 19 flagged with its meaning. The response returns every reduction step and a full interpretation (archetype title, keywords, description, strengths, challenges, career, relationships and spirituality) in the language set by lang. Built for Life Path calculators, numerology apps, onboarding personality profiles and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day (1-31) | |
| 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 |
| year | Yes | Birth year between 100 and 2100. Supports historical figures like Einstein (1879) and Shakespeare (1564). | |
| month | Yes | Birth month (1-12) | |
| 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. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| calculation | Yes | |
| hasKarmicDebt | Yes | |
| karmicDebtNumber | No | |
| karmicDebtMeaning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), and the description adds genuine behavioral detail beyond them: master numbers 11/22/33 are kept, karmic debt of 13/14/16/19 is flagged, and every reduction step plus a full interpretation is returned in the lang-specified language.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose and scope before capabilities and audience; no wasted clauses, though the trailing audience list is mildly promotional rather than operational.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a 100%-covered schema, safety annotations and an output schema, nothing needed to call the tool is missing; the description supplies the remaining semantic context (derivation rule, master/karmic handling, localization) an agent needs to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 day/month/year ranges, lang options and the compact columnar shape; the description adds no syntax or format detail beyond that, making baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Calculate') and resource ('Life Path number') and pins the exact inputs ('read from the birth year, month and day alone'), which cleanly separates it from siblings like post_numerology_birth_day, post_numerology_expression or post_numerology_soul_urge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives intended contexts (calculators, numerology apps, onboarding profiles) and the derivation rule, but never names an alternative or states when *not* to use it, so routing against the ~19 sibling numerology tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Maturity number, also called the Realization number, from the Life Path and Expression numbers with Pythagorean numerology. Send a full birth name and birth date, the two numbers precomputed, or one of each; master numbers 11, 22 and 33 are kept at full value and in the result. The Maturity number describes who a person grows into in the second half of life, usually felt from around 35 to 40, and the response returns the calculation and a full interpretation in the language set by lang. Built for life coaching apps, midlife and later-life guidance, and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | Birth day (1-31). Required with year and month for automatic Life Path calculation. | |
| 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 |
| year | No | Birth year to calculate Life Path automatically. Use with month and day instead of passing lifePath directly. | |
| month | No | Birth month (1-12). Required with year and day for automatic Life Path calculation. | |
| 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. | |
| fullName | No | Full birth name to calculate the Expression number automatically. Use instead of passing expression directly. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. | |
| lifePath | No | Your Life Path number (1-9, 11, 22, 33). Optional if year, month, day are provided. | |
| expression | No | Your Expression number (1-9, 11, 22, 33). Optional if fullName is provided. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| calculation | Yes | |
| hasKarmicDebt | Yes | |
| karmicDebtNumber | No | |
| karmicDebtMeaning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish this is a safe read-only operation, and the description adds real behavioral context on top: master numbers 11/22/33 are preserved at full value, the calculation lists the letters counted, non-Latin scripts are transliterated, and untranslated fields fall back to English. The only minor gap is no mention of what happens with insufficient input (all params optional).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core computation, input modes, and output are front-loaded, which is good structure. The trailing audience sentence ('Built for life coaching apps, midlife and later-life guidance, and AI agents') adds little for an agent deciding how to call the tool and is the one piece of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, yet it still notes the response includes the calculation plus a full interpretation in lang. Inputs, language fallback, and edge behavior are covered; the only unaddressed case is the minimum required input combination given that no parameters are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuinely useful meaning about how the optional parameters combine (name+date, precomputed numbers, or a mix) and how lang affects the returned interpretation. That flexibility across zero required params is not fully obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Calculate the Maturity number, also called the Realization number') and names the exact inputs it derives from (Life Path and Expression). This differentiates it cleanly from siblings like post_numerology_life_path or post_numerology_expression, which compute those inputs separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly lays out the acceptable input modes ('full birth name and birth date, the two numbers precomputed, or one of each'), which is the actionable guidance an agent needs to invoke it. It does not, however, explicitly say when to prefer this over sibling chart/dual tools or name alternatives, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Personal Day number from a birth month and day with Pythagorean numerology, the 1 to 9 theme of a single calendar day personalized to the birthday. The day is targetDate, or today in UTC when omitted. The response returns the day theme and guidance with the parent Personal Month and Personal Year, in the language set by lang. Built for daily push notifications, morning briefings, calendar widgets and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day (1-31) | |
| 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 |
| month | Yes | Birth month (1-12) | |
| 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. | |
| targetDate | No | Target date in YYYY-MM-DD format, in the years 100 to 2100. Defaults to today (UTC). |
| Name | Required | Description |
|---|---|---|
| theme | Yes | |
| guidance | Yes | |
| targetDate | Yes | |
| personalDay | Yes | |
| personalYear | Yes | |
| personalMonth | Yes | |
| personalYearTheme | Yes | |
| personalMonthTheme | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so it is clear this is a safe read. The description adds useful behavior beyond that: targetDate defaults to today in UTC, and the response bundles the day theme with the parent Personal Month and Personal Year. Errors, rate limits, and failure modes remain unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then mechanics (default date, response contents), then use cases. No sentence is wasted and it never buries the lead. Slightly long, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% schema coverage, the description needn't explain return values, yet it usefully summarizes the response shape. For a 5-parameter read-only calculation tool this is essentially complete, missing only edge-case or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so defaults, ranges, and the lang enum are already fully documented in the schema. The description restates the targetDate default (today UTC) and the lang-driven output language, which is consistent but adds little beyond structured fields, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Calculate') and resource ('Personal Day number'), plus the exact inputs (birth month/day) and the personality of the output (1-9 theme of a calendar day). It is distinguishable from siblings like personal_month, personal_year, and daily that could otherwise be confused with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Built for daily push notifications, morning briefings, calendar widgets and AI agents' clause gives real deployment context, implying when this tool fits. However, it never names the adjacent siblings (personal_month, personal_year, daily) or states when NOT to use this tool, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Personality number from the consonants of a full birth name with Pythagorean numerology. Every letter other than A, E, I, O and U is a consonant, Y and W included; master numbers 11, 22 and 33 are kept and a karmic debt of 13, 14, 16 or 19 is flagged with its meaning. The response lists every consonant name by name and returns a full interpretation of first impressions, public image, career and relationships in the language set by lang. Built for personal branding apps, social and dating profiles, coaching tools and AI agents.
| 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. | |
| fullName | Yes | Full birth name. Its consonants give the Personality number, so a name with none is refused. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| calculation | Yes | |
| hasKarmicDebt | Yes | |
| karmicDebtNumber | No | |
| karmicDebtMeaning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive), so the description is free to add real behavior: master numbers 11/22/33 preserved, karmic debt of 13/14/16/19 flagged with meaning, consonant list returned, and a name with no consonants refused. These are non-obvious traits beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the calculation rule, and the behavioral details (master numbers, karmic debt, script folding) are crammed densely but usefully into the first two sentences. The closing marketing sentence about target apps is the only padding, keeping this just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values, yet it still previews the interpretation scope and language behavior, which is helpful. All inputs are covered and the refusal condition is stated, so an agent has what it needs to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lang, compact and fullName thoroughly. The description only echoes the lang linkage and the consonant dependence of fullName, adding no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Calculate) and resource (Personality number) plus the exact input basis (consonants of a full birth name) and the system (Pythagorean). This distinguishes it from vowel-based siblings like soul_urge and all-letter tools like expression without the agent opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It defines the letter rule (everything but A,E,I,O,U, Y and W included) and lists target audiences, which implies when it is appropriate, but it never names an alternative sibling or states an exclusion condition. Usage is inferable from the vowel/consonant split rather than made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Personal Month number from a birth month and day with Pythagorean numerology, the 1 to 9 theme of one calendar month inside the Personal Year. The year and month are the ones sent, each defaulting to the current UTC year and month when omitted. The response returns the month theme, practical focus and the parent Personal Year with its theme, in the language set by lang. Built for monthly forecast features, push notifications, editorial columns and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day (1-31) | |
| 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 |
| year | No | Target year. Defaults to the current UTC year. | |
| month | Yes | Birth month (1-12) | |
| 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. | |
| targetMonth | No | Target calendar month to forecast (1 to 12). Defaults to the current UTC month. |
| Name | Required | Description |
|---|---|---|
| focus | Yes | |
| theme | Yes | |
| personalYear | Yes | |
| calendarMonth | Yes | |
| personalMonth | Yes | |
| personalYearTheme | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already covering safety, the description adds real context: year/month default to the current UTC year/month when omitted, the response returns month theme, practical focus and the parent Personal Year, and lang controls output language. It does not mention rate limits or caching, but the added behavioral detail is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four front-loaded sentences covering definition, defaults, response contents and audience; the definition leads and nothing is padding, though the closing audience list is the weakest-earning sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only calculation tool with a full output schema and 100% schema coverage, the description supplies the extra defaults, output shape and language-fallback behavior an agent needs. Sibling differentiation and target-vs-birth month disambiguation are the remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 clarifies that year/month default to current UTC and that lang sets the response language, but it does not resolve the potential confusion between the required birth 'month' and the 'targetMonth' forecast parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Calculate) and resource (Personal Month number) with the algorithm (Pythagorean) and the exact output contents (1 to 9 theme of a calendar month inside the Personal Year). It naturally distinguishes itself from siblings like post_numerology_personal_day and post_numerology_personal_year by naming the parent Personal Year relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers use-case framing ('monthly forecast features, push notifications, editorial columns and AI agents') but never states when to choose this over personal_day or personal_year, nor any prerequisite or exclusion. Usage is implied by the theme, not routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Personal Year number from a birth month and day with Pythagorean numerology, the 1 to 9 cycle that sets the theme of a calendar year. The year is the one sent, or the current UTC year when omitted, and it turns over on 1 January; the birth year is not needed. The response returns the place in the nine-year cycle, the theme, a forecast, opportunities, challenges and advice in the language set by lang. Built for yearly planning features, New Year content, coaching tools and AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day (1-31) | |
| 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 |
| year | No | Year to forecast. Defaults to the current UTC year; the Personal Year turns over on 1 January. | |
| month | Yes | Birth month (1-12) | |
| 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. |
| Name | Required | Description |
|---|---|---|
| cycle | Yes | |
| theme | Yes | |
| advice | Yes | |
| forecast | Yes | |
| challenges | Yes | |
| personalYear | Yes | |
| opportunities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read-only, non-destructive operation, and the description adds genuinely useful behavior beyond them: the year defaults to the current UTC year, the cycle turns over on 1 January, and the birth year is not required. It stops short of describing any limits or edge cases, but the added context is solid for a read-only calculation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the calculation and cycle definition, then defaults, then output, then audience. It is slightly padded by the closing marketing sentence ('Built for yearly planning features...') which adds little operational value, but overall the structure is disciplined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full schema and an output schema present, the description need not enumerate return fields, yet it does outline theme, forecast, opportunities, challenges and advice, which orients the agent ahead of the structured response. The only real gap is the lack of disambiguation from the sibling month/day tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema carries the baseline burden, and the description adds real meaning on top: it clarifies the year default and turnover semantics and explicitly notes that no birth year is needed. The enums and compact/lossless shape are left to the schema, which is the right place for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate the Personal Year number from a birth month and day') and scopes it to a 1-9 annual cycle, so the agent knows exactly what is computed. It does not, however, differentiate itself from the very close siblings post_numerology_personal_month and post_numerology_personal_day, leaving the agent to infer the scope boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through audience framing ('yearly planning features, New Year content, coaching tools'), which hints at context but never states when to choose this over personal_month/personal_day or what inputs are disallowed. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Soul Urge number, also called the Heart Desire number, from the vowels of a full birth name with Pythagorean numerology. A, E, I, O and U are the vowels and Y and W count as consonants; master numbers 11, 22 and 33 are kept and a karmic debt of 13, 14, 16 or 19 is flagged with its meaning. The response lists every vowel name by name and returns a full interpretation of inner motivation, relationships and spiritual path in the language set by lang. Built for self-discovery apps, dating profiles, coaching tools and AI agents.
| 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. | |
| fullName | Yes | Full birth name. Its vowels A, E, I, O and U give the Soul Urge, so a name with none is refused. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| number | Yes | |
| meaning | Yes | |
| calculation | Yes | |
| hasKarmicDebt | Yes | |
| karmicDebtNumber | No | |
| karmicDebtMeaning | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnlyHint/destructiveHint annotations: it discloses vowel treatment (A/E/I/O/U vowels, Y and W as consonants), preservation of master numbers 11/22/33, karmic-debt flagging for 13/14/16/19, per-vowel output, and a full interpretation return. For a stateless calculator this is rich, decision-relevant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core calculation and rules, and the operative details come early. The closing sentence enumerating target audiences is mild marketing filler that does not help an agent decide or invoke, keeping it short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't detail return values, and it still sketches them (per-vowel listing, interpretation). It covers the input contract and edge case (a name with no vowels is refused, mirrored in the schema) but omits language fallback behavior and the compact toggle, which the schema does carry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so fullName, lang and compact are already documented in the schema. The description restates the vowel rule for fullName and mentions lang only in passing ('the language set by lang') without adding new semantics, and never touches compact — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — calculating the Soul Urge / Heart Desire number — and pins down the exact input basis: the vowels of a full birth name under Pythagorean numerology. That vowel basis implicitly distinguishes it from consonant-based (personality) and full-name (expression) siblings without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an audience framing (self-discovery apps, dating profiles, coaching tools, AI agents) but never states when to pick this tool over the many sibling numerology endpoints, nor any exclusion. Usage is inferable from the scope of the calculation but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
post_numerology_bridge3 fields changedInput schema / properties / fullName / descriptionPrevious value: -"Full legal birth name as it appears on the birth certificate. Used to calculate Expression, Soul Urge, and Personality numbers. Include first, middle, and last names separated by spaces."New value: +"Full birth name as it appears on the birth certificate, first, middle and last names separated by spaces. Used to calculate the Expression, Soul Urge and Personality numbers. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."Output schema / properties / soulUrgePersonalityAdded value: +{
+ "properties": {
+ "bridge": {
+ "maximum": 8,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "from": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "to": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "bridge",
+ "from",
+ "to",
+ "meaning"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "lifePathExpression",
- "expressionPersonality",
- "expressionSoulUrge"
-]New value: +[
+ "lifePathExpression",
+ "expressionPersonality",
+ "soulUrgePersonality",
+ "expressionSoulUrge"
+]post_numerology_business_name1 field changedInput schema / properties / name / descriptionPrevious value: -"The business or brand name to evaluate."New value: +"The business or brand name to evaluate. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_chaldean1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to analyze. Chaldean tradition uses the name a person is most known by, not necessarily the full legal birth name."New value: +"The name to analyze. Chaldean tradition uses the name a person is most known by, not necessarily the full legal birth name. It needs at least one vowel (A, E, I, O, U) and one consonant, since the Soul Urge is read from the vowels and the Personality from the consonants; Y counts as a consonant. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_chart2 fields changedInput schema / properties / currentYear / descriptionPrevious value: -"Year for Personal Year calculation (defaults to current year)"New value: +"Calendar year for the Personal Year, defaults to the current UTC year. It moves the Personal Year only: the nested personalMonth and maturityStatus.currentAge always read the current UTC date."Input schema / properties / fullName / descriptionPrevious value: -"Full birth name as it appears on the birth certificate. Used for all letter-based Pythagorean numerology calculations including Expression, Soul Urge, Personality, and Karmic Lessons."New value: +"Full birth name as it appears on the birth certificate. Used for every letter-based number in the chart: Expression, Soul Urge, Personality, Karmic Lessons, Hidden Passion, Subconscious Self and the special letters. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_dual1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to analyze in both systems."New value: +"The name to analyze in both systems. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_expression1 field changedInput schema / properties / fullName / descriptionPrevious value: -"Full birth name (first, middle, last)"New value: +"Full birth name (first, middle, last). A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_karmic_debt1 field changedInput schema / properties / fullName / descriptionPrevious value: -"Full birth name (checks Expression, Soul Urge, Personality)"New value: +"Full birth name (checks Expression, Soul Urge, Personality). A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_karmic_lessons1 field changedInput schema / properties / fullName / descriptionPrevious value: -"Full birth name to analyze for missing numbers"New value: +"Full birth name to analyze for missing numbers. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_maturity1 field changedInput schema / properties / fullName / descriptionPrevious value: -"Full birth name to calculate Expression number automatically. Use instead of passing expression directly."New value: +"Full birth name to calculate the Expression number automatically. Use instead of passing expression directly. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_personal_day1 field changedInput schema / properties / targetDate / descriptionPrevious value: -"Target date in YYYY-MM-DD format. Defaults to today (UTC)."New value: +"Target date in YYYY-MM-DD format, in the years 100 to 2100. Defaults to today (UTC)."post_numerology_personal_month2 fields changedInput schema / properties / targetMonth / descriptionPrevious value: -"Target calendar month to forecast (1-12, defaults to current month)"New value: +"Target calendar month to forecast (1 to 12). Defaults to the current UTC month."Input schema / properties / year / descriptionPrevious value: -"Target year for calculation (defaults to current year)"New value: +"Target year. Defaults to the current UTC year."post_numerology_personal_year1 field changedInput schema / properties / year / descriptionPrevious value: -"Year to calculate (defaults to current year)"New value: +"Year to forecast. Defaults to the current UTC year; the Personal Year turns over on 1 January."post_numerology_personality1 field changedInput schema / properties / fullName / descriptionPrevious value: -"Full birth name (consonants will be extracted)"New value: +"Full birth name. Its consonants give the Personality number, so a name with none is refused. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_soul_urge1 field changedInput schema / properties / fullName / descriptionPrevious value: -"Full birth name (vowels will be extracted)"New value: +"Full birth name. Its vowels A, E, I, O and U give the Soul Urge, so a name with none is refused. A name in any script is converted to Latin letters before it is counted, Cyrillic and Greek as the passport spelling and accents folded to the base letter, and the calculation lists the letters counted. For a script that does not write its vowels, send the Latin spelling the person uses."post_numerology_karmic_debt1 field changedInput schema / properties / day / descriptionPrevious value: -"Birth day (checks Life Path)"New value: +"Birth day (checks Birth Day on its own, and Life Path with year and month)"post_numerology_chart1 field changedInput schema / properties / currentYear / minimumPrevious value: -2020New value: +100post_numerology_personal_month1 field changedInput schema / properties / year / minimumPrevious value: -2020New value: +100post_numerology_personal_year1 field changedInput schema / properties / year / minimumPrevious value: -2020New value: +100get_numerology_compound_number1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nature": {
+ "enum": [
+ "fortunate",
+ "unfortunate",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "root": {
+ "type": "number"
+ },
+ "sameAs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "nature",
+ "meaning",
+ "root"
+ ],
+ "type": "object"
+}get_numerology_meanings_number1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "type",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_birth_day1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtMeaning": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_bridge1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "expressionPersonality": {
+ "properties": {
+ "bridge": {
+ "maximum": 8,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "from": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "to": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "bridge",
+ "from",
+ "to",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "expressionSoulUrge": {
+ "properties": {
+ "bridge": {
+ "maximum": 8,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "from": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "to": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "bridge",
+ "from",
+ "to",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "lifePathExpression": {
+ "properties": {
+ "bridge": {
+ "maximum": 8,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "from": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "to": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "number"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "bridge",
+ "from",
+ "to",
+ "meaning"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "lifePathExpression",
+ "expressionPersonality",
+ "expressionSoulUrge"
+ ],
+ "type": "object"
+}post_numerology_business_name1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "compound": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "compoundMeaning": {
+ "properties": {
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nature": {
+ "enum": [
+ "fortunate",
+ "unfortunate",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "sameAs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "nature",
+ "meaning"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "favorableCompound": {
+ "type": "boolean"
+ },
+ "guidance": {
+ "type": "string"
+ },
+ "industries": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "planet": {
+ "type": "string"
+ },
+ "rating": {
+ "enum": [
+ "excellent",
+ "good",
+ "caution",
+ "avoid"
+ ],
+ "type": "string"
+ },
+ "root": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "total",
+ "compound",
+ "root",
+ "planet",
+ "rating",
+ "favorableCompound",
+ "industries",
+ "guidance",
+ "calculation",
+ "compoundMeaning",
+ "summary"
+ ],
+ "type": "object"
+}post_numerology_chaldean1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "caution": {
+ "type": "boolean"
+ },
+ "destiny": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "compound": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "compoundMeaning": {
+ "properties": {
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nature": {
+ "enum": [
+ "fortunate",
+ "unfortunate",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "sameAs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "nature",
+ "meaning"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "root": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "compound",
+ "root",
+ "calculation",
+ "compoundMeaning"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "type": "string"
+ },
+ "numberMeaning": {
+ "properties": {
+ "caution": {
+ "type": "boolean"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "planet": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "planet",
+ "title",
+ "keywords",
+ "caution",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "personality": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "compound": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "compoundMeaning": {
+ "properties": {
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nature": {
+ "enum": [
+ "fortunate",
+ "unfortunate",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "sameAs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "nature",
+ "meaning"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "root": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "compound",
+ "root",
+ "calculation",
+ "compoundMeaning"
+ ],
+ "type": "object"
+ },
+ "soulUrge": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "compound": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "compoundMeaning": {
+ "properties": {
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nature": {
+ "enum": [
+ "fortunate",
+ "unfortunate",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "sameAs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "nature",
+ "meaning"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "root": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "compound",
+ "root",
+ "calculation",
+ "compoundMeaning"
+ ],
+ "type": "object"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "destiny",
+ "soulUrge",
+ "personality",
+ "numberMeaning",
+ "caution",
+ "summary"
+ ],
+ "type": "object"
+}post_numerology_chart1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "additionalInsights": {
+ "properties": {
+ "challenges": {
+ "items": {
+ "properties": {
+ "endAge": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "meaning": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "howToOvercome": {
+ "type": "string"
+ },
+ "lesson": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "description",
+ "lesson",
+ "howToOvercome"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "position": {
+ "type": "number"
+ },
+ "startAge": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "position",
+ "number",
+ "startAge",
+ "endAge",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hiddenPassion": {
+ "properties": {
+ "allPassions": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "count",
+ "allPassions",
+ "title",
+ "description"
+ ],
+ "type": "object"
+ },
+ "karmicDebt": {
+ "properties": {
+ "debtNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "meanings": {
+ "items": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "hasKarmicDebt",
+ "debtNumbers",
+ "meanings"
+ ],
+ "type": "object"
+ },
+ "karmicLessons": {
+ "properties": {
+ "lessons": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "howToOvercome": {
+ "type": "string"
+ },
+ "lesson": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "lesson",
+ "description",
+ "howToOvercome"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "presentNumbers": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "missingNumbers",
+ "lessons",
+ "presentNumbers"
+ ],
+ "type": "object"
+ },
+ "nameLetters": {
+ "properties": {
+ "capstone": {
+ "properties": {
+ "letter": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "letter",
+ "number",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "cornerstone": {
+ "properties": {
+ "letter": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "letter",
+ "number",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "firstVowel": {
+ "properties": {
+ "letter": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "letter",
+ "meaning"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "cornerstone",
+ "capstone",
+ "firstVowel"
+ ],
+ "type": "object"
+ },
+ "personalYear": {
+ "properties": {
+ "advice": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cycle": {
+ "type": "string"
+ },
+ "forecast": {
+ "type": "string"
+ },
+ "opportunities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "personalMonth": {
+ "properties": {
+ "focus": {
+ "type": "string"
+ },
+ "personalMonth": {
+ "type": "number"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "personalMonth",
+ "theme",
+ "focus"
+ ],
+ "type": "object"
+ },
+ "personalYear": {
+ "type": "number"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "personalYear",
+ "cycle",
+ "theme",
+ "forecast",
+ "opportunities",
+ "challenges",
+ "advice",
+ "personalMonth"
+ ],
+ "type": "object"
+ },
+ "pinnacles": {
+ "items": {
+ "properties": {
+ "endAge": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "meaning": {
+ "properties": {
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "opportunities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "description",
+ "opportunities",
+ "challenges"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "position": {
+ "type": "number"
+ },
+ "startAge": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "position",
+ "number",
+ "startAge",
+ "endAge",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "subconsciousSelf": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "uniqueNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "number",
+ "uniqueNumbers",
+ "title",
+ "description"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "karmicLessons",
+ "karmicDebt",
+ "personalYear",
+ "pinnacles",
+ "challenges",
+ "hiddenPassion",
+ "subconsciousSelf",
+ "nameLetters"
+ ],
+ "type": "object"
+ },
+ "birthDayProfile": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "day": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "reducesTo": {
+ "type": "number"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "day",
+ "reducesTo",
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships"
+ ],
+ "type": "object"
+ },
+ "coreNumbers": {
+ "properties": {
+ "birthDay": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "expression": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "lifePath": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "maturity": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "personality": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "soulUrge": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "lifePath",
+ "expression",
+ "soulUrge",
+ "personality",
+ "birthDay",
+ "maturity"
+ ],
+ "type": "object"
+ },
+ "luckyAssociations": {
+ "properties": {
+ "colors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "compatibleNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "day": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "gemstones": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "incompatibleNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "rulingPlanet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "colors",
+ "gemstones",
+ "day",
+ "element",
+ "rulingPlanet",
+ "compatibleNumbers",
+ "incompatibleNumbers"
+ ],
+ "type": "object"
+ },
+ "maturityStatus": {
+ "properties": {
+ "activationRange": {
+ "type": "string"
+ },
+ "currentAge": {
+ "type": "number"
+ },
+ "isActive": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "isActive",
+ "currentAge",
+ "activationRange"
+ ],
+ "type": "object"
+ },
+ "profile": {
+ "properties": {
+ "birthdate": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "birthdate"
+ ],
+ "type": "object"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "profile",
+ "coreNumbers",
+ "additionalInsights",
+ "maturityStatus",
+ "summary"
+ ],
+ "type": "object"
+}post_numerology_compatibility1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "advice": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "expression": {
+ "properties": {
+ "compatibility": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "person1": {
+ "type": "number"
+ },
+ "person2": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "person1",
+ "person2",
+ "compatibility",
+ "description"
+ ],
+ "type": "object"
+ },
+ "lifePath": {
+ "properties": {
+ "compatibility": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "person1": {
+ "type": "number"
+ },
+ "person2": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "person1",
+ "person2",
+ "compatibility",
+ "description"
+ ],
+ "type": "object"
+ },
+ "overallScore": {
+ "type": "number"
+ },
+ "rating": {
+ "type": "string"
+ },
+ "soulUrge": {
+ "properties": {
+ "compatibility": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "person1": {
+ "type": "number"
+ },
+ "person2": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "person1",
+ "person2",
+ "compatibility",
+ "description"
+ ],
+ "type": "object"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "overallScore",
+ "rating",
+ "lifePath",
+ "expression",
+ "soulUrge",
+ "strengths",
+ "challenges",
+ "advice"
+ ],
+ "type": "object"
+}post_numerology_daily1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dailyMessage": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "seed": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "date",
+ "seed",
+ "number",
+ "type",
+ "dailyMessage",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_dual1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "agreement": {
+ "type": "boolean"
+ },
+ "chaldean": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "caution": {
+ "type": "boolean"
+ },
+ "compound": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "compoundMeaning": {
+ "properties": {
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nature": {
+ "enum": [
+ "fortunate",
+ "unfortunate",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "sameAs": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "nature",
+ "meaning"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "planet": {
+ "type": "string"
+ },
+ "root": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "compound",
+ "root",
+ "total",
+ "calculation",
+ "planet",
+ "title",
+ "caution",
+ "compoundMeaning"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "pythagorean": {
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "number": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "type",
+ "calculation",
+ "title",
+ "keywords"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "name",
+ "pythagorean",
+ "chaldean",
+ "agreement",
+ "note"
+ ],
+ "type": "object"
+}post_numerology_expression1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtMeaning": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_karmic_debt1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "debtNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "meanings": {
+ "items": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hasKarmicDebt",
+ "debtNumbers",
+ "meanings",
+ "message"
+ ],
+ "type": "object"
+}post_numerology_karmic_lessons1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "lessons": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "howToOvercome": {
+ "type": "string"
+ },
+ "lesson": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "lesson",
+ "description",
+ "howToOvercome"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "missingNumbers": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "presentNumbers": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "missingNumbers",
+ "lessons",
+ "presentNumbers"
+ ],
+ "type": "object"
+}post_numerology_life_path1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtMeaning": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_maturity1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtMeaning": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_personal_day1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "guidance": {
+ "type": "string"
+ },
+ "personalDay": {
+ "type": "number"
+ },
+ "personalMonth": {
+ "type": "number"
+ },
+ "personalMonthTheme": {
+ "type": "string"
+ },
+ "personalYear": {
+ "type": "number"
+ },
+ "personalYearTheme": {
+ "type": "string"
+ },
+ "targetDate": {
+ "type": "string"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "personalDay",
+ "theme",
+ "guidance",
+ "targetDate",
+ "personalMonth",
+ "personalMonthTheme",
+ "personalYear",
+ "personalYearTheme"
+ ],
+ "type": "object"
+}post_numerology_personal_month1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calendarMonth": {
+ "type": "number"
+ },
+ "focus": {
+ "type": "string"
+ },
+ "personalMonth": {
+ "type": "number"
+ },
+ "personalYear": {
+ "type": "number"
+ },
+ "personalYearTheme": {
+ "type": "string"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "personalMonth",
+ "theme",
+ "focus",
+ "calendarMonth",
+ "personalYear",
+ "personalYearTheme"
+ ],
+ "type": "object"
+}post_numerology_personal_year1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "advice": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cycle": {
+ "type": "string"
+ },
+ "forecast": {
+ "type": "string"
+ },
+ "opportunities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "personalYear": {
+ "type": "number"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "personalYear",
+ "cycle",
+ "theme",
+ "forecast",
+ "opportunities",
+ "challenges",
+ "advice"
+ ],
+ "type": "object"
+}post_numerology_personality1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtMeaning": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+}post_numerology_soul_urge1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "calculation": {
+ "type": "string"
+ },
+ "hasKarmicDebt": {
+ "type": "boolean"
+ },
+ "karmicDebtMeaning": {
+ "properties": {
+ "challenge": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "resolution": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "description",
+ "challenge",
+ "resolution"
+ ],
+ "type": "object"
+ },
+ "karmicDebtNumber": {
+ "type": "number"
+ },
+ "meaning": {
+ "properties": {
+ "career": {
+ "type": "string"
+ },
+ "challenges": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationships": {
+ "type": "string"
+ },
+ "spirituality": {
+ "type": "string"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "keywords",
+ "description",
+ "strengths",
+ "challenges",
+ "career",
+ "relationships",
+ "spirituality"
+ ],
+ "type": "object"
+ },
+ "number": {
+ "type": "number"
+ },
+ "type": {
+ "enum": [
+ "single",
+ "master"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "calculation",
+ "type",
+ "hasKarmicDebt",
+ "meaning"
+ ],
+ "type": "object"
+}get_numerology_compound_number2 fields changedInput 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."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"
+]get_numerology_meanings_number2 fields changedInput 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."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"
+]post_numerology_birth_day2 fields changedInput 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."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"
+]post_numerology_bridge2 fields changedInput 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."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"
+]post_numerology_business_name2 fields changedInput 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."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"
+]post_numerology_chaldean2 fields changedInput 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."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"
+]post_numerology_chart2 fields changedInput 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."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"
+]post_numerology_compatibility2 fields changedInput 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."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"
+]post_numerology_daily2 fields changedInput 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."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"
+]post_numerology_dual2 fields changedInput 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."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"
+]post_numerology_expression2 fields changedInput 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."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"
+]post_numerology_karmic_debt2 fields changedInput 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."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"
+]post_numerology_karmic_lessons2 fields changedInput 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."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"
+]post_numerology_life_path2 fields changedInput 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."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"
+]post_numerology_maturity2 fields changedInput 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."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"
+]post_numerology_personal_day2 fields changedInput 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."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"
+]post_numerology_personal_month2 fields changedInput 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."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"
+]post_numerology_personal_year2 fields changedInput 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."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"
+]post_numerology_personality2 fields changedInput 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."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"
+]post_numerology_soul_urge2 fields changedInput 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."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"
+]get_numerology_compound_number2 fields changedInput schema / examplesAdded value: +[
+ {
+ "number": "23"
+ }
+]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."get_numerology_meanings_number2 fields changedInput schema / examplesAdded value: +[
+ {
+ "number": "5"
+ }
+]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."post_numerology_birth_day2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 23
+ }
+]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."post_numerology_bridge2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 15,
+ "fullName": "John William Smith",
+ "month": 7,
+ "year": 1990
+ }
+]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."post_numerology_business_name2 fields changedInput schema / examplesAdded value: +[
+ {
+ "name": "Ford"
+ }
+]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."post_numerology_chaldean2 fields changedInput schema / examplesAdded value: +[
+ {
+ "name": "Helen"
+ }
+]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."post_numerology_chart2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 15,
+ "fullName": "John William Smith",
+ "month": 7,
+ "year": 1990
+ }
+]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."post_numerology_compatibility1 field changedInput 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."post_numerology_daily2 fields changedInput schema / examplesAdded value: +[
+ {}
+]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."post_numerology_dual2 fields changedInput schema / examplesAdded value: +[
+ {
+ "name": "David"
+ }
+]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."post_numerology_expression2 fields changedInput schema / examplesAdded value: +[
+ {
+ "fullName": "John William Smith"
+ }
+]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."post_numerology_karmic_debt2 fields changedInput schema / examplesAdded value: +[
+ {}
+]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."post_numerology_karmic_lessons2 fields changedInput schema / examplesAdded value: +[
+ {
+ "fullName": "John William Smith"
+ }
+]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."post_numerology_life_path2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 15,
+ "month": 7,
+ "year": 1990
+ }
+]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."post_numerology_maturity2 fields changedInput schema / examplesAdded value: +[
+ {}
+]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."post_numerology_personal_day2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 18,
+ "month": 7
+ }
+]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."post_numerology_personal_month2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 18,
+ "month": 7
+ }
+]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."post_numerology_personal_year2 fields changedInput schema / examplesAdded value: +[
+ {
+ "day": 15,
+ "month": 7
+ }
+]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."post_numerology_personality2 fields changedInput schema / examplesAdded value: +[
+ {
+ "fullName": "John William Smith"
+ }
+]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."post_numerology_soul_urge2 fields changedInput schema / examplesAdded value: +[
+ {
+ "fullName": "John William Smith"
+ }
+]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."get_numerology_compound_number1 field changedInput 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."get_numerology_meanings_number1 field changedInput 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."post_numerology_birth_day1 field changedInput 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."post_numerology_bridge1 field changedInput 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."post_numerology_business_name1 field changedInput 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."post_numerology_chaldean1 field changedInput 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."post_numerology_chart1 field changedInput 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."post_numerology_compatibility1 field changedInput 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."post_numerology_daily1 field changedInput 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."post_numerology_dual1 field changedInput 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."post_numerology_expression1 field changedInput 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."post_numerology_karmic_debt1 field changedInput 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."post_numerology_karmic_lessons1 field changedInput 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."post_numerology_life_path1 field changedInput 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."post_numerology_maturity1 field changedInput 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."post_numerology_personal_day1 field changedInput 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."post_numerology_personal_month1 field changedInput 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."post_numerology_personal_year1 field changedInput 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."post_numerology_personality1 field changedInput 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."post_numerology_soul_urge1 field changedInput 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."get_numerology_compound_number1 field changedInput 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"
+}get_numerology_meanings_number1 field changedInput 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"
+}post_numerology_birth_day1 field changedInput 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"
+}post_numerology_bridge1 field changedInput 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"
+}post_numerology_business_name1 field changedInput 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"
+}post_numerology_chaldean1 field changedInput 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"
+}post_numerology_chart1 field changedInput 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"
+}post_numerology_compatibility1 field changedInput 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"
+}post_numerology_daily1 field changedInput 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"
+}post_numerology_dual1 field changedInput 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"
+}post_numerology_expression1 field changedInput 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"
+}post_numerology_karmic_debt1 field changedInput 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"
+}post_numerology_karmic_lessons1 field changedInput 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"
+}post_numerology_life_path1 field changedInput 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"
+}post_numerology_maturity1 field changedInput 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"
+}post_numerology_personal_day1 field changedInput 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"
+}post_numerology_personal_month1 field changedInput 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"
+}post_numerology_personal_year1 field changedInput 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"
+}post_numerology_personality1 field changedInput 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"
+}post_numerology_soul_urge1 field changedInput 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"
+}get_numerology_compound_numberget_numerology_compound_number_numberget_numerology_compound_number_numberget_numerology_meanings_numberpost_numerology_birth_daypost_numerology_bridgepost_numerology_business_namepost_numerology_chaldeanpost_numerology_chartpost_numerology_compatibilitypost_numerology_dailypost_numerology_dualpost_numerology_expressionpost_numerology_karmic_debtpost_numerology_karmic_lessonspost_numerology_life_pathpost_numerology_maturitypost_numerology_personal_daypost_numerology_personal_monthpost_numerology_personal_yearpost_numerology_personalitypost_numerology_soul_urgeAngel number meanings and repeating sequences like 111, 222, 333 for AI agents.
Gematria with typed transliteration, the 72 names, Tree of Life and Hebrew birthday for AI agents.
Human Design bodygraph, type, authority, profile, gates and channels for AI agents.
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Add one secure layer between your agents and this server.
