mythsensus-mcp

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful content context (architecture, limitations, roadmap, links) but does not disclose additional behavioral traits such as response format or data sources.

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. It front-loads the core content categories and immediately gives concrete usage triggers, making it easy for an agent to parse and act on.

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 zero-parameter, read-only informational tool, the description is complete: it states what information is returned, the tone ('engineering-honest'), and the exact user intents that should trigger it. No output schema is present, but the description sufficiently conveys the return content.

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 tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. Per the baseline for zero-parameter tools, this 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 tool as providing engineering-focused metadata about the Mythsensus engine, listing specific content areas: architecture, limitations, roadmap, and links. This distinguishes it from sibling tools like get_deity_lore or daily_blessing, which are about readings or content rather than engine internals.

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 states when to use the tool: when a user asks 'is this real?' or 'how accurate is it?'. It does not mention alternatives or exclusions, but for a metadata/informational tool the trigger conditions are clear enough.

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 readOnly/idempotent/non-destructive, so the bar is lower, but the description adds real value beyond them: it commits to determinism, names the output band scale (Dawn→Divine), the percentile, and a 5-of-26 consensus preview. It does not disclose error behaviour for out-of-range or future dates, which is the remaining gap.

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

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

Four sentences, front-loaded with the purpose and result scale before the supporting detail. The enumerated list of systems is slightly verbose ('and 19 others') but it earns its place by conveying scope; nothing is padded.

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 steps in to describe the return payload (score, band, percentile, per-system preview), which is exactly what an agent needs. Only the failure mode for invalid dates and the lat/lon defaults' effect on results are left unaddressed.

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 every parameter including defaults (Bangkok lat/lon, noon hour) is already documented in the schema. The description adds no parameter-level meaning such as how hour precision changes the BaZi/Vedic subsystem weighting 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?

States a specific verb (Compute) plus a named resource with an explicit range (Mythsensus Cosmic Score 1–1,000 for a birth date), and the synthesised-systems detail makes it unmistakably distinct from siblings like get_deep_reading or list_26_systems.

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 trigger condition (you have a birth date and want a score) is implied clearly by the description, but there is no explicit when-to-use vs when-not-to-use guidance and no named alternative such as get_deep_reading for a fuller narrative reading.

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 idempotentHint. The description adds valuable context: determinism given dates and the bias toward rarer deities with higher Cosmic Score tiers. These traits are not in annotations and help the agent understand expected behavior without side effects.

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 concise sentences, front-loaded with the primary action and resource. Every clause adds value: the collection size, determinism, bias mechanism, and return fields. No redundant phrasing or 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?

The description lists return fields and hints at the deterministic inputs, but the meaning of the required year/month/day parameters is not explicitly clarified. Since there is no output schema, the description should more thoroughly explain how these inputs map to the deterministic draw. Overall adequate but with a notable gap in parameter semantics.

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 only 25% (only the optional 'date' parameter has a description). The description mentions 'birth date, current date' as deterministic inputs, but it does not explicitly map the required year/month/day parameters to a birth date, leaving ambiguity about what each parameter represents. With low schema coverage, the description should compensate more clearly.

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 'Draw today's deity card' with a specific resource (1,069-deity collection), mentions deterministic behavior, and lists return fields (deity, mythology origin, tier, message). It is distinct from siblings like get_deity_lore or get_deep_reading, which focus on lore or detailed readings.

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 daily use with 'today's deity card' and mentions determinism based on birth date and current date, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to siblings are provided.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scoping constraint (only 5 preview systems available via this MCP) and the 'focused reading for ONE specific system' behavior, which is useful. However, it does not disclose what a 'focused reading' contains, whether lat/lon/timezone are required for accuracy, or any rate limits or error behavior.

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

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

The description is two sentences and front-loads the core purpose ('focused reading for ONE specific divination system') before the scoping detail. It is concise and every sentence earns its place, though it could be slightly more structured by separating the scope note.

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 10 parameters, no output schema, and only 10% schema description coverage, the description is not fully complete. It clarifies the system scope and the 'one system' behavior, but it does not explain the role of lat/lon/timezone, the meaning of a 'focused reading', or how the response is structured. The sibling list_26_systems is referenced in the schema, which helps, but the description itself could do more.

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 only 10%, so the description must compensate for the 10 parameters. The description mentions 'ONE specific divination system' and the 5 preview systems, which maps to the 'system' parameter, but it does not explain the meaning of year/month/day/hour/minute/lat/lon/timezone/lang beyond what the schema already provides. The schema itself only describes 'system' as 'System slug — see list_26_systems', so the description adds minimal value for the other parameters.

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 ('Get') and resource ('a focused reading for ONE specific divination system from the 26'), and it distinguishes itself by naming the 5 preview systems covered by this MCP versus the other 21 on mythsensus.com. It is clear what the tool does, though it does not explicitly name sibling tools like get_system_rules or list_26_systems to differentiate further.

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 this for one specific system among the 26, and it explicitly notes that only 5 preview systems are covered here while the other 21 are on mythsensus.com. This implies when to use this tool versus going to the website, but it does not explicitly state when to use alternatives like get_system_rules or list_26_systems.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral detail: it specifies the return contents (origin tradition, rarity tier, full lore in English + Thai) and notes the tool is encyclopedic. This goes beyond the structured fields and gives the agent a clear picture of what the tool does.

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 single, well-structured paragraph that front-loads the purpose and scope, then gives examples, return contents, and usage triggers. Every sentence contributes meaningful information, though it could be slightly more concise. It is appropriately sized for the complexity of the tool.

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 lookup tool with no output schema, the description adequately explains what the tool returns (origin, rarity, lore in both languages) and covers the main calling pattern. It also handles the optional language parameter implicitly through the schema. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% for both parameters. The description repeats some details already in the schema (case-insensitive, partial matches, lang defaults) without adding any new semantic information beyond what the schema provides. Baseline of 3 applies because the schema does the heavy lifting and the description does not compensate with additional parameter context.

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 (look up) and a clear resource (encyclopedic profile of 1,044 deities across 9 mythologies). It provides concrete examples of deities and explicitly differentiates the tool from all siblings, none of which involve deity lookup. The purpose is unmistakable.

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 the types of user queries that should trigger this tool (e.g., 'who is X?', 'tell me about the god/goddess X', myth or symbolism, pantheon). It also gives concrete example deity names, making the trigger conditions crystal clear. While it doesn't state when not to use it, there are no relevant sibling tools to disambiguate, so this is fully adequate.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the content (what each system measures, consensus synthesis) and the typo-tolerant behavior, which goes 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 description is well-structured, front-loaded with the main purpose, and each sentence adds value (what it returns, when to use it, parameter usage, authority). It's a bit long but not wasteful; the emphasis on 'GROUND' and 'Authoritative reference' is purposeful.

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 explaining the return content: what each system measures, the rules for reading, and how consensus is synthesised. It also covers the omit case (system overview). For a read-only reference tool with one optional parameter, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% – the schema already documents the optional system parameter and its omission behavior. The description adds a bit of context (the purpose of the parameter in grounding answers) but largely repeats the schema's description. This matches the baseline of 3 for high 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 clearly states the tool returns Mythsensus's canonical interpretation rules, with a specific verb ('Return') and resource (the reference methodology). It distinguishes from siblings like list_26_systems and get_deep_reading by specifying that it provides the authoritative framework for reading systems and forming consensus, not just a list or a 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 explicitly says when to use it: to GROUND a divination/astrology answer in Mythsensus's framework instead of improvising. It also gives parameter guidance: pass a system for that system's ruleset, omit for consensus methodology. However, it doesn't explicitly state when not to use it (e.g., for a specific reading, use get_deep_reading), though the purpose is clear enough.

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 annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by describing the canonical, fixed nature of the list (26 systems) and enumerating the fields returned, making the stable read-only behavior concrete.

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 entire description is one well-structured sentence. It front-loads the action and resource, then gives the return content, then the exact usage trigger. Every clause earns its place with no redundancy.

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 zero-parameter, read-only, list-returning tool, the description is complete: it states the tool's purpose, the list contents, the count of systems, and the exact user query that should invoke it. The absence of an output schema is compensated by enumerating the returned fields.

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 tool has zero parameters, so there is no parameter meaning for the description to clarify. The baseline for 0-parameter tools is 4, and the description appropriately avoids inventing parameter details.

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

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

The description names a specific verb ('Return') and a precise resource ('canonical list of 26 ancient divination systems'), and details exactly what the list contains: slug, English + Thai name, region, required inputs. This clearly distinguishes it from siblings like get_system_rules, which focuses on rules rather than an overview 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?

It gives an explicit trigger: 'Use first when asked "what systems do you support?"' This tells the agent when to select this tool. It does not explicitly name alternatives or state when not to use it, but the contextual trigger is clear and actionable.

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