Gematria with typed transliteration, the 72 names, Tree of Life and Hebrew birthday for AI agents.
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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, and the description adds useful behavior beyond that: every entry includes definition, provenance class, century, and sources, and the API deliberately prevents conflating rabbinic and Christian/modern traditions. It does not discuss edge cases or limitations, but for a static catalogue list the core behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a few sentences long and front-loads the main action and scope before adding context about provenance and intended audience. It is slightly dense, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a simple list endpoint, the description carries the burden of describing the return payload. It specifies the categories, the per-entry fields, and the semantic guarantee about provenance, which is enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (lang, compact) are fully described in the schema, so the description does not need to repeat them. The description itself adds no parameter-level guidance, which meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a strong verb and concrete object ('Return the full catalogue of gematria methods') and enumerates the exact scope: eleven rabbinic ciphers, two substitution transformations, and three Latin alphabet ciphers. This makes the tool clearly distinct from sibling endpoints focused on names, letters, daily readings, and birth profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the intended use case: calculators that need to show which method produced a number and where the method comes from. It does not explicitly contrast with sibling tools or say when not to use it, but the resource type itself differentiates it clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the Omer count is a real 49-day observance, and outside that window the response explicitly says the count is not running and provides the next opening date. This is useful information an agent cannot infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core return value and output fields, and the second sentence earns its place by explaining the dated-window behavior and typical use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does a good job of naming the main returned items: the sephirah of the week, the sephirah of the day, the Hebrew label, and a composed reading. It also covers the important out-of-window response behavior. It does not fully specify the response shape, but given the self-documenting parameters and read-only nature, the remaining gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all five parameters with descriptions, examples, defaults, and an enum, giving 100% schema description coverage. The tool description does not add parameter-level semantics beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the day of the Omer count for a date' and lists the output fields, so an agent can tell what the tool does. It is clearly distinct from sibling kabbalah tools by its focus on the dated Omer count, but it does not explicitly name or contrast siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names concrete intended use cases: daily widgets, Jewish calendar features, and lifecycle emails, and it specifies the selection criterion 'want a dated reading rather than a random one.' It provides clear context but does not explicitly state when not to use the tool or name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already present, the description adds meaningful context beyond the annotations: the attributions are a 'documented school split rather than a fixed table' and 'the response echoes which one produced the answer.' This explains the flexible nature of the data and the echo behavior, which an agent would not infer from schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core return payload before moving to the school-split nuance and intended use cases. Every sentence earns its place; it could be slightly tighter but is not bloated or repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by enumerating the returned fields and noting that the response echoes the chosen reading. Combined with 100% parameter schema coverage and read-only annotations, an agent has enough context to invoke the tool correctly, though a brief note on the response envelope would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters, including enums, defaults, and the compact format behavior. The description adds only a high-level reference to 'the requested reading' without supplementing the schema's parameter details, 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.
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: 'Return all 22 Hebrew letters' and enumerates exactly which attributes are included (numeric value, final form, class, element/planet/sign, tarot trump, path number). This clearly distinguishes it from sibling get_kabbalah_letters_id, which targets a single letter, by emphasizing 'all 22.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'letter reference pages, tarot apps that render the paths, and any feature that has to say what a letter carries and on whose authority.' It does not explicitly name alternative tools or state when not to use it, but the 'all 22' scope strongly implies the contrast with a single-letter endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
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 context about what the call returns and flags that the element/planet/sign depends on 'the requested reading', which is a useful behavioral link to the letterAttribution parameter. It does not go deeper into response shape or edge behavior, but for a read-only getter with a thorough schema this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the first front-loads the action and enumerates the return fields, which is justified because there is no output schema; the second states the use case and contrasts with the all-22 call. The first sentence is dense, but every item in it adds agent-usable information about the response payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, and a readOnly annotation, the description fills the main gap — the absence of an output schema — by enumerating every return field. Combined with the schema, an agent knows what to pass, what to expect back, and when to prefer this over the multi-letter endpoint. The only minor omission is a description of the JSON response envelope, which is not critical for a single-letter detail call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (id enum with 22 values, lang, compact, letterAttribution) are documented inside the schema itself, putting the baseline at 3. The description's only param-adjacent contribution is 'under the requested reading', which reinforces the letterAttribution dependency without adding enum-level detail. No gap to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Return one Hebrew letter in full') and enumerates exactly what comes back: glyph and final form, both gematria readings, Sefer Yetzirah class and meaning, element/planet/sign, tarot trump, and path number. It also carves out its niche against the all-22 helper by stating 'one row rather than all 22 letters', which distinguishes it from sibling 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence names the target context ('Built for letter detail pages') and the audience ('any reader who wants one row rather than all 22 letters'), giving a clear when-to-use signal and an implied exclusion of the full-list sibling. It does not name that alternative explicitly or lay out selection logic among the letter-family endpoints, so it stops just short of the explicit when/when-not bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, lowering the bar. The description adds genuinely useful behavioral context beyond that: the names are DERIVED via boustrophedon reading rather than copied from a table, and rows where a named published list differs are flagged — disclosing that outputs may intentionally diverge from published sources. The longitude mode switch is also disclosed. It does not cover response shape or pagination behavior, but no output schema exists and the core behavioral traits are well surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the return payload is front-loaded first, the derivation/discrepancy-flag behavior second, and the invocation mode plus use cases third. There is no filler, tautology, or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 5 documented parameters and no output schema, the description covers the essential return contract (six per-row fields), the provenance caveat, and the alternative single-name mode. Minor gaps exist — the exact shape of the discrepancy flag and the response envelope are unspecified — but nothing an agent needs to call the tool or interpret its results is fundamentally missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents all five parameters (lang, limit, offset, compact, longitude). The description adds minimal parameter-level meaning: it reinforces longitude's mode-switching behavior and explains the five-degree arc concept, but adds nothing about lang, limit, offset, or compact beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb ('Return') and resource (the seventy two names) with an exhaustive field list: three letters, divine name suffix, five-degree ecliptic arc, sign, and angelic choir. This field-level specificity clearly distinguishes it from siblings like get_kabbalah_names_number, get_kabbalah_letters, and get_kabbalah_ciphers without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases ('birth angel features, Shem HaMephorash reference pages') and an explicit invocation mode ('Pass a longitude to get the single name governing that degree'). It stops short of naming sibling alternatives or stating when not to use it, so exclusions are absent, but the context is clear 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.
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.
| 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 | No | 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. |
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 valuable behavior beyond annotations: it explains that the response includes the exact verse positions so readers can verify the derivation rather than trust it, and it lists the specific data components returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, front-loaded with the main action and followed by useful context. Each sentence earns its place: the first states behavior and output, the second explains the design rationale, and the third gives a concrete use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a simple read-only tool: it explains the return content and intended use, and no output schema exists to shift that burden. However, the number parameter is optional in the schema while the description implies an index is needed, and the description does not clarify what happens when number is omitted or out of range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents lang, number, and compact clearly. The description adds little parameter-specific meaning beyond restating the idea of retrieving a name by index, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: returning one of the seventy two names by index, and enumerates the fields that will be included. It is distinguishable from the plural sibling get_kabbalah_names by the singular 'one... by its index', but it does not explicitly name that sibling or draw a contrast, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose implies it should be used when a single name is needed by index, and the closing phrase 'built for birth angel detail pages and reference features' gives some context. However, it gives no explicit guidance on when to prefer the list-style sibling tool, and it does not state exclusions such as what happens if the optional number parameter is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
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 genuinely useful behavior beyond that: Daat is addressable and 'its response says plainly that it is counted in some diagrams and not in others,' pre-disclosing an edge case an agent would otherwise hit at runtime. It also previews response content, which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first is a dense but organized enumeration of return fields, the second covers the Daat edge case, and the third states intended use cases. The primary action is front-loaded and there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden — and it delivers a nearly complete field list, which is rare. Combined with 100% schema parameter coverage and read-only annotations, nothing an agent needs to call this correctly is missing; the Daat special case is even pre-disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself already documents all five parameters, including enums, defaults, and the sephirotSystem/letterAttribution disagreement notes. The description adds only a light tie-in ('the sphere it carries under the requested system') without new parameter-level detail, matching the baseline-3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Return one sephirah in full' — and enumerates exact return fields: Hebrew and English names, pillar, world, sphere, emanation meaning, and every touching path with its letter and tarot trump. This scope clearly distinguishes it from siblings like get_kabbalah_tree (whole tree at once) and get_kabbalah_letters_id (single letter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence gives concrete usage context: 'Built for sephirot detail pages and for tree diagrams that load one node at a time.' This implies when to prefer it over fetching a whole tree, but it never names an alternative explicitly or states a when-not-to-use condition, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond that: school splits are typed request parameters rather than hidden defaults, and the response echoes which arrangement and reading produced it. This helps an agent understand that variant selection is explicit and observable in the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: the first enumerates return contents, the second clarifies behavior around variants and echo, and the third gives concrete use cases. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only whole-tree retrieval tool with no output schema, the description covers the main return contents and the key behavioral nuance of echoed variants. It could go slightly further in describing the response shape or compact mode, but those details are available in the schema and the description is otherwise complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already documents each parameter. The description reinforces that school variants are typed parameters rather than hidden defaults, but it does not add new semantic detail about individual parameter values beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names the exact resource: the whole Tree of Life with ten sephirot, Daat, 22 paths, four worlds, and lightning flash order. It clearly differentiates itself from granular sibling endpoints by emphasizing 'whole Tree of Life in one call' and by stating it is built for diagram and reference use rather than a picture or individual element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it for Tree of Life diagrams, tarot path features, and reference pages needing structure rather than an image. It does not explicitly name sibling alternatives or state when not to use it, but the 'whole tree in one call' framing and target use cases make the appropriate context reasonably explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 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. | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal readOnly=true and destructive false. The description adds genuine behavioral context: the Hebrew date is 'computed from the published calendar algorithm rather than looked up', the sunset boundary is a caller assertion rather than a computation, and the two dating conventions are explicitly called out as conventions the response echoes. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences each earn their place: the first lists what is returned, the second explains the two non-obvious design decisions, and the third names target audiences. It is front-loaded with the most important information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 4 enums, and no output schema, the description does well: it enumerates the returned data, explains the calendar and dating conventions that could otherwise be confusing, and states the intended product contexts. It stops short of a 5 because there is no explicit mention of response shape or error behavior, though the rich schema and annotations cover most operational needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 9 parameters well. The description adds useful conceptual context about why afterSunset and angelDating are typed request fields, but it does not add new parameter-level syntax, constraints, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the Hebrew date of a birth, the Hebrew birthday that follows it, the three birth names... and the sephirah of the birth day.' This precisely enumerates what the tool produces and clearly distinguishes it from siblings like post_kabbalah_name_profile by anchoring the output to a single birth moment and Hebrew birthday concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear intended use cases: '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.' However, it never explicitly tells an agent when to choose this tool over a sibling or when not to use it, so usage remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. 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. | letter-map-mathers |
| secondNameHebrew | No | Second name already in Hebrew, which skips the transliteration step. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, so the description adds valuable behavioral context: it discloses that the composite is partly proprietary, that the classical method only covers equal value under the standard reading, and that the response itself marks which parts are ours. This lets callers decide whether to recompute or ignore components, which is far beyond the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three information-dense sentences, each earning its place: what the tool returns, how the composite weighting works, and when to use it. Slightly wordy around 'every component and its maximum published beside it,' but overall well-structured and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a useful conceptual response map: profiles, agreeing ciphers, and a composite with component maxima. It does not spell out exact field names or compact/lang behaviors, but the schema covers parameters and the description gives enough for correct invocation and expectation-setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond echoing the two-name concept, but it does not need to because every parameter is already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Score two names against each other in gematria,' and then enumerates the return components: both profiles, agreeing ciphers, and a composite with published maxima. This clearly differentiates it from single-name profile or cipher sibling tools by centering on pairwise name compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use contexts: 'name compatibility features, relationship content and any product that wants a number it can show the arithmetic for.' It does not explicitly name alternatives or state when not to use it, but the intended scenarios are concrete enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. 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. | letter-map-mathers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false annotations, the safety profile is already clear, and the description adds significant behavioral detail: Latin names lack a single Hebrew spelling so every candidate spelling comes back with its own values and the chosen one is named; the substitution ciphers AtBash/Albam are explained as returning strings and/or values; non-Hebrew text is folded; and vowel points are removed. The description also clarifies the response includes matches and the rationale for each number, which is exactly the kind of behavioral context beyond annotations that helps an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core function, follows with the important caveat about Latin names and the per-candidate rule naming, and ends with use cases. It is information-dense but not bloated; every sentence adds a distinct fact. It loses a point because the opening is a long sentence with many clauses (ten ciphers, two substitutions, per-letter breakdown, curated matches) that could be split for easier parsing by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 optional parameters and no output schema, the description, combined with 100% schema coverage, covers the essential behavior: input types (Latin vs. Hebrew), transliteration rationale, cipher selection, output shape hints (per-letter breakdown, matches, columns/rows compact shape), and language fallback. The sibling tool names indicate a wider gematria family, but this tool's role is distinct and fully explained. Nothing important appears missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description still adds meaning above the schema by explaining the overall flow: a Latin name is first transliterated, then scored, and the chosen spelling is named. It also provides context for the transliteration parameter's rationale (why only one deterministic map exists) and clarifies the purpose of the compact, includeMatches, and latinCiphers parameters. Since every parameter has its own schema description, the marginal value is solid but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Score') and identifies the exact resource and scope: Hebrew/Latin words across ten gematria ciphers, with per-letter breakdowns, matches, and transliteration behavior. It distinguishes itself from sibling tools by clearly explaining that it handles both Latin and Hebrew input and returns multiple ciphers, whereas siblings like get_kabbalah_ciphers or get_kabbalah_daily have different scopes. The opening sentence directly tells an agent what computation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the intended use cases: 'Built for name meaning features, numerology apps... and any product that has to show a reader why the number is what it is.' This gives clear when-to-use context. It doesn't explicitly exclude alternatives among the siblings, but the sibling suite appears to have distinct getters for daily readings, letters, names, tree, and profiles, so the application context is sufficient to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. 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. | letter-map-mathers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral richness beyond that: it surfaces multiple candidate Hebrew spellings, names the chosen one, and enumerates the response contents including readings, per-letter breakdown, sephirah, and curated shared-value words. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, front-loaded sentences: the first defines the core behavior and differentiator, the second inventories the response and target use cases. Every clause earns its place and there is no filler or circular wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 3 enums, and no output schema, the description compensates by describing the response shape and intended contexts. It relies appropriately on the schema for parameter semantics; a minor gap is that it does not explicitly state that one of name or nameHebrew must be provided, though the schema makes that discoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description alludes to spelling selection and transliteration nuance, which connects to name/nameHebrew/transliteration, but it does not add parameter-level details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Score a name'), the method ('rabbinic gematria ciphers', 'Tree of Life'), and the distinctive output ('every candidate Hebrew spelling shown and the chosen one named'). This separates it from sibling gematria or name tools by framing it as a full name-reading profile rather than a simple cipher lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete intended use cases: '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, though it does not explicitly name sibling alternatives or states when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_kabbalah_ciphersget_kabbalah_dailyget_kabbalah_lettersget_kabbalah_letters_idget_kabbalah_namesget_kabbalah_names_numberget_kabbalah_sephirot_idget_kabbalah_treepost_kabbalah_birth_profilepost_kabbalah_compatibilitypost_kabbalah_gematriapost_kabbalah_name_profileClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Life Path, Expression, karmic debt and Chaldean numerology readings for AI agents.
Human Design bodygraph, type, authority, profile, gates and channels for AI agents.
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
I Ching hexagram casts, 64 hexagram meanings and changing lines for AI agents.
Add one secure layer between your agents and this server.
Most tools are cleanly separated by resource and verb: collection/detail variants exist for letters and names, tree vs single sephirah is clear, and compute endpoints are distinct. The only meaningful overlap is post_kabbalah_gematria and post_kabbalah_name_profile, which both score a name across gematria ciphers and display candidate Hebrew spellings; the descriptions differentiate their outputs but an agent could easily select the wrong one.
Every tool follows the same verb_kabbalah_resource pattern, with get_ for reference lookups and post_ for computations. snake_case is used throughout, and detail variants are marked consistently with _id or _number.
Twelve tools is well within the ideal range and each tool covers a distinct area: catalogues, letters, names, sephirot/tree, daily Omer, and name calculations. The surface is broad enough to be useful without feeling inflated.
The API covers the core domain comprehensively: reference data for ciphers, letters, 72 names, sephirot/tree, dated Omer count, and the main name-scoring operations including compatibility. CRUD is not applicable for a read-only/compute server, and get_kabbalah_tree already provides collection-level sephirot data, so there are no obvious dead ends.