Numerology MCP Server by RoxyAPI

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

Annotations already mark the tool read-only, so the description does not need to repeat that. It instead discloses substantive behavior: each result includes a symbolic title, nature, and full interpretation, and numbers 33 to 52 return a sameAs pointer to a lower number. This is useful behavioral detail beyond the annotations.

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

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

The description is information-dense and front-loaded with the core lookup behavior, then return structure, then edge-case behavior. The final 'Perfect for' sentence is slightly promotional but does not waste much space.

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?

There is no output schema, so the description takes on the responsibility of describing the returned fields, which it does clearly: symbolic title, nature, interpretation, and sameAs behavior. It also covers the number range, the Cheiro source, and the tool's role in numerology workflows. This makes the tool safe and expected for an agent to call 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?

The input schema's descriptions already cover 100% of the parameters, including number, lang, and compact. The description adds no new parameter semantics beyond illustrative examples like The Wheel of Fortune for 10, so it is neither detrimental nor heavily compensatory.

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: 'Get the classical Chaldean interpretation of a compound number ... from 10 to 52'. It also sets clear scope by explaining compound numbers as unreduced two-digit numbers that go beyond the single-digit root, which differentiates it from ordinary numerology lookups and the sibling get_numerology_meanings_number.

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 'Perfect for Chaldean numerology references, compound number lookups, and AI numerology tools' gives clear usage context. However, it does not explicitly tell the agent when not to use this tool or name an alternative for single-digit number meanings, so it falls short of full when/when-not guidance.

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

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

Annotations already show readOnlyHint=true and destructiveHint=false, so this is clearly a safe read. The description adds useful behavior beyond that: response length of 300-500 words, expert-written content, included fields, and special handling of master numbers 11, 22, and 33 with their reduced base number.

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 main purpose and then adds useful details about output content and lengths. It is slightly redundant in that both the first and last sentences emphasize that complete meanings are returned, but overall it is compact and scannable.

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 the lack of an output schema, the description provides a strong outline of what will be returned: archetype title, keywords, personality traits, strengths, weaknesses, career guidance, relationship dynamics, and spiritual insights. It also covers master-number expansion behavior and output length, which gives an agent enough context for selection and invocation.

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

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

Schema coverage is 100%, so the schema already explains number, lang, and compact well. The description reinforces the allowed number range and clarifies the master-number behavior, but it does not add meaningful semantic details for lang or compact 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 states a specific action and resource: get the complete numerology meaning for any valid number (1-9, 11, 22, 33). It also scopes the tool to Pythagorean numerology and enumerates the 12 valid numbers, which distinguishes it from sibling tools like the Chaldean or compound-number tools.

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 explicitly lists applicable use cases: 'numerology reference tools, educational apps, quick lookups, and building custom numerology calculators.' This gives clear context for when to use the tool, though it never explicitly mentions when-not-to-use it or points to an alternative sibling.

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

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

Annotations already declare this as read-only and non-destructive. The description adds behavioral detail beyond annotations: it automatically detects Master Numbers, reduces double-digit days, and returns 300-500 word interpretations with specific thematic content. This gives an agent useful expectations about the computation and 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 front-loaded with the core action and meaning, and the later sentences provide behavioral and use-case context. It is somewhat longer than strictly necessary, with promotional phrases like 'Perfect for talent discovery apps', but every section serves some purpose.

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 three parameters, no output schema, and no nested objects, the description covers the main behavior, Master Number handling, output length, and use-case domain. It does not fully define the exact response structure, but the description is complete enough for an agent to decide when and how to call 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 input schema already documents all parameters, including day constraints, lang enum, and compact behavior. The description adds minor conceptual context about the day parameter but does not meaningfully extend the schema's parameter semantics.

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

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

The first sentence clearly states the verb ('Calculate'), the resource ('Birth Day number'), and the input ('day you were born 1-31'). It also describes the meaning ('special talents and abilities'), so an agent can identify the tool's unique purpose. However, it does not explicitly contrast itself with sibling tools like life_path or expression.

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 provides clear use-case guidance through 'Perfect for talent discovery apps, career counseling platforms, personal development services, and skill assessment tools.' It implies when to use this tool but does not explicitly state when not to use it or name alternatives, so it falls short of a full exclusion-based recommendation.

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

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

Annotations already flag readOnlyHint=true and destructiveHint=false, so the safety bar is lower. The description adds genuine behaviorial value beyond the annotations by explaining the internal computation steps, the 0–8 meaning (0 aligned, higher=friction) and the need for four internally derived core numbers.

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 material is front-loaded with the outcome and the pair list, followed by the interpretation stretched. The trailing sentence reiterates the both-inputs requirement and implies the internal calculation of all four core numbers, which mildly restates earlier content; the sentence about clearly 'portant for personal development / coaching applications' is contextual noise. Still, overall condense and well-organized.

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 present, the description must do more to tell the agent what to expect back. It interprets the return values well (0=aligned, higher=tension) and gives the three exact outputs; however it remains silent on the response shape (e.g., an object vs a list, whether guidance text is included). Moderately complex to agent, this is a notable residue but not a blocking gap.

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

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

Schema description coverage is 100%, so the baseline of 3 applies; each parameter is already explained well within the schema (e.g., name→Calculates Expression/Soul/Urge, spirit; year→Pythagorean Life Path). The description only adds the redundant note about needing both name and date, which is useful but does not materially enrich the parameter semantics.

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

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

The description states the exact verb (calculate), resource (three Bridge Numbers), and outcome (harmony between aspects), and names the three pairs: Life Path–Expression, Expression–Personality, Expression–Soul Urge. This stands apart from sibling tools like post_numerology_expression or post_numerology_compatibility by making clear it aggregates internicians, the role of the pairs clarifies the distinct function.

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 invocation context – use when career need to harmonize differing personality aspects – and states an explicit prerequisite (both full name and birth date must be present). It does not explicitly enumerate which sibling tools cover the alternative, single core-number, use case, so no firm exclusions, leaving a minor gap.

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

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

Annotations already 'offer' read-only and non-destructive safety, so the description carries less burden. It goes beyond that by naming the exact return pieces (compound/root number, planetary ruler, rating, favored industries, Cheiro status) and adding a clear caveat: 'This is a positioning guidance layered over the fundamentals... not a guarantee.' This is honest and useful for 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.

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

The description is compact and front-loaded: it starges the purpose, enumerates the key outputs, highlights the most relevant numbers, and gives use cases and a caveat. Every sentence contributes to understanding the tool. The phrase 'the system practitioners use for trade names' adds tone but is not essential; still, the overall structure is efficient.

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 the important work of listing the expected return fields (compound and root number, planetary ruler, rating, industries, Cheiro fortune) and giving interpretation context for critical numbers like 4 and 8. It's enough for an agent to know what to expect from a business-name check. It doesn't document the exact JSON shape, but that is a minor gap when the semantic results are clearly named.

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 schema covers all three parameters with descriptions, so the baseline is 3. The natural description reinforces the 'name' semantics by calling it a business or brand name, but it adds no extra detail about 'lang' or 'compact' beyond what the schema already provides. No negative signals either; the baseline is acceptable.

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 starts with a definite verb and resource: 'Analyze a business or brand name with Chaldean numerology.' It clearly distinguishes itself from sibling personal-number tools by emphasizing business names and trade names, and enumerates specific outputs like the compound and root number and planetary ruler. This is not tautological and leaves no ambiguity about what the tool selects with exceptional clarity.

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?

'Use it to vet a company name, compare brand options, or guide a naming decision' gives a crystal-clear purpose for use. It doesn't explicitly mention when not to use this tool or name alternative tools, but the context signals and the specialized business-name scope make the choice almost self-evident among all sibling numerology tools. A small explicit 'not for personal name readings' would push this to 5.

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

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

The description adds substantial behavioral detail beyond the read-only annotations: it discloses the mapping of letters to values 1-8, the sacred exlusion of 9, the use of unreduced two-digit compound numbers, and the specific returned components including Cheiro interpretations, planetary ruler, and karmic caution flags. It fully aligns with the annotations and gives the agent a strong mental model of the tool's behavior.

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

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

The description is longer than average but every sentence contributes distinct information: the Chaldean system, compound number treatment, return contents, and ideal use case. It is front-loaded with the core purpose and minimizes fluff, though the final 'Perfect for' sentence is somewhat marketing-style and could be trimmed without losing essential meaning.

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?

Even without an output schema, the description clearly states what the response will contain: Destiny, Soul Urge, and Personality, each with compound number, root, and Cheiro interpretation, plus planetary ruler and a caution flag. The presence of full schema documentation for all parameters and the read-only annotations makes the definition complete enough for an agent to call it correctly on the first try.

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%, with detailed descriptions for name, lang, and compact. The tool description does not add new parameter-specific semantics beyond what the schema already provides, so the baseline of 3 applies. The description adds context about the reading itself but not directly about parameter formats or meanings.

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: 'Calculate a complete Chaldean numerology reading for a name.' It clearly distinguishes this tool from siblings by emphasizing the Chaldean mapping, the unreduced compound number, and the combined Destiny, Soul Urge, and Personality outputs. This is not a tautology and leaves no ambiguity about what the tool does.

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

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

The description gives clear contextual use: it is for use cases needing both compound and root layers in one call and for Chaldean rather than other numerology systems. However, it does not explicitly name alternatives or state when not to use this tool, even though several sibling tools cover individual aspects like soul urge or personality. It falls just short of explicit when-when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds behavioral context beyond those annotations by revealing that one call returns an aggregated bundle containing interpretations, karmic analysis, yearly forecast, and a holistic summary, plus the compact-mode cost savings. 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?

The first sentence succeeds in front-loading the main purpose. However, later sentences include promotional filler like 'Perfect for numerology apps, complete reading services...' and 'Ideal for generating PDF reports...' that repeat the single-endpoint value and don't sharpen the agent's ability to call the tool correctly.

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?

Despite having no output schema, the description conveys what a caller should expect: detailed interpretations, karmic analysis, yearly forecast, and summary. Input requirements are fully covered by schema plus examples. It could be stronger by sketching the exact JSON output shape, but for the purpose of selecting and calling the tool, it is largely 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?

All 7 parameters are described in the schema with 100% coverage, so the description doesn't need to repeat parameter details. It correctly implies that birth data and fullName are required inputs, but it doesn't add any parameter-specific meaning beyond the schema.

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

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

The description clearly states the action ('Generate'), the resource ('a comprehensive numerology chart'), and exactly which calculations are included. The phrase 'single endpoint provides everything needed for a full numerology reading' distinguishes it from the many individual numerology endpoints in the sibling list.

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 explicitly tells you when to use this tool: when you need a complete chart and want to avoid multiple API calls. It doesn't explicitly name individual sibling endpoints as alternatives for narrower queries, so it stops short of full when-not-to-use guidance.

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

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

Annotations already mark this as read-only and non-destructive, so no side-effect warnings are needed. The description importantly reveals what happens with input modes—numbers, raw name/birthdate, or a mix—and what the output will contain: a weighted 0-100 score, aspect scores, strengths, challenges, and advice.

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

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

The core functional sentences are dense and useful, but the ending has promotional filler about dating apps and 'actionable insights' that does not help an agent select or invoke the tool. The key behavioral and output info is still early enough, but the description could be tightened.

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?

There is no output schema, but the description makes up for it by describing the composite score, individual aspect weights, and the strengths/challenges/advice outputs. It does not discuss validation or precedence behavior for partially filled input modes, but enough is present for reliable tool use.

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

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

With 50% schema description coverage, the description adds real semantics beyond the schema by explaining the family of usable inputs per person and the fact that the two input modes can be mixed. It does not need to re-export lang or compact details because the schema already covers those cleanly.

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 a declarative and specific resource: 'Calculate numerology compatibility between two people using Pythagorean numerology.' It stands apart from sibling tools such as post_numerology_life_path or post_numerology_soul_urge because it is explicitly a two-person compatibility analysis, not a single-number reading.

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 contextual use cases like dating apps, relationship counseling, and matchmaking, and clearly describes the two supported input modes. However, it does not explicitly say when not to use this tool or direct the agent to a single-person sibling tool for one-person numerology questions.

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

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

The description adds meaningful behavioral detail beyond the readOnly annotation: seeded randomness ensures the same seed plus date produces the same result. It also discloses that the response includes interpretation fields such as archetype, keywords, strengths, challenges, career, relationships, and spiritual insights. 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?

The description is concise and front-loaded: it states purpose, reproducibility, and return value quickly. The 'perfect for' and 'ideal for' phrases add context but are slightly promotional.

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 usefully lists inside categories returned. Optional params are thoroughly handled in the schema, and the readOnlyFeature remains baked by annotations. 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.

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

All four parameters are already fully documented in the schema, so the description does not need to repeat them. The description reinforces the seed parameter's purpose, but adds little beyond the schema's own 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?

The description clearly states the resource is a daily numerology number (1-9, 11, 22, 33) and that it returns a full interpretation. It is distinct enough to identify the tool's main purpose, though it does not explicitly differentiate from any of the many sibling numerology tools.

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 provides strong application context: 'Number of the Day' features, wellness platforms, daily push notifications, and morning briefings. It also explains when deterministic seeded readings are useful. However, it does not explicitly say when not to use this tool or which sibling tool to choose instead.

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

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

The description adds meaningful behavioral detail beyond the readOnlyHint and destructiveHint annotations: it explains calculation rules, master number preservation, the compound-to-root reduction in Chaldean, and the presence of an agreement flag in the response. It discloses what the call returns and how the systems differ 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.

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

The description is front-loaded with the core action and purpose, and the additional system explanations earn their place by clarifying what distinguishes the two numerology methods. It is slightly longer than strictly necessary, but the details are relevant and useful for selecting this tool over similar numerology endpoints.

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 summarizing what the agent will receive: Pythagorean and Chaldean results, interpretations, and an agreement flag. The input schema fully covers the required 'name' and optional 'lang' and 'compact' parameters, so nothing essential is missing for an agent to make a correct 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%, and the schema already documents each parameter including the 'name' field and the meaning of 'compact'. The description adds general context about the overall calculation, but it does not add meaningful per-parameter insight beyond what the schema already provides, 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 states exactly what the tool does: calculate a name number in both Pythagorean and Chaldean systems in a single request. It clearly distinguishes itself from sibling tools by emphasizing that it is 'the only numerology API that returns Pythagorean and Chaldean for a name in a single request.' This gives an agent a precise, non-tautological understanding of the tool's role.

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 clearly signals when this tool is appropriate: when a comparison between the two numerology systems is needed, and it explicitly frames itself as ideal for comparison tools and AI assistants. It does not, however, explicitly name sibling alternatives or spell out when not to use it, such as 'use post_numerology_chaldean if only the Chaldean number is needed.'

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

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses important behavior: it 'automatically detects Master Numbers', returns a 300-500 word meaning, and covers personality, career, relationships, and spiritual insights. It also clarifies that full birth name is required. Better than average because it gives meaningful insight into output and processing 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.

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

The description is front-loaded with the core definition and includes useful behavioral details. It is relatively efficient, but it has a mildly promotional final sentence ('Perfect for...') and some repetition in explaining that the number reveals talents and life purpose. This keeps it just below a top score for conciseness.

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 that there is no output schema, the description does a good job of describing what is returned. It covers the input, method (Pythagorean), and the content areas of the interpretation, plus master numbers detection. It could be even richer, for instance by describing the returned JSON structure, but the description is sufficient for an agent to correctly call 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?

The input schema already covers all parameters with descriptions, so the metadata base for these params is high. The description refers back to 'full birth name' but does not add much beyond what the schema already says about fullName. It does not enrich the meaning of lang or compact, so a 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 identifies the operation: 'Calculate your Expression (Destiny) number from your full birth name using Pythagorean numerology.' It also specifies the output scope (natural talents, life goals, personality/career/relationship/spiritual insights). It does not explicitly contrast with siblings like personality or soul urge, but the focus on the Expression number and full birth name makes the tool distinguishable.

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 some usage context by listing 'name numerology apps, career guidance tools, personal development platforms, and talent assessment services.' However, it does not explain when to choose this tool over the many sibling numerology tools, nor when not to use it. The intended use is 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.

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

The readOnlyHint and destructiveHint annotations already establish the tool is a safe read operation. The description adds useful context about the reduction process and return value composition (challenges, resolution strategies). It does not cover edge cases like what happens when no karmic debt number is present, but with annotations present, this is an acceptable disclosure level.

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

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

The core functional statement is clear and front-loaded, but the final marketing sentence listing spiritual growth apps and past life services adds little value for an AI agent selecting the tool. The description is reasonably sized but could be more tightly focused without this 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?

Given the tool has no output schema, the description helpfully mentions the return items: debt descriptions, challenges, and resolution guidance. It also indicates the calculations covered and makes reasonable assumptions to complete. Remaining details like default behavior when multiple karmic debts are found, are not essential for invocation given the schema and annotations.

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 schema covers all 6 parameters with detailed descriptions (e.g., month, day, year for Life Path; fullName for other calculations). The description adds no parameter-level details beyond what the schema already communicates, so the baseline 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 clearly states the tool checks for Karmic Debt numbers (13, 14, 16, 19) across specific numerology calculations, using a specific methodology (Pythagorean numerology). It is clear about the subject matter and scope, but it does not explicitly distinguish itself from its closest siblings like post_numerology_karmic_lessons, so it stops short of full differentiation.

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 provides clear context for when to use the tool, including applicable use cases ('spiritual growth apps, karmic astrology platforms') and the specific calculations it applies to. However, it lacks explicit exclusions or guidance about when to use an alternative tool, such as post_numerology_karmic_lessons.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds useful behavioral context, including how lessons are derived, what the output includes, and the emphasis on challenges and practical guidance, going beyond the bare annotation flags.

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 well-structured, front-loading the core function, then the operating rule, then the deliverable. Every sentence earns its place, and the text is appropriately sized for a numerology analysis tool with moderate complexity.

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 compensates by naming the returned information prominently. It also gives relevant use-case contexts and covers the input requirement of a full birth name. Minor details like edge cases or response format nuances are not stated, but the essential value is 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?

The schema already provides 100% coverage for all parameters, including descriptions, defaults, and the language enum. The description mentions the full name but does not materially add parameter semantics beyond what the schema already states, 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 target: 'Analyze your Karmic Lessons from your birth name using Pythagorean numerology.' It defines the core concept precisely, linking it to missing numbers 1-9. This clearly separates it from sibling tools like karmic debt, birth day, or compound number.

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 for the tool's use case, emphasizing when it is relevant, such as spiritual growth apps and personal development platforms. There is no explicit comparison or exclusion of sibling tools, but the distinct mechanism 'numbers missing from your name' effectively implies when to select it.

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

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

Beyond the readOnlyHint and non-destructiveHint annotations, the description adds valuable behavioral context by disclosing automatic detection of Master Numbers and Karmic Debt numbers, and confirming the output includes detailed 300-500 word interpretations with categories. This meaningfully expands on what the schema alone does not reveal about the tool's behavior.

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

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

The description is informative but somewhat overstuffed with promotional and generic use-case language, such as 'Perfect for numerology apps' and 'most significant.' The first sentence is clear and front-loaded, but the second half is more marketing-driven than instruction-driven. While not excessively long, it could be tightened to focus solely on the calculation and output.

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 offers a good high-level outline of the output, including the types of interpretation and typical length, which is helpful because there is no output schema. However, it does not specify the exact response structure, field names, or how the compact parameter affects the result shape. Given the five-parameter surface and no output schema, a little more concrete detail on return format 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?

The input schema has 100% description coverage for all five parameters, including clear ranges, examples, and defaults. The description does not need to repeat these details, and it accurately references the core birth-date inputs. There is no added semantic information about parameters beyond the schema, so the baseline 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 clearly states the tool calculates the Life Path number from a birth date using Pythagorean numerology, which is a specific verb plus resource. It also adds meaningful context about output content and special number detection. However, it does not explicitly differentiate itself from the many sibling numerology tools, such as post_numerology_karmic_debt or post_numerology_compatibility, even though it mentions those topics.

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

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

The description implies the tool is for general Life Path readings, but gives no explicit guidance on when to choose this tool over siblings like post_numerology_karmic_debt or post_numerology_compatibility. Mentioning relationship compatibility and Karmic Debt numbers in this description could actually mislead an agent into selecting the wrong, more specialized tool.

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

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

Annotations already mark it read-only and non-destructive. The description adds meaningful extra behavioral detail: it automatically detects Master Numbers and returns interpretative results in the specified manner and depth. It does not contradict the annotations and goes beyond the annotation-only safety profile by describing useful operational behavior.

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

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

The description front-loads the core purpose and computation, then gives output type, scope, and master number behavior. It avoids overly deep structure, but retains a few promotional contextually less central phrases. There is minor redundancy with the title, but the definition preserves useful detail without exceeding the intended.

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?

There is no output schema, so the description fills that gap by describing the returned interpretation and rough length. It also covers Master Numbers and the domain. It gives an agent enough info to know what inputs will do, what output to expect, and whether this is the right tool for a general request about later life or maturity.

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 schema covers all parameters clearly, and the description adds a layer not visible in the schema: that the two central inputs (Life Path and Expression) are combined to produce the Maturity number. This helps an agent understand why both parameters exist and how the computation algorithm is structured, beyond the basic 'birth date' versus 'direct number' guidance.

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?

Description opens with a specific verb and resource: 'Calculate your Maturity (Realization) number by adding Life Path and Expression numbers using Pythagorean numerology.' It clearly defines what the tool computes and why it differs from sibling tools that only compute Life Path or Expression numbers, by presenting the combination and later-life focus.

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?

Clearly establishes the use case by describing when the Number manifests, that it is relevant for midlife guidance, and which application types should use it. It does not name alternatives or explicitly state when not to use this tool, but it is directional enough for an agent to route to it for maturity-focused calculations.

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

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

With readOnlyHint=true and destructiveHint=false already present, the description adds useful behavioral context by stating it returns a daily theme, actionable guidance, and parent month and year context. It does not contradict the annotations and reasonably describes the behavioral output and personalization logic.

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

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

The core action is front-loaded, and the description is structured logically: calculate → explain → differentiate → describe output. It is slightly verbose because of the repeated positioning around daily/personalized content and a somewhat broad use-case list, but none of the content feels misleading.

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 clear return summary: daily theme, actionable guidance, and parent month and year context. It also gives enough context about options and personalization to guide usage. Minor gaps like target date defaulting and timezone behavior are covered by the schema, so this description is not required to repeat them.

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 each parameter is already documented. The description adds a relationship between birth month/day and target date, but it does not materially expand on parameter meaning beyond the schema's own descriptions.

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 states a specific verb and resource: 'Calculate your Personal Day number from birth month, day, and a target date.' It also differentiates the tool from generic daily numerology by saying 'Unlike generic daily numbers, this is based on YOUR birth data combined with the calendar date.'

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: daily push notifications, morning briefings, calendar widgets, daily content generation, and life coaching tools. It also implies when to choose this tool over a generic daily numerology tool, though it does not name alternative sibling tools or describe explicit when-not conditions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: 'returns comprehensive interpretation including public image, personality, professional presence', 'takes automatically detects Master Numbers (11,22,33)', and specifies a length of 300–500 word meanings. 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?

The description is somewhat wordy in places (e.g., repeating 'outer personality', 'mask you regularly show the world', 'social persona') and is 3 relatively long. However, it opens with the most important computation, then explains purpose, output, master handling, and typical use cases in a logical order. Clearer and more structured than the average tool description, so 4.

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 responsibility for explaining return behavior, and it does that thoroughly: says the return is a 'comprehensive interpretation' covering public image, 'social dynamics', 'personality presence', 'relationship first presence', and 'for all numbers 1-9, 11, 22, 33'. It also says which numbers are returned in 300–500 words and that master numbers are detected. Missing precise return JSON shape, but for a pure numerology calculator this is strongly adequate.

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 fullName, lang, and compact. The description adds no extra parameter-level semantics beyond repeating that the fullName's consonants are used. Thus the baseline 3 is appropriate; the description doesn't merge or aid more than what is in 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?

States a specific verb ('Calculate'), resource ('Personality'), and scope ('from the versus in your birth name using Pythagorean numerology'), and lists the return. This distinguishes it from sibling numerology tools like soul_urge (vowels) and life_path. The title and description both emphasize 'how others perceive you', so the purpose is unambiguous.

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

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

Provides clear use cases for the tool: 'Personal branding apps, social skills training, professional development, and communication coaching'. It does not explicitly name alternatives or when *not* to use it, but the 'consonants' basis naturally disambiguates from sibling vowel-based tools. Lacks an explicit 'when to not use' clause, hence 4 rather than 5.

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

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

With readOnlyHint=true and destructiveHint=false, annotations already cover the safety profile. The description adds behavioral value by specifying what the tool returns: monthly theme, practical focus guidance, and the parent Personal Year context. It stops short of describing exact output structure, but the main non-obvious 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 well-structured and front-loads the core calculation and output. The opening 'Perfect for...' sentence lists plausible use cases but is not essential for invocation. This is slightly longer than necessary but still focused and readable.

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

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

For a tool with no output schema, the description provides useful outcome detail (theme, practical focus, parent Personal Year context) and parameter context (birth info plus target month/year). It could additionally specify exact result shape or fallback language behavior, but the given coverage is adequate given full schema param descriptions and annotations.

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 each parameter is already documented. The description reinforces the core inputs (birth month/day, target year/month) and clarifies the requested period, but it adds little beyond what the schema already provides. This matches the baseline for full 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?

The description opens with a specific action ('Calculate your Personal Month number') and resource basis (birth month/day plus target year/month). It further clarifies the result's meaning—monthly theme and energy within the Personal Year cycle—which clearly distinguishes it from related daily/yearly tools.

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 clearly targets monthly forecast use cases and explicitly ties the result to a target calendar month, making the appropriate context evident without ambiguity. It names several application scenarios but does not explicitly contrast with sibling tools like post_numerology_personal_day or post_numerology_personal_year.

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

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

With readOnlyHint and destructiveHint already supplied, the description adds value by explaining the 9-year cycle system, the current-year forecast semantic, and the return content. It also notes the Pythagorean method, which is a behavioral detail beyond annotations. No contradiction exists.

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

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

The core calculation and forecast content are front-loaded, but the description contains marketing language such as 'Perfect for yearly planning apps, life coaching platforms, astrology services, and personal development tools' and a somewhat redundant final sentence about detailed forecasts. Not every sentence earns its place, though the structure remains reasonably readable.

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

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

There is no output schema, so the description reasonably compensates by enumerating forecast components. However, it leaves some ambiguity around 'all 9 Personal Year cycles' versus the single current-year annual forecast, and it does not clarify response structure, pagination, or language/compact side effects. For a 5-param tool with no output schema, this is adequate but not 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 baseline is 3. The description does add that month+day+year are combined to produce the Personal Year number, which helps link the inputs, but it does not contribute details about the language or compact parameters. The schema already sufficiently documents those, so no extra credit or penalty is warranted.

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 ('Calculate your Personal Year number from your birth month, day, and current year using Pythagorean numerology'), then lists concrete outputs (theme, opportunities, challenges, actionable advice). The title's 'Annual cycle and forecast for current year' further distinguishes it from daily and monthly numerology 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 implies usage through 'yearly planning apps, life coaching platforms, astrology services, and personal development tools,' but it never explicitly contrasts this tool with siblings such as post_numerology_personal_day or post_numerology_personal_month, nor does it give exclusions or routing conditions. Usage context is implied rather than stated as a decision rule.

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

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

Annotations indicate readOnly and non-destructive behavior, so safety is already established. The description provides valuable extra behavioral details not covered by annotations: automatic detection of Master Numbers (11, 22, 33) and return content of detailed 300-500 word meanings for all numbers including 1-9, 11, 22, and 33.

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

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

The first sentence immediately communicates the core operation, and the structure is logically organized. However, several middle sentences are repetitive and could be condensed into one line for the same meaning of 'interests and spiritual longings', making the description unnecessarily wordy. Still, it remains moderately concise.

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 gives a good overview of return content: personality traits, emotional needs, relationship desires, spiritual longings, and even the default output length of all numbers including Master Numbers. The tool is a simple one-time calculation with only one required parameter, so the definition is reasonably complete for an agent to infer whether it is the right choice.

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

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

Schema coverage is 100%, and the schema already fully describes both fullName with vowel knowledge, lang with enum and defaults, and compact with clear semantics. The description adds no new parameter-level information beyond what is already specified in the input schema, so 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?

Description clearly states: 'Calculate your Soul Urge (Heart Desire) number from the vowels in your birth name using Pythagorean numerology.' Specific verb, resource, and method. The vowel-based, inner-desire nature distinguishes it from other numerology sibling tools such as life path or personality.

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?

Provides clear use context: appropriate for self-discovery, emotional intelligence, relationship counseling, and personal development. However, it does not explicitly mention when not to use this tool or compare it to any specific sibling alternative, only indirectly implying that it is for vowel-based reading.

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