Kabbalah MCP Server by RoxyAPI

by com.roxyapi

Overview Discussions Admin

Server Details

Gematria with typed transliteration, the 72 names, Tree of Life and Hebrew birthday for AI agents.

Ownership verified

Status: Healthy
Uptime: 99.8% over 21 days
Last Tested: 2026-09-26 13:50
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-09-23 18:06 across 12 tools

Disambiguation4/5

Most tools are clearly separated by resource and granularity: ciphers, Omer, letters, 72 names, sephirot/tree, birth, and compatibility each have distinct roles. The main exception is post_kabbalah_gematria and post_kabbalah_name_profile, which both score a name across gematria ciphers with candidate spellings and per-letter breakdowns; the descriptions help, but an agent could easily pick the wrong one. The plural/detail pairs like letters vs letters_id are otherwise clear.

Naming Consistency4/5

All names use a consistent snake_case pattern with a get_kabbalah_/post_kabbalah_ prefix and the domain prefix, so the overall style is predictable. Minor deviations: HTTP verbs (get/post) are used instead of semantic action verbs, and get_kabbalah_names_number is a less clear way to express 'name by index' than a resource-detail convention. Still, the pattern is much more coherent than mixed casing or inconsistent verbs.

Tool Count5/5

Twelve tools is well within the ideal 3-15 range and appropriate for a Kabbalah reference/gematria API. The count covers reference lookups, computations, and derived profiles without feeling padded or fragmented. Each tool earns its place in the set.

Completeness4/5

The surface covers the main domain areas—gematria ciphers, Hebrew letters, 72 names, sephirot, Tree of Life, daily Omer, birth profile, and compatibility—so there are no major workflow dead ends. However, get_kabbalah_ciphers advertises eleven rabbinic ciphers and three Latin ciphers, while the scoring tools only exercise ten rabbinic ciphers and two substitutions, leaving some catalogued methods without a computational endpoint. This is a minor gap agents can work around.

Available Tools

12 tools

get_kabbalah_ciphersList gematria ciphers - gematria methods API with provenance on every rowA

Read-only

Inspect

Return the full catalogue of gematria methods this API computes: eleven rabbinic ciphers, two substitution transformations, and the three Latin alphabet ciphers, each with its definition, its provenance class, the century of its tradition and the sources it was taken from. Every entry states whether it is rabbinic or a Renaissance Christian or modern Latin cipher, so a product never presents one tradition as the other. Built for calculators that want to show a reader which method produced a number and where the method comes from.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`ciphers`	Yes
`latinCiphers`	Yes
`transformations`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: every entry 'states whether it is rabbinic or a Renaissance Christian or modern Latin cipher, so a product never presents one tradition as the other,' plus provenance class, century, and sources are guaranteed per row.

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

Conciseness5/5

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

The description is front-loaded with the core scope in the first sentence, immediately followed by provenance guarantees and then the intended consumer. Every sentence earns its place, with no filler or repetition.

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

Completeness5/5

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

There are no required parameters, the output schema describes return shape, and annotations cover the read-only safety profile. The description supplies the remaining context: what the catalogue contains, how each entry is classified, and why a product would use it. Nothing needed for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both lang and compact are fully documented in the input schema with defaults and behavior. The description adds no parameter-specific meaning, which is acceptable given the schema carries the full burden.

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

Purpose5/5

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

The description states a specific verb, 'Return', and a resource, 'the full catalogue of gematria methods', then enumerates the exact contents: eleven rabbinic ciphers, two substitution transformations, and three Latin alphabet ciphers. It clearly distinguishes this metadata/reference tool from computation-focused siblings like get_kabbalah_daily or post_kabbalah_gematria.

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

Usage Guidelines4/5

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

The final sentence, 'Built for calculators that want to show a reader which method produced a number and where the method comes from,' gives a clear intended-use context. It does not explicitly name alternatives or when-not-to-use, but the catalogue framing and sibling names make the distinction evident.

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

get_kabbalah_dailyGet the sephirah of the day - Omer count API with the sephirot pairingA

Read-only

Inspect

Return the day of the Omer count for a date, with the sephirah of the week, the sephirah of the day inside it, the printed Hebrew label and a composed reading. The count is a real, dated, forty nine day observance rather than an invented daily, so outside the window the response says the count is not running and gives the date it next opens. Built for daily widgets, Jewish calendar features and lifecycle emails that want a dated reading rather than a random one.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD. Defaults to the current UTC date when omitted, so a caller that wants a fixed answer should send one.
`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.
`timezone`	No	IANA name or decimal offset, used only to decide which calendar date it is where the caller is when date is omitted. It does not move the count, which is a calendar count rather than a clock one.
`afterSunset`	No	Set true when the moment falls after nightfall, which advances the Hebrew date by one day because the Hebrew day begins in the evening. It is a caller assertion rather than a computation, since sunset depends on a place and this route takes none.

Output Schema

ParametersJSON Schema

Name	Required	Description
`day`	No
`date`	Yes
`week`	No
`inOmer`	Yes
`reading`	Yes
`dayInWeek`	No
`nextStart`	No
`hebrewDate`	No
`daySephirah`	No
`hebrewLabel`	No
`weekSephirah`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavior beyond that: the count is a real, dated 49-day observance, and outside the window the response reports that the count is not running and provides the next opening date. It also clarifies that this is a calendar count rather than a clock count, which is useful for date handling.

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

Conciseness5/5

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

The description is three sentences, each earning its place: the first states what is returned, the second explains the date-window behavior and off-window response, and the third names the intended consumers. Key information is front-loaded and there is no filler or repetition of schema details.

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

Completeness5/5

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

With a fully documented schema, an output schema present, and read-only annotations covering the safety profile, the description covers everything needed for correct invocation: purpose, date-window behavior, target use cases, and the distinction from random daily content. Nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, and the input schema already documents all five parameters with types, defaults, examples, and behavioral notes. The description itself only adds the high-level notion of 'for a date' and does not need to explain parameters further, so the baseline of 3 applies.

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

Purpose5/5

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

The first sentence identifies a specific verb ('Return'), a precise resource ('the day of the Omer count for a date'), and the concrete returned fields (sephirah of the week, sephirah of the day, Hebrew label, composed reading). This clearly separates it from the sibling Kabbalah tools, which concern ciphers, letters, names, and the tree rather than the dated Omer count.

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

Usage Guidelines4/5

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

The description gives a clear intended audience: 'daily widgets, Jewish calendar features and lifecycle emails that want a dated reading rather than a random one.' It also contrasts the tool with an 'invented daily' concept. However, it never explicitly names sibling alternatives or states when not to use them, so an agent must infer exclusions from sibling names and the Omer-specific wording.

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

get_kabbalah_lettersList the Hebrew letters - Hebrew alphabet API with the Sefer Yetzirah attributionsA

Read-only

Inspect

Return all 22 Hebrew letters with their numeric value, their final form, their Sefer Yetzirah class, the element or planet or sign they carry under the requested reading, the tarot trump on their path and the path number itself. The letter attributions are a documented school split rather than a fixed table, so the reading is a request parameter and the response echoes which one produced the answer. Built for letter reference pages, tarot apps that render the paths, and any feature that has to say what a letter carries and on whose authority.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`letterAttribution`	No	Which reading assigns the element, planet or sign to each letter. The seven double letters are the contested column and the four readings genuinely disagree on them; the twelve simple letters run in natural zodiacal order in all four. The golden-dawn member does NOT exchange He and Tzade, which is a later change from a different author.	sefer-yetzirah-gra

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`letters`	Yes
`classCounts`	Yes
`letterAttribution`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With readOnlyHint=true and destructiveHint=false, the safety profile is already covered by annotations. The description adds genuinely useful behavioral context by stating that attributions are 'a documented school split rather than a fixed table' and that the response 'echoes which one produced the answer'.

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

Conciseness5/5

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

Two information-dense sentences with no filler. The first sentence front-loads the output contents, and the second explains the important variability and intended use cases.

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

Completeness5/5

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

The tool has no required parameters and an output schema exists, so the return shape is already specified. The description covers what is returned, why attributions vary, how the reading parameter influences results, and where the tool is meant to be used.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by framing the letterAttribution parameter as a 'reading' and explaining that the response identifies which reading generated the result. The schema itself also contains detailed context about contesting readings, supporting the elevated score.

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

Purpose5/5

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

The description begins with a precise action and resource: 'Return all 22 Hebrew letters' with the exact fields included. The phrase 'all 22' also distinguishes this list endpoint from the singular get_kabbalah_letters_id, and the mention of 'requested reading' sets expectations that this is an attribution-aware reference tool.

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

Usage Guidelines4/5

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

It explicitly names the target use cases: letter reference pages, tarot apps that render paths, and any feature that needs to state what a letter carries and on whose authority. It does not name sibling alternatives or describe when to use a different endpoint, but the context is clear and free of exclusions.

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

get_kabbalah_letters_idGet one Hebrew letter - Hebrew letter meaning APIA

Read-only

Inspect

Return one Hebrew letter in full: its glyph and final form, its value under the standard and the finals reading, its Sefer Yetzirah class and what that class means, the element or planet or sign it carries under the requested reading, the tarot trump on its path, and the path number. Built for letter detail pages and for any reader who wants one row rather than all 22 letters.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Letter identifier, one of alef, bet, gimel, dalet, he, vav, zayin, chet, tet, yod, kaf, lamed, mem, nun, samekh, ayin, pe, tzadi, qof, resh, shin, tav. Matching folds case and punctuation.
`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.
`letterAttribution`	No	Which reading assigns the element, planet or sign to each letter. The seven double letters are the contested column and the four readings genuinely disagree on them; the twelve simple letters run in natural zodiacal order in all four. The golden-dawn member does NOT exchange He and Tzade, which is a later change from a different author.	sefer-yetzirah-gra

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`path`	Yes
`final`	Yes
`trump`	Yes
`value`	Yes
`letter`	Yes
`meaning`	Yes
`ordinal`	Yes
`finalValue`	Yes
`attribution`	Yes
`letterClass`	Yes
`classReading`	Yes
`romanization`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by detailing the response contents (glyph, final form, values, Sefer Yetzirah class, element/planet/sign, tarot trump, path number), giving the agent a concrete expectation of what will be returned without repeating the annotation info.

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

Conciseness4/5

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

The description is a single dense sentence that front-loads the core action ('Return one Hebrew letter in full') and then lists the returned fields and the intended use case. There is no filler, and it covers both purpose and usage in a compact form.

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

Completeness4/5

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

With an output schema present, the description does not need to explain return values, and it does not attempt to. It covers the tool's purpose, content, and use case adequately. It does not mention error handling or edge cases, but the schema's enum and parameter descriptions cover validation. For a read-only, single-item retrieval tool, this is complete.

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

Parameters3/5

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

Schema description coverage is 100%, meaning each parameter is already documented in the schema (id enum, lang options, compact flag, letterAttribution readings). The description does not add extra meaning beyond what the schema provides—it references 'requested reading' but the schema already explains the four readings in detail. Therefore the baseline of 3 applies.

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

Purpose5/5

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

The description states a clear verb ('Return') and a specific resource ('one Hebrew letter in full'), and enumerates the exact attributes returned. It explicitly differentiates from the sibling get_kabbalah_letters by noting 'one row rather than all 22 letters', making the tool's scope unmistakable.

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

Usage Guidelines4/5

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

The description provides a clear usage context: 'Built for letter detail pages and for any reader who wants one row rather than all 22 letters.' This implicitly contrasts with the plural sibling tool, indicating when to use this one. It does not enumerate all alternative tools, but for the primary distinction it is sufficient.

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

get_kabbalah_namesList the 72 names - Shem HaMephorash API derived from the versesA

Read-only

Inspect

Return the seventy two names, each with the three letters it is read from, the divine name suffix, the five degree ecliptic arc it governs, the sign that arc falls in and the angelic choir it belongs to. The names are DERIVED from three verses of Exodus read in the boustrophedon order rather than copied from a table, and any row where a named published list differs is flagged on that row. Pass a longitude to get the single name governing that degree. Built for birth angel features, Shem HaMephorash reference pages and any product that has to show where a name comes from.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`limit`	No	Maximum items to return per page. Range: 1-72, default 20.
`offset`	No	Number of items to skip for pagination. Default 0.
`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.
`longitude`	No	Ecliptic longitude in degrees, 0 inclusive to 360 exclusive, measured from 0 Aries. Returns the single name governing that degree instead of the list. 360 is rejected because it is the same point as 0 and the arcs are half open at the top.

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes
`names`	Yes
`total`	Yes
`offset`	Yes
`longitude`	No

TDQS

A4.1/5.0

Behavior4/5

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

The description goes beyond the readOnly/destructive annotations by explaining that the names are 'DERIVED from three verses of Exodus read in the boustrophedon order rather than copied from a table' and that discrepant rows are flagged. This adds meaningful behavioral context about data provenance and flags, with no contradiction to the annotations.

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

Conciseness4/5

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

The description front-loads the core output and then adds details on derivation, longitude mode, and use cases. It is a bit dense but every sentence contributes useful information, so it earns a score above average.

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

Completeness4/5

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

Given the rich input schema and an output schema, the description provides essential conceptual background, derivation methodology, and intended use cases. It does not need to spell out return values because an output schema exists, and it covers the key behavioral variant (longitude). It is complete enough for an agent to select and invoke correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds little beyond the schema for parameters, mentioning longitude behavior in prose but not adding new semantic detail. Per the rubric, a baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states a specific verb and resource: 'Return the seventy two names' with a detailed list of attributes: letters, divine name suffix, ecliptic arc, sign, and angelic choir. It also mentions the alternative single-name behavior via longitude, which distinguishes it from sibling tools like get_kabbalah_names_number or get_kabbalah_letters.

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

Usage Guidelines4/5

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

It provides clear context for when to use the tool ('Built for birth angel features, Shem HaMephorash reference pages...') and describes the conditional longitude mode ('Pass a longitude to get the single name governing that degree'). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

get_kabbalah_names_numberGet one of the 72 names - 72 names of God API by indexA

Read-only

Inspect

Return one of the seventy two names by its index: the three letters read out of the verses, the exact positions they were read from, the suffixed name, the ecliptic arc it governs, the sign and the choir. The positions are on the response so a reader can check the derivation against the verses rather than trust it. Built for birth angel detail pages and reference features.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`number`	Yes	Index of the name, 1 to 72.
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`sign`	Yes
`choir`	Yes
`arcEnd`	Yes
`number`	Yes
`suffix`	Yes
`letters`	Yes
`arcStart`	Yes
`degreeInSign`	Yes
`romanization`	Yes
`traditionalName`	Yes
`lettersAsWritten`	Yes
`publishedDisagreement`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the positions are included so readers can verify the derivation against the verses, which goes beyond the structured annotations. It also enumerates the response contents, aiding expectation-setting.

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

Conciseness5/5

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

The description is concise: two sentences. The primary action and key output content are front-loaded, and the verification rationale is a meaningful addition without any wasted words.

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

Completeness5/5

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

Given that an output schema exists, the description need not detail return shapes. It covers the tool's purpose, use case, and a distinctive behavioral trait (verifiable derivation). The schema handles parameter specifics, so no critical information is missing.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter (lang, number, compact) fully documented. The description mentions 'by its index,' which aligns with the required `number` parameter, but adds no additional semantic detail beyond what the schema already provides. Baseline 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: 'Return one of the seventy two names by its index.' It lists the exact output fields (letters, positions, suffixed name, ecliptic arc, sign, choir), which clearly distinguishes it from siblings like get_kabbalah_names (which likely returns all names).

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

Usage Guidelines4/5

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

The description gives explicit usage context: 'Built for birth angel detail pages and reference features.' It does not name alternatives or exclusion conditions, but the context is clear enough for an agent to know when to invoke this tool.

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

get_kabbalah_sephirot_idGet one sephirah - sefirot meaning API with the paths that touch itA

Read-only

Inspect

Return one sephirah in full: its Hebrew and English names, its pillar, its world, the sphere it carries under the requested system, what the emanation is said to hold, and every path that touches it with the letter and the tarot trump on each. Daat is addressable here as well, and its response says plainly that it is counted in some diagrams and not in others. Built for sephirot detail pages and for tree diagrams that load one node at a time.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Sephirah identifier, one of keter, chokhmah, binah, chesed, gevurah, tiferet, netzach, hod, yesod, malkuth, daat. Matching folds case and punctuation.
`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.
`sephirotSystem`	No	Which reading assigns a sphere to each sephirah. The two were compared row by row and agree on all ten, so the answer is the same either way; the parameter exists so a caller knows which one produced it rather than assuming.	classical
`letterAttribution`	No	Which reading assigns the element, planet or sign to each letter. The seven double letters are the contested column and the four readings genuinely disagree on them; the twelve simple letters run in natural zodiacal order in all four. The golden-dawn member does NOT exchange He and Tzade, which is a later change from a different author.	sefer-yetzirah-gra

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`paths`	Yes
`world`	Yes
`hebrew`	Yes
`number`	Yes
`pillar`	Yes
`english`	Yes
`meaning`	Yes
`pillarName`	Yes
`attribution`	Yes
`conventions`	Yes
`romanization`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the operation's safety profile is established. The description adds meaningful behavioral context by noting that Daat is addressable and that its response explicitly discloses how it is counted differently across diagrams. It also tells the agent exactly what content each returned sephirah record contains.

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

Conciseness5/5

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

The description is three sentences, each earning its place: the first front-loads the full return payload, the second adds the important Daat caveat, and the third names the target use cases. There is no filler or redundant repetition of schema field names.

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

Completeness5/5

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

With a 100%-documented input schema, an output schema present, and annotations covering the read-only safety profile, the description supplies the remaining practical context: exact scope, Daat behavior, and intended page/tree use. Nothing essential for invoking this tool correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, and the input schema already documents each parameter thoroughly, including enums, defaults, case/punctuation folding, translation fallback, and compact shape behavior. The description only loosely references 'the requested system,' but it does not need to compensate because the schema carries the semantic weight.

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

Purpose5/5

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

The description opens with a specific verb, 'Return one sephirah in full,' and then enumerates the exact fields and associated data it returns, including names, pillar, world, sphere, emanations, and connected paths with letters and tarot trumps. This moves well beyond a restatement of the name or title and clearly distinguishes the tool from sibling tree or list-style endpoints.

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

Usage Guidelines4/5

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

The description states a clear context for use: 'Built for sephirot detail pages and for tree diagrams that load one node at a time.' This gives an agent a concrete sense of when to invoke this tool. It does not explicitly name alternatives or say when not to use it, but the single-node focus is unambiguous.

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

get_kabbalah_treeGet the Tree of Life - sephirot and 22 paths API with typed school variantsA

Read-only

Inspect

Return the whole Tree of Life in one call: the ten sephirot with their Hebrew, their pillar, their world and their sphere, Daat beside them, the 22 paths with the letter and the tarot trump on each, the four worlds under both mappings that are in circulation, and the lightning flash order. The school splits are typed request parameters rather than hidden defaults, and the response echoes which arrangement and which reading produced it. Built for Tree of Life diagrams, tarot path features and reference pages that need the structure rather than a picture of it.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`treeVariant`	No	Which arrangement of the twenty two paths. The 1652 arrangement, in which Malkuth carries three paths, is the only one with a published table that letters every path, so it is the only member.	kircher
`sephirotSystem`	No	Which reading assigns a sphere to each sephirah. The two were compared row by row and agree on all ten, so the answer is the same either way; the parameter exists so a caller knows which one produced it rather than assuming.	classical
`letterAttribution`	No	Which reading assigns the element, planet or sign to each letter. The seven double letters are the contested column and the four readings genuinely disagree on them; the twelve simple letters run in natural zodiacal order in all four. The golden-dawn member does NOT exchange He and Tzade, which is a later change from a different author.	sefer-yetzirah-gra

Output Schema

ParametersJSON Schema

Name	Required	Description
`paths`	Yes
`worlds`	Yes
`sephirot`	Yes
`conventions`	Yes
`lightningFlash`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context beyond that: it discloses the response echoes which arrangement and reading produced it, notes that school splits are typed parameters rather than hidden defaults, and specifies that translation coverage varies with English fallback (though that detail is in the schema). It accurately reflects the read-only nature without contradiction, and the extra context about response echoing is not available from annotations.

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

Conciseness4/5

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

The description is a single paragraph but is well-organized and front-loads the core purpose. Each clause adds information: the content list, the design decision, and the intended use cases. It avoids redundancy and keeps sentences focused, though it is slightly longer than strictly necessary. The structure is clear and efficient, earning a 4.

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

Completeness4/5

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

Given the tool's complexity (5 parameters, 4 enums) and the presence of an output schema, the description covers the key aspects: what data is returned, the design choice around parameters, and the echo of the arrangement. It does not mention error handling or edge cases, but those are likely covered by the output schema. The description is sufficient for an agent to understand the tool's purpose and expected output without missing critical context.

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

Parameters3/5

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

The schema covers 100% of parameters with detailed descriptions, including enums and defaults. The tool description adds only a high-level note that school splits are typed request parameters, which is already evident from the schema. It does not elaborate on parameter semantics beyond what the schema provides, so it meets the baseline of 3 but does not exceed it.

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

Purpose5/5

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

The description opens with a precise verb and resource ('Return the whole Tree of Life in one call') and enumerates the exact components delivered (ten sephirot with Hebrew, pillar, world, sphere; Daat; 22 paths with letter and tarot trump; four worlds; lightning flash order). It also distinguishes itself from siblings by stating it is 'Built for Tree of Life diagrams, tarot path features and reference pages that need the structure rather than a picture of it,' clearly separating it from tools like get_kabbalah_letters or get_kabbalah_sephirot_id.

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

Usage Guidelines3/5

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

The description implies usage for structural references and notes that school splits are exposed as parameters, but it does not explicitly state when to choose this tool over alternatives, nor does it name any sibling tool or provide exclusion criteria. The mention of 'structure rather than a picture' hints at a use case but leaves the agent to infer the boundary with other kabbalah tools. No explicit 'use when X' or 'not for Y' guidance is given.

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

post_kabbalah_birth_profileGenerate a birth profile - Hebrew birthday and birth angel APIA

Read-only

Inspect

Return the Hebrew date of a birth, the Hebrew birthday that follows it, the three birth names of the Renaissance angel tradition and the sephirah of the birth day, from one birth moment. The Hebrew date is computed from the published calendar algorithm rather than looked up, the sunset boundary is a typed request field because it depends on where you were, and the two rival ways of dating the first name are a typed convention the response echoes. Built for Jewish culture and education apps, birth angel features and any product that wants the Hebrew birthday on the same key as the rest of its readings.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	Birth date in YYYY-MM-DD, proleptic Gregorian. Dates before the 1582 reform are read on the same proleptic reckoning rather than switched to the Julian calendar.
`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
`time`	No	Birth time in HH:MM:SS local to the timezone field. Defaults to noon when omitted, which is stated because the name read from the hour changes every twenty minutes and a defaulted time cannot be precise.
`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.
`timezone`	Yes	IANA name (e.g. "America/New_York", "Europe/London", "UTC"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. "-05:00", "+01:00"). Prefer the IANA name: it is resolved to the offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error.
`yearStart`	No	Which date the civil wheel of five day periods opens on. Both are conventions rather than facts: the equinox itself moves inside a window that covers both days, and it fell on 20 March in 2026. march-21 is the pinned published wheel and march-20 is that wheel shifted one day. Ignored when angelDating is solar-longitude.	march-21
`afterSunset`	No	Set true when the moment falls after nightfall, which advances the Hebrew date by one day because the Hebrew day begins in the evening. It is a caller assertion rather than a computation, since sunset depends on a place and this conversion takes none.
`angelDating`	No	How the name of the day is found. Use solar-longitude for the exact five degree arc the Sun stood in at the birth moment, or lenain-blocks for the fixed civil calendar of five day periods. The Sun does not move at a constant rate, so the two drift apart by up to about three days by early August and were never reconciled.	solar-longitude
`leapDayPolicy`	No	Where 29 February falls. The civil wheel was built for a 365 day year and has no slot for it, so published tables differ: extend-previous reads the day as part of the period ending 28 February, next-angel reads it as the opening of the period starting 1 March. Ignored when angelDating is solar-longitude.	extend-previous

Output Schema

ParametersJSON Schema

Name	Required	Description
`angels`	Yes
`sephirah`	Yes
`birthData`	Yes
`hebrewDate`	Yes
`conventions`	Yes
`hebrewBirthday`	Yes

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: the Hebrew date is computed via a published algorithm rather than looked up, the sunset field is a caller assertion because it depends on location, and the two naming conventions are typed and echoed. This goes beyond the annotations and helps the agent understand why certain fields exist and how the computation works.

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

Conciseness5/5

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

The description is two sentences with no wasted words. The first sentence front-loads the main function, and the second packs in the key design rationales (computation, sunset dependency, naming conventions) without redundancy. It is dense but efficient.

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

Completeness4/5

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

Given the tool's complexity (9 parameters, 4 enums, output schema present), the description covers the essential behavioral and domain context, such as the computation method and the two conventions. It does not explain every parameter (schema does that) nor describe return format (output schema exists), so it is reasonably complete for an agent to use correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add detailed parameter-level semantics beyond what the schema provides, though it does offer a high-level explanation of the sunset and angelDating concepts. This aligns with the baseline of 3 for high coverage.

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

Purpose5/5

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

The description states a specific verb ('Return') with a clear resource ('birth profile') and enumerates the exact outputs: Hebrew date, following Hebrew birthday, three birth names, and sephirah. It distinguishes from siblings by focusing on birth-specific data, while other tools like get_kabbalah_names or get_kabbalah_ciphers are clearly different in scope.

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

Usage Guidelines3/5

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

The description gives a target audience ('Built for Jewish culture and education apps, birth angel features...') which implies when to use it, but it does not explicitly state when to use this instead of sibling tools like post_kabbalah_name_profile or get_kabbalah_daily. There is no mention of alternatives or exclusions, so guidance is only implied.

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

post_kabbalah_compatibilityCompare two names - gematria name compatibility API with every component publishedA

Read-only

Inspect

Score two names against each other in gematria and return both profiles, the ciphers they agree on, and a composite with every component and its maximum published beside it. Equal value under the standard reading is the one relation the classical method actually works with and it carries the largest weight; the rest of the composite is ours and the response says so, so a caller can recompute or ignore it. Built for name compatibility features, relationship content and any product that wants a number it can show the arithmetic for.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`firstName`	No	First name in Latin script. Send firstNameHebrew instead to control the spelling.
`secondName`	No	Second name in Latin script. Send secondNameHebrew instead to control the spelling.
`misparGadol`	No	Which method the name mispar gadol means, because the sources use it for two. Use finals-500-900 to score the five word final letters as 500 to 900, or milui to score each letter as the value of its own spelled out name.	finals-500-900
`firstNameHebrew`	No	First name already in Hebrew, which skips the transliteration step.
`transliteration`	No	How a Latin name is written in Hebrew before it is scored. Two members. letter-map-mathers is the 1887 Hermetic letter map, with e read as its author practised it: a point inside a word and alef at the start of one. It writes no c, f, w or x, so a name carrying one of them outside a two letter group returns 400 naming the letter. letter-map-modern follows the modern Israeli transcription rules for the sound each Latin letter carries in English and French spelling, covers every Latin letter, drops the geresh and does not double vav or yod, so send textHebrew for the ktiv male form. Every form states the readings it used in rule. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction.	letter-map-mathers
`secondNameHebrew`	No	Second name already in Hebrew, which skips the transliteration step.

Output Schema

ParametersJSON Schema

Name	Required	Description
`band`	Yes
`first`	Yes
`score`	Yes
`second`	Yes
`reading`	Yes
`components`	Yes
`conventions`	Yes
`sharedValues`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description discloses how the composite works: the standard equal-value relation carries the largest weight, the rest is proprietary, and the response explicitly says so so callers can recompute or ignore it. This gives agents an unusually clear picture of the algorithm's provenance and limits.

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

Conciseness4/5

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

The description is front-loaded with the core function, followed by the weighting caveat and then the target use cases. It is a little dense, particularly the middle sentence about standard reading and composite ownership, but every sentence carries distinct information and there is no filler.

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

Completeness4/5

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

The description conveys the tool's purpose, output shape, algorithmic transparency, and use cases, while the output schema and fully documented parameters cover invocation details. It is complete enough for correct selection and calling, though it does not offer guidance on edge cases such as mixing Hebrew and Latin inputs, which the schema leaves open.

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

Parameters3/5

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

The input schema has 100% parameter documentation with detailed descriptions for lang, compact, firstName, secondName, and transliteration. The main description adds general context about comparing two names, but it does not add meaning beyond the schema, so the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb ('Score'), a clear resource ('two names against each other in gematria'), and the exact output components: both profiles, ciphers they agree on, and a composite. This separates it from siblings like post_kabbalah_gematria and get_kabbalah_names, which handle single names or cipher lookup rather than pairwise compatibility.

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

Usage Guidelines4/5

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

The description gives clear intended contexts: 'name compatibility features, relationship content and any product that wants a number it can show the arithmetic for.' It does not explicitly name sibling tools as alternatives or say when not to use them, but the use-case framing is enough to guide selection.

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

post_kabbalah_gematriaCalculate gematria - Hebrew gematria calculator API with every spelling shownA

Read-only

Inspect

Score a Hebrew word or a Latin name across ten rabbinic gematria ciphers and two substitution transformations, with the per letter breakdown and the curated equal value matches beside each number. A Latin name has no single Hebrew spelling, so every candidate spelling the transliteration map produces comes back with its own values and the rule that produced it, and the chosen one is named. Built for name meaning features, numerology apps that want the Hebrew reading, and any product that has to show a reader why the number is what it is.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`text`	No	Latin text to write in Hebrew and then score, up to 200 characters. Non Latin scripts are folded to Latin first, so a Cyrillic or Devanagari name works. Send textHebrew instead to control the Hebrew spelling yourself.
`ciphers`	No	Which ciphers to return, by identifier. Omit for every computed cipher. Valid values are mispar-hechrachi, mispar-gadol, otiyot-be-milui, mispar-katan, mispar-kidmi, mispar-prati, mispar-ha-merubah-ha-klali, mispar-meshulash, mispar-musafi, kolel.
`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.
`textHebrew`	No	Hebrew text to score, up to 200 characters. Anything outside the Hebrew script is rejected. Vowel points, cantillation marks, maqaf and paseq are removed before scoring, so a pointed and an unpointed spelling of one word give the same number.
`misparGadol`	No	Which method the name mispar gadol means, because the sources use it for two. Use finals-500-900 to score the five word final letters as 500 to 900, or milui to score each letter as the value of its own spelled out name.	finals-500-900
`atbashOutput`	No	What AtBash and Albam return: the substituted Hebrew string, its standard value, or both. The biblical witness for AtBash is a substituted WORD rather than a number, which is why the string is available on its own.	both
`latinCiphers`	No	Whether to also score the Latin text with the three Latin alphabet ciphers. They are Renaissance Christian and modern in lineage rather than rabbinic, and the response labels each one. Ignored when textHebrew was sent.
`includeMatches`	No	Whether to return the curated equal value entries for the chosen spelling. Set false to skip the lookup when only the numbers are wanted.
`transliteration`	No	How a Latin name is written in Hebrew before it is scored. Two members. letter-map-mathers is the 1887 Hermetic letter map, with e read as its author practised it: a point inside a word and alef at the start of one. It writes no c, f, w or x, so a name carrying one of them outside a two letter group returns 400 naming the letter. letter-map-modern follows the modern Israeli transcription rules for the sound each Latin letter carries in English and French spelling, covers every Latin letter, drops the geresh and does not double vav or yod, so send textHebrew for the ktiv male form. Every form states the readings it used in rule. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction.	letter-map-mathers

Output Schema

ParametersJSON Schema

Name	Required	Description
`input`	Yes
`chosen`	Yes
`values`	Yes
`matches`	Yes
`conventions`	Yes
`hebrewForms`	Yes
`latinValues`	No
`transformations`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With readOnlyHint=true and destructiveHint=false, the safety profile is already established. The description adds valuable behavioral context: Latin names produce every candidate Hebrew spelling with the producing rule, the chosen spelling is named, and results include per-letter breakdowns and curated matches. This goes beyond what the annotations alone convey.

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

Conciseness5/5

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

The description is three sentences with no wasted words. It front-loads the core action, explains the important Latin-name edge case, and closes with use cases. This is appropriate for a complex tool because the schema handles the detailed parameters.

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

Completeness5/5

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

Given the 10-parameter schema, 100% parameter coverage, output schema, and read-only annotations, the description is complete enough. It addresses the most confusing behavior—multiple Hebrew spellings for Latin names—and the schema covers the remaining details. No essential agent decision is left unexplained.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description provides helpful framing for ciphers and transliteration but does not need to restate parameter details. It adds conceptual context, not new syntax or format information beyond what the schema already gives.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Score a Hebrew word or a Latin name across ten rabbinic gematria ciphers and two substitution transformations.' It also names concrete output components (per-letter breakdown, equal-value matches), making it clear what the tool does and how it differs from profile/name-oriented siblings.

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

Usage Guidelines4/5

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

The description clearly states the intended contexts: 'name meaning features, numerology apps that want the Hebrew reading, and any product that has to show a reader why the number is what it is.' It does not explicitly list excluded cases or name sibling alternatives, but the use-case guidance is strong enough for an agent to select it appropriately.

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

post_kabbalah_name_profileGenerate a name profile - Kabbalah name numerology API with the spelling shownA

Read-only

Inspect

Score a name across the rabbinic gematria ciphers and place it on the Tree of Life, with every candidate Hebrew spelling shown and the chosen one named. The response carries the standard, the large, the small and the preceding readings with the per letter breakdown, the sephirah the reduced value points at, and the curated words that share the value. Built for name meaning pages, Kabbalah numerology features and any product that wants a name reading it can defend line by line.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`name`	No	The name in Latin script, to be written in Hebrew and then scored. Non Latin scripts are folded to Latin first. Send nameHebrew instead to control the spelling yourself.
`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.
`nameHebrew`	No	The name already in Hebrew, which skips the transliteration step entirely and scores exactly the spelling you sent.
`misparGadol`	No	Which method the name mispar gadol means, because the sources use it for two. Use finals-500-900 to score the five word final letters as 500 to 900, or milui to score each letter as the value of its own spelled out name.	finals-500-900
`transliteration`	No	How a Latin name is written in Hebrew before it is scored. Two members. letter-map-mathers is the 1887 Hermetic letter map, with e read as its author practised it: a point inside a word and alef at the start of one. It writes no c, f, w or x, so a name carrying one of them outside a two letter group returns 400 naming the letter. letter-map-modern follows the modern Israeli transcription rules for the sound each Latin letter carries in English and French spelling, covers every Latin letter, drops the geresh and does not double vav or yod, so send textHebrew for the ktiv male form. Every form states the readings it used in rule. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction.	letter-map-mathers

Output Schema

ParametersJSON Schema

Name	Required	Description
`input`	Yes
`chosen`	Yes
`values`	Yes
`letters`	Yes
`matches`	Yes
`sephirah`	Yes
`conventions`	Yes
`hebrewForms`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond the annotations: it promises 'every candidate Hebrew spelling shown and the chosen one named' and enumerates exactly what the response carries (standard, large, small, preceding readings, per-letter breakdown, sephirah, curated words). This gives an agent a concrete picture of the tool's output behavior without contradicting the annotations.

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

Conciseness4/5

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

The description is two dense sentences that pack in the core action, the unique spelling behavior, the full response contents, and the intended use cases. It is front-loaded with the primary function and then fills in supporting details. It is slightly longer than absolute minimum but every clause earns its place, so it remains well-structured.

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

Completeness4/5

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

With an output schema and fully documented parameters, the description does not need to explain return values or parameter syntax. It supplies the missing context: the tool's purpose, the product fit, and the key behavioral promise about Hebrew spelling. The only minor gap is that it does not discuss how to orchestrate the optional name/nameHebrew parameters, but the schema already hints at this, so the description is complete enough for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema fully documents all six parameters, including enums and mutually exclusive hints (e.g., 'Send nameHebrew instead to control the spelling yourself'). The tool description itself adds no parameter-level meaning, so the baseline of 3 applies; it neither improves nor detracts from what the schema already provides.

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

Purpose4/5

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

The description clearly states the tool's core action: 'Score a name across the rabbinic gematria ciphers and place it on the Tree of Life,' along with distinctive details like 'every candidate Hebrew spelling shown' and the full response breakdown. This is specific enough to identify the tool's function, but it does not explicitly differentiate from close siblings like post_kabbalah_gematria or post_kabbalah_birth_profile, so it only partially distinguishes.

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

Usage Guidelines4/5

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

The description provides clear usage context: 'Built for name meaning pages, Kabbalah numerology features and any product that wants a name reading it can defend line by line.' This tells an agent when to reach for this tool, but it offers no exclusions or alternatives, so it stops short of the explicit when/when-not guidance that would merit a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 23, 2026
- Changedget_kabbalah_names3 fields changed
  - addedInput schema / properties / longitude / minimum
```
Added value: +0
```
  - addedInput schema / properties / offset / default
```
Added value: +0
```
  - addedInput schema / properties / offset / minimum
```
Added value: +0
```

2 tool updatesSep 20, 2026

Changedget_kabbalah_names5 fields changed
- removedInput schema / properties / longitude / minimum
```
Removed value: -0
```
- changedInput schema / properties / longitude / type
```
Previous value: -[
-  "number",
-  "null"
-]New value: +"number"
```
- removedInput schema / properties / offset / default
```
Removed value: -0
```
- removedInput schema / properties / offset / minimum
```
Removed value: -0
```
- changedInput schema / properties / offset / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```

Changedpost_kabbalah_gematria1 field changed

addedInput schema / properties / ciphers / items / enum

Added value: +[
+  "mispar-hechrachi",
+  "mispar-gadol",
+  "otiyot-be-milui",
+  "mispar-katan",
+  "mispar-kidmi",
+  "mispar-prati",
+  "mispar-ha-merubah-ha-klali",
+  "mispar-meshulash",
+  "mispar-musafi",
+  "kolel"
+]

12 tool updatesSep 20, 2026

Changedget_kabbalah_ciphers1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "ciphers": {
+      "items": {
+        "properties": {
+          "century": {
+            "type": "string"
+          },
+          "computed": {
+            "type": "boolean"
+          },
+          "definition": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "multiValued": {
+            "type": "boolean"
+          },
+          "name": {
+            "type": "string"
+          },
+          "sources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "tradition": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "tradition",
+          "century",
+          "definition",
+          "computed",
+          "sources"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "latinCiphers": {
+      "items": {
+        "properties": {
+          "century": {
+            "type": "string"
+          },
+          "computed": {
+            "type": "boolean"
+          },
+          "definition": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "multiValued": {
+            "type": "boolean"
+          },
+          "name": {
+            "type": "string"
+          },
+          "sources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "tradition": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "tradition",
+          "century",
+          "definition",
+          "computed",
+          "sources"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    },
+    "transformations": {
+      "items": {
+        "properties": {
+          "century": {
+            "type": "string"
+          },
+          "computed": {
+            "type": "boolean"
+          },
+          "definition": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "multiValued": {
+            "type": "boolean"
+          },
+          "name": {
+            "type": "string"
+          },
+          "sources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "tradition": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "tradition",
+          "century",
+          "definition",
+          "computed",
+          "sources"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "total",
+    "ciphers",
+    "transformations",
+    "latinCiphers"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_daily1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "date": {
+      "type": "string"
+    },
+    "day": {
+      "type": "number"
+    },
+    "dayInWeek": {
+      "type": "number"
+    },
+    "daySephirah": {
+      "properties": {
+        "english": {
+          "type": "string"
+        },
+        "hebrew": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "romanization": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "hebrew",
+        "romanization",
+        "english"
+      ],
+      "type": "object"
+    },
+    "hebrewDate": {
+      "type": "string"
+    },
+    "hebrewLabel": {
+      "type": "string"
+    },
+    "inOmer": {
+      "type": "boolean"
+    },
+    "nextStart": {
+      "type": "string"
+    },
+    "reading": {
+      "type": "string"
+    },
+    "week": {
+      "type": "number"
+    },
+    "weekSephirah": {
+      "properties": {
+        "english": {
+          "type": "string"
+        },
+        "hebrew": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "romanization": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "hebrew",
+        "romanization",
+        "english"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "date",
+    "inOmer",
+    "reading"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_letters1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "classCounts": {
+      "properties": {
+        "double": {
+          "type": "number"
+        },
+        "mother": {
+          "type": "number"
+        },
+        "simple": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "mother",
+        "double",
+        "simple"
+      ],
+      "type": "object"
+    },
+    "letterAttribution": {
+      "type": "string"
+    },
+    "letters": {
+      "items": {
+        "properties": {
+          "attribution": {
+            "properties": {
+              "kind": {
+                "type": "string"
+              },
+              "value": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "kind",
+              "value"
+            ],
+            "type": "object"
+          },
+          "classReading": {
+            "type": "string"
+          },
+          "final": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "finalValue": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "letter": {
+            "type": "string"
+          },
+          "letterClass": {
+            "type": "string"
+          },
+          "meaning": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "ordinal": {
+            "type": "number"
+          },
+          "path": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "trump": {
+            "properties": {
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              },
+              "number": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "number",
+              "name"
+            ],
+            "type": "object"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "letter",
+          "final",
+          "romanization",
+          "name",
+          "meaning",
+          "ordinal",
+          "value",
+          "finalValue",
+          "letterClass",
+          "classReading",
+          "attribution",
+          "trump",
+          "path"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "letterAttribution",
+    "classCounts",
+    "letters"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_letters_id1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "properties": {
+        "kind": {
+          "type": "string"
+        },
+        "value": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "kind",
+        "value"
+      ],
+      "type": "object"
+    },
+    "classReading": {
+      "type": "string"
+    },
+    "final": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "finalValue": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "id": {
+      "type": "string"
+    },
+    "letter": {
+      "type": "string"
+    },
+    "letterClass": {
+      "type": "string"
+    },
+    "meaning": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "ordinal": {
+      "type": "number"
+    },
+    "path": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "romanization": {
+      "type": "string"
+    },
+    "trump": {
+      "properties": {
+        "id": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "number": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "number",
+        "name"
+      ],
+      "type": "object"
+    },
+    "value": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "id",
+    "letter",
+    "final",
+    "romanization",
+    "name",
+    "meaning",
+    "ordinal",
+    "value",
+    "finalValue",
+    "letterClass",
+    "classReading",
+    "attribution",
+    "trump",
+    "path"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_names1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "limit": {
+      "type": "number"
+    },
+    "longitude": {
+      "type": "number"
+    },
+    "names": {
+      "items": {
+        "properties": {
+          "arcEnd": {
+            "type": "number"
+          },
+          "arcStart": {
+            "type": "number"
+          },
+          "choir": {
+            "type": "string"
+          },
+          "degreeInSign": {
+            "type": "number"
+          },
+          "letters": {
+            "type": "string"
+          },
+          "lettersAsWritten": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "number": {
+            "type": "number"
+          },
+          "publishedDisagreement": {
+            "properties": {
+              "list": {
+                "type": "string"
+              },
+              "prints": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "list",
+              "prints"
+            ],
+            "type": "object"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "sign": {
+            "type": "string"
+          },
+          "suffix": {
+            "type": "string"
+          },
+          "traditionalName": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "number",
+          "letters",
+          "lettersAsWritten",
+          "suffix",
+          "name",
+          "romanization",
+          "traditionalName",
+          "arcStart",
+          "arcEnd",
+          "sign",
+          "degreeInSign",
+          "choir"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "limit",
+    "offset",
+    "names"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_names_number1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "arcEnd": {
+      "type": "number"
+    },
+    "arcStart": {
+      "type": "number"
+    },
+    "choir": {
+      "type": "string"
+    },
+    "degreeInSign": {
+      "type": "number"
+    },
+    "letters": {
+      "type": "string"
+    },
+    "lettersAsWritten": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "number": {
+      "type": "number"
+    },
+    "publishedDisagreement": {
+      "properties": {
+        "list": {
+          "type": "string"
+        },
+        "prints": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "list",
+        "prints"
+      ],
+      "type": "object"
+    },
+    "romanization": {
+      "type": "string"
+    },
+    "sign": {
+      "type": "string"
+    },
+    "suffix": {
+      "type": "string"
+    },
+    "traditionalName": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "number",
+    "letters",
+    "lettersAsWritten",
+    "suffix",
+    "name",
+    "romanization",
+    "traditionalName",
+    "arcStart",
+    "arcEnd",
+    "sign",
+    "degreeInSign",
+    "choir"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_sephirot_id1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "type": "string"
+    },
+    "conventions": {
+      "properties": {
+        "letterAttribution": {
+          "type": "string"
+        },
+        "sephirotSystem": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "sephirotSystem",
+        "letterAttribution"
+      ],
+      "type": "object"
+    },
+    "english": {
+      "type": "string"
+    },
+    "hebrew": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "meaning": {
+      "type": "string"
+    },
+    "number": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "paths": {
+      "items": {
+        "properties": {
+          "attribution": {
+            "properties": {
+              "kind": {
+                "type": "string"
+              },
+              "value": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "kind",
+              "value"
+            ],
+            "type": "object"
+          },
+          "from": {
+            "type": "string"
+          },
+          "letter": {
+            "type": "string"
+          },
+          "letterGlyph": {
+            "type": "string"
+          },
+          "path": {
+            "type": "number"
+          },
+          "to": {
+            "type": "string"
+          },
+          "trump": {
+            "properties": {
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              },
+              "number": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "number",
+              "name"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "path",
+          "letter",
+          "letterGlyph",
+          "from",
+          "to",
+          "trump",
+          "attribution"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pillar": {
+      "type": "string"
+    },
+    "pillarName": {
+      "type": "string"
+    },
+    "romanization": {
+      "type": "string"
+    },
+    "world": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "id",
+    "number",
+    "hebrew",
+    "romanization",
+    "english",
+    "pillar",
+    "pillarName",
+    "world",
+    "attribution",
+    "meaning",
+    "paths",
+    "conventions"
+  ],
+  "type": "object"
+}

Changedget_kabbalah_tree1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "conventions": {
+      "properties": {
+        "letterAttribution": {
+          "type": "string"
+        },
+        "sephirotSystem": {
+          "type": "string"
+        },
+        "treeVariant": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "treeVariant",
+        "sephirotSystem",
+        "letterAttribution"
+      ],
+      "type": "object"
+    },
+    "lightningFlash": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "paths": {
+      "items": {
+        "properties": {
+          "attribution": {
+            "properties": {
+              "kind": {
+                "type": "string"
+              },
+              "value": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "kind",
+              "value"
+            ],
+            "type": "object"
+          },
+          "from": {
+            "type": "string"
+          },
+          "letter": {
+            "type": "string"
+          },
+          "letterGlyph": {
+            "type": "string"
+          },
+          "path": {
+            "type": "number"
+          },
+          "to": {
+            "type": "string"
+          },
+          "trump": {
+            "properties": {
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              },
+              "number": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "number",
+              "name"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "path",
+          "letter",
+          "letterGlyph",
+          "from",
+          "to",
+          "trump",
+          "attribution"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sephirot": {
+      "items": {
+        "properties": {
+          "attribution": {
+            "type": "string"
+          },
+          "english": {
+            "type": "string"
+          },
+          "hebrew": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "meaning": {
+            "type": "string"
+          },
+          "number": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "pillar": {
+            "type": "string"
+          },
+          "pillarName": {
+            "type": "string"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "world": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "number",
+          "hebrew",
+          "romanization",
+          "english",
+          "pillar",
+          "pillarName",
+          "world",
+          "attribution",
+          "meaning"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "worlds": {
+      "items": {
+        "properties": {
+          "english": {
+            "type": "string"
+          },
+          "hebrew": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "sephirot": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "sephirotAlternate": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "id",
+          "hebrew",
+          "romanization",
+          "english",
+          "sephirot",
+          "sephirotAlternate"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "sephirot",
+    "paths",
+    "worlds",
+    "lightningFlash",
+    "conventions"
+  ],
+  "type": "object"
+}

Changedpost_kabbalah_birth_profile1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "angels": {
+      "items": {
+        "properties": {
+          "choir": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "number": {
+            "type": "number"
+          },
+          "reading": {
+            "type": "string"
+          },
+          "role": {
+            "type": "string"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "traditionalName": {
+            "type": "string"
+          },
+          "window": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "role",
+          "number",
+          "name",
+          "romanization",
+          "traditionalName",
+          "choir",
+          "window",
+          "reading"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "birthData": {
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "time": {
+          "type": "string"
+        },
+        "timezone": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "date",
+        "time",
+        "timezone"
+      ],
+      "type": "object"
+    },
+    "conventions": {
+      "properties": {
+        "afterSunset": {
+          "type": "boolean"
+        },
+        "angelDating": {
+          "type": "string"
+        },
+        "leapDayPolicy": {
+          "type": "string"
+        },
+        "yearStart": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "angelDating",
+        "yearStart",
+        "leapDayPolicy",
+        "afterSunset"
+      ],
+      "type": "object"
+    },
+    "hebrewBirthday": {
+      "properties": {
+        "date": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "hebrewYear": {
+          "type": "number"
+        },
+        "note": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "date",
+        "hebrewYear"
+      ],
+      "type": "object"
+    },
+    "hebrewDate": {
+      "properties": {
+        "afterSunset": {
+          "type": "boolean"
+        },
+        "day": {
+          "type": "number"
+        },
+        "hebrew": {
+          "type": "string"
+        },
+        "leapYear": {
+          "type": "boolean"
+        },
+        "month": {
+          "type": "string"
+        },
+        "monthNumber": {
+          "type": "number"
+        },
+        "year": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "year",
+        "month",
+        "monthNumber",
+        "day",
+        "leapYear",
+        "hebrew",
+        "afterSunset"
+      ],
+      "type": "object"
+    },
+    "sephirah": {
+      "properties": {
+        "english": {
+          "type": "string"
+        },
+        "hebrew": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "meaning": {
+          "type": "string"
+        },
+        "number": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "romanization": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "number",
+        "english",
+        "hebrew",
+        "romanization",
+        "meaning"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "birthData",
+    "hebrewDate",
+    "hebrewBirthday",
+    "angels",
+    "sephirah",
+    "conventions"
+  ],
+  "type": "object"
+}

Changedpost_kabbalah_compatibility1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "band": {
+      "type": "string"
+    },
+    "components": {
+      "items": {
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "matched": {
+            "type": "boolean"
+          },
+          "maximum": {
+            "type": "number"
+          },
+          "points": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "points",
+          "maximum",
+          "matched"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "conventions": {
+      "properties": {
+        "misparGadol": {
+          "type": "string"
+        },
+        "transliteration": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "misparGadol"
+      ],
+      "type": "object"
+    },
+    "first": {
+      "properties": {
+        "hebrew": {
+          "type": "string"
+        },
+        "input": {
+          "type": "string"
+        },
+        "reduced": {
+          "type": "number"
+        },
+        "romanization": {
+          "type": "string"
+        },
+        "rule": {
+          "type": "string"
+        },
+        "sephirah": {
+          "type": "string"
+        },
+        "sephirahEnglish": {
+          "type": "string"
+        },
+        "standard": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "input",
+        "hebrew",
+        "romanization",
+        "rule",
+        "standard",
+        "reduced",
+        "sephirah",
+        "sephirahEnglish"
+      ],
+      "type": "object"
+    },
+    "reading": {
+      "type": "string"
+    },
+    "score": {
+      "type": "number"
+    },
+    "second": {
+      "properties": {
+        "hebrew": {
+          "type": "string"
+        },
+        "input": {
+          "type": "string"
+        },
+        "reduced": {
+          "type": "number"
+        },
+        "romanization": {
+          "type": "string"
+        },
+        "rule": {
+          "type": "string"
+        },
+        "sephirah": {
+          "type": "string"
+        },
+        "sephirahEnglish": {
+          "type": "string"
+        },
+        "standard": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "input",
+        "hebrew",
+        "romanization",
+        "rule",
+        "standard",
+        "reduced",
+        "sephirah",
+        "sephirahEnglish"
+      ],
+      "type": "object"
+    },
+    "sharedValues": {
+      "items": {
+        "properties": {
+          "cipher": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "cipher",
+          "name",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "first",
+    "second",
+    "sharedValues",
+    "score",
+    "band",
+    "components",
+    "reading",
+    "conventions"
+  ],
+  "type": "object"
+}

Changedpost_kabbalah_gematria1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "chosen": {
+      "properties": {
+        "hebrew": {
+          "type": "string"
+        },
+        "rule": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "hebrew",
+        "rule"
+      ],
+      "type": "object"
+    },
+    "conventions": {
+      "properties": {
+        "atbashOutput": {
+          "type": "string"
+        },
+        "misparGadol": {
+          "type": "string"
+        },
+        "transliteration": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "misparGadol",
+        "atbashOutput"
+      ],
+      "type": "object"
+    },
+    "hebrewForms": {
+      "items": {
+        "properties": {
+          "hebrew": {
+            "type": "string"
+          },
+          "letters": {
+            "items": {
+              "properties": {
+                "glyph": {
+                  "type": "string"
+                },
+                "isFinal": {
+                  "type": "boolean"
+                },
+                "letterId": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": "string"
+                },
+                "value": {
+                  "type": "number"
+                }
+              },
+              "required": [
+                "glyph",
+                "letterId",
+                "name",
+                "isFinal",
+                "value"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "rule": {
+            "type": "string"
+          },
+          "values": {
+            "items": {
+              "properties": {
+                "alternateValues": {
+                  "items": {
+                    "type": "number"
+                  },
+                  "type": "array"
+                },
+                "id": {
+                  "type": "string"
+                },
+                "source": {
+                  "type": "string"
+                },
+                "tradition": {
+                  "type": "string"
+                },
+                "value": {
+                  "type": "number"
+                }
+              },
+              "required": [
+                "id",
+                "value",
+                "tradition",
+                "source"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "hebrew",
+          "romanization",
+          "rule",
+          "values",
+          "letters"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "input": {
+      "properties": {
+        "text": {
+          "type": "string"
+        },
+        "textHebrew": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "latinValues": {
+      "items": {
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "lineage": {
+            "type": "string"
+          },
+          "tradition": {
+            "type": "string"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "value",
+          "tradition",
+          "lineage"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "matches": {
+      "items": {
+        "properties": {
+          "hebrew": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "meaning": {
+            "type": "string"
+          },
+          "note": {
+            "type": "string"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "sources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "hebrew",
+          "romanization",
+          "meaning",
+          "value",
+          "note",
+          "sources"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "transformations": {
+      "items": {
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "output": {
+            "type": "string"
+          },
+          "outputRomanization": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          },
+          "tradition": {
+            "type": "string"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "tradition",
+          "source"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "values": {
+      "items": {
+        "properties": {
+          "alternateValues": {
+            "items": {
+              "type": "number"
+            },
+            "type": "array"
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          },
+          "tradition": {
+            "type": "string"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "value",
+          "tradition",
+          "source",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "input",
+    "hebrewForms",
+    "chosen",
+    "values",
+    "transformations",
+    "matches",
+    "conventions"
+  ],
+  "type": "object"
+}

Changedpost_kabbalah_name_profile1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "chosen": {
+      "properties": {
+        "hebrew": {
+          "type": "string"
+        },
+        "romanization": {
+          "type": "string"
+        },
+        "rule": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "hebrew",
+        "romanization",
+        "rule"
+      ],
+      "type": "object"
+    },
+    "conventions": {
+      "properties": {
+        "misparGadol": {
+          "type": "string"
+        },
+        "transliteration": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "misparGadol"
+      ],
+      "type": "object"
+    },
+    "hebrewForms": {
+      "items": {
+        "properties": {
+          "hebrew": {
+            "type": "string"
+          },
+          "letters": {
+            "items": {
+              "properties": {
+                "glyph": {
+                  "type": "string"
+                },
+                "isFinal": {
+                  "type": "boolean"
+                },
+                "letterId": {
+                  "type": "string"
+                },
+                "name": {
+                  "type": "string"
+                },
+                "value": {
+                  "type": "number"
+                }
+              },
+              "required": [
+                "glyph",
+                "letterId",
+                "name",
+                "isFinal",
+                "value"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "rule": {
+            "type": "string"
+          },
+          "values": {
+            "items": {
+              "properties": {
+                "alternateValues": {
+                  "items": {
+                    "type": "number"
+                  },
+                  "type": "array"
+                },
+                "id": {
+                  "type": "string"
+                },
+                "source": {
+                  "type": "string"
+                },
+                "tradition": {
+                  "type": "string"
+                },
+                "value": {
+                  "type": "number"
+                }
+              },
+              "required": [
+                "id",
+                "value",
+                "tradition",
+                "source"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "hebrew",
+          "romanization",
+          "rule",
+          "values",
+          "letters"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "input": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "nameHebrew": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "letters": {
+      "items": {
+        "properties": {
+          "glyph": {
+            "type": "string"
+          },
+          "isFinal": {
+            "type": "boolean"
+          },
+          "letterId": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "glyph",
+          "letterId",
+          "name",
+          "isFinal",
+          "value"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "matches": {
+      "items": {
+        "properties": {
+          "hebrew": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "meaning": {
+            "type": "string"
+          },
+          "note": {
+            "type": "string"
+          },
+          "romanization": {
+            "type": "string"
+          },
+          "sources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "value": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "id",
+          "hebrew",
+          "romanization",
+          "meaning",
+          "value",
+          "note",
+          "sources"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sephirah": {
+      "properties": {
+        "english": {
+          "type": "string"
+        },
+        "hebrew": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "meaning": {
+          "type": "string"
+        },
+        "number": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "reading": {
+          "type": "string"
+        },
+        "reduced": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "id",
+        "number",
+        "english",
+        "hebrew",
+        "reduced",
+        "meaning",
+        "reading"
+      ],
+      "type": "object"
+    },
+    "values": {
+      "properties": {
+        "large": {
+          "type": "number"
+        },
+        "preceding": {
+          "type": "number"
+        },
+        "small": {
+          "type": "number"
+        },
+        "standard": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "standard",
+        "large",
+        "small",
+        "preceding"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "input",
+    "hebrewForms",
+    "chosen",
+    "values",
+    "letters",
+    "sephirah",
+    "matches",
+    "conventions"
+  ],
+  "type": "object"
+}

1 tool updateSep 19, 2026
- Changedget_kabbalah_names_number5 fields changed
  - changedInput schema / examples
```
Previous value: -[
-  {}
-]New value: +[
+  {
+    "number": 27
+  }
+]
```
  - addedInput schema / properties / number / maximum
```
Added value: +72
```
  - addedInput schema / properties / number / minimum
```
Added value: +1
```
  - changedInput schema / properties / number / type
```
Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
```
  - addedInput schema / required
```
Added value: +[
+  "number"
+]
```

1 tool updateSep 16, 2026

Changedpost_kabbalah_birth_profile1 field changed

changedInput schema / properties / timezone / description

Previous value: -"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."

3 tool updatesSep 16, 2026

Changedpost_kabbalah_compatibility2 fields changed

changedInput schema / properties / transliteration / description

Previous value: -"How a Latin name is written in Hebrew before it is scored. One member, a deterministic published letter map. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction, and every published Hebrew standard romanizes the other way. Send textHebrew to control the spelling yourself."New value: +"How a Latin name is written in Hebrew before it is scored. Two members. letter-map-mathers is the 1887 Hermetic letter map, with e read as its author practised it: a point inside a word and alef at the start of one. It writes no c, f, w or x, so a name carrying one of them outside a two letter group returns 400 naming the letter. letter-map-modern follows the modern Israeli transcription rules for the sound each Latin letter carries in English and French spelling, covers every Latin letter, drops the geresh and does not double vav or yod, so send textHebrew for the ktiv male form. Every form states the readings it used in rule. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction."

changedInput schema / properties / transliteration / enum

Previous value: -[
-  "letter-map-mathers"
-]New value: +[
+  "letter-map-mathers",
+  "letter-map-modern"
+]

Changedpost_kabbalah_gematria2 fields changed

changedInput schema / properties / transliteration / description

Previous value: -"How a Latin name is written in Hebrew before it is scored. One member, a deterministic published letter map. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction, and every published Hebrew standard romanizes the other way. Send textHebrew to control the spelling yourself."New value: +"How a Latin name is written in Hebrew before it is scored. Two members. letter-map-mathers is the 1887 Hermetic letter map, with e read as its author practised it: a point inside a word and alef at the start of one. It writes no c, f, w or x, so a name carrying one of them outside a two letter group returns 400 naming the letter. letter-map-modern follows the modern Israeli transcription rules for the sound each Latin letter carries in English and French spelling, covers every Latin letter, drops the geresh and does not double vav or yod, so send textHebrew for the ktiv male form. Every form states the readings it used in rule. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction."

changedInput schema / properties / transliteration / enum

Previous value: -[
-  "letter-map-mathers"
-]New value: +[
+  "letter-map-mathers",
+  "letter-map-modern"
+]

Changedpost_kabbalah_name_profile2 fields changed

changedInput schema / properties / transliteration / description

Previous value: -"How a Latin name is written in Hebrew before it is scored. One member, a deterministic published letter map. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction, and every published Hebrew standard romanizes the other way. Send textHebrew to control the spelling yourself."New value: +"How a Latin name is written in Hebrew before it is scored. Two members. letter-map-mathers is the 1887 Hermetic letter map, with e read as its author practised it: a point inside a word and alef at the start of one. It writes no c, f, w or x, so a name carrying one of them outside a two letter group returns 400 naming the letter. letter-map-modern follows the modern Israeli transcription rules for the sound each Latin letter carries in English and French spelling, covers every Latin letter, drops the geresh and does not double vav or yod, so send textHebrew for the ktiv male form. Every form states the readings it used in rule. Phonetic Ashkenazi and Sephardi schemes are not offered because no two references agree on a rule for that direction."

changedInput schema / properties / transliteration / enum

Previous value: -[
-  "letter-map-mathers"
-]New value: +[
+  "letter-map-mathers",
+  "letter-map-modern"
+]

12 tool updatesSep 6, 2026
- First observedget_kabbalah_ciphers
- First observedget_kabbalah_daily
- First observedget_kabbalah_letters
- First observedget_kabbalah_letters_id
- First observedget_kabbalah_names
- First observedget_kabbalah_names_number
- First observedget_kabbalah_sephirot_id
- First observedget_kabbalah_tree
- First observedpost_kabbalah_birth_profile
- First observedpost_kabbalah_compatibility
- First observedpost_kabbalah_gematria
- First observedpost_kabbalah_name_profile

Related MCP Connectors

Numerology MCP Server by RoxyAPI A
com.roxyapi
Life Path, Expression, karmic debt and Chaldean numerology readings for AI agents.
AI & Machine Learning
202
Human Design MCP Server by RoxyAPI A
com.roxyapi
Human Design bodygraph, type, authority, profile, gates and channels for AI agents.
Health & Wellness
122
Asterwise AOAuth
com.asterwise
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Software Architecture
1031
I Ching MCP Server by RoxyAPI A
com.roxyapi
I Ching hexagram casts, 64 hexagram meanings and changing lines for AI agents.
Art & Culture Education & Learning Tools
92

Related MCP Servers

giskard-memory
Knowledge & Memory Vector Databases Autonomous Agents
giskard09
A
license
Not graded
quality
C
maintenance
Pay-per-use semantic memory for AI agents with cryptographic attestation. Vector embeddings with SHA256 commitment, secp256k1 signature, and Lightning invoice.
Updated 3 months ago (2026-06-12 18:56 UTC)
Apache 2.0
Mark Reynolds
Blockchain Security Legal & Compliance
m-reynaldo35
A
license
Not graded
quality
F
maintenance
Post-quantum document anchoring for AI agents. Anchor any SHA-256 hash to Algorand mainnet with ML-DSA-65 (NIST FIPS-204) signatures and receive a self-contained proof bundle verifiable offline — decades from now, without trusting any vendor.
Updated 3 months ago (2026-06-14 23:28 UTC)
4 npm
MIT
MIND MCP Server
Knowledge & Memory CRM Autonomous Agents
theastraway
A
license
Not graded
quality
B
maintenance
Enables AI agents to persist and retrieve memories via a personal knowledge graph, with tools for emotional intelligence, CRM, life management, social features, self-training, and autonomous insights.
Updated 4 days ago (2026-09-22 20:26 UTC)
1,101 npm
6
MIT
Neo0 MCP Serverofficial
Knowledge & Memory Search AI & Machine Learning
Neo0ai
F
license
Not graded
quality
B
maintenance
A coordinate-based semantic addressing system for AI agents, providing tools to derive immutable addresses, search concepts, and manage personae via the Model Context Protocol.
Updated 2 months ago (2026-07-26 04:32 UTC)
-