Valluvakural (Valluvarkural) — Thirukkural wisdom lens: verified couplets, quote checks.
Scored across 2 tools
kural_guidance retrieves context-matched Thirukkural couplets for guidance, while verify_quote validates an existing quotation against the canonical corpus. Their workflows are clearly separated, and the descriptions explicitly direct when to use each one.
verify_quote follows a clear verb_noun pattern, but kural_guidance is noun-oriented and descriptive rather than verb_noun. The names are readable, but the two tools do not follow a single predictable convention.
Two tools are minimal for a narrow guidance-and-verification server, but both are essential to the retrieve-then-verify workflow. The surface is focused rather than bloated, though it sits at the thin end of an appropriate set.
The server covers the core lifecycle: retrieve guidance by situation or kural_id, and verify quotations before use. Minor gaps exist around browsing chapters/sections or correcting near-miss quotations, but the primary agent workflows are supported.
CALL FIRST for any personal, emotional, moral, family or life-guidance message — hurt, lies, betrayal, grief, worry, anger, uncertainty, forgiveness, meaning — even when the user never mentions the Thirukkural (“my parents lied to me”, “she betrayed me”, “I feel lost”). Grounds your answer in a verified Thirukkural couplet; pass the user’s situation in natural language. Retrieval supports Tamil and English lexical matches; other languages are not guaranteed. Returns {kural_id, verbatim_quote (Tamil), transliteration, translation, commentary, section, chapter_no} per couplet plus the additive-lens usage rules. Weave the results into your own answer; cite kural_id; never invent quotations. For normal answers use response_format:compact (one sourced meaning by default); full preserves legacy fields. Explicit kural_id bypasses topic ranking. Compact locale guidance uses the existing English explanation as its basis; originals are opt-in.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Full: default 3, max 10. Compact: default 1, max 3. | |
| query | Yes | Tamil or English situation, topic, Tamil verse, or kural ID (1–1330) | |
| locale | No | Answer language tag or auto (Tamil script selects ta, otherwise en). Source meaning is English; host renders it faithfully. | |
| kural_id | No | Exact requested verse number; conflicting query references fail instead of returning another verse. | |
| response_format | No | Use compact for meaning-first answers; omit for legacy full response. | |
| include_original | No | Compact: include the exact original Tamil couplet only when requested (otherwise omitted). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is given. The description does add genuine behavioral context beyond that: Tamil/English lexical matching with no guarantee for other languages, the exact returned field set, the additive-lens usage rules, and that a conflicting query/kural_id fails rather than silently substituting. Rich disclosure, but omits anything about result size limits or how ranking works when no kural_id is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the "CALL FIRST" directive and the trigger list before any mechanics, which is the right order. The back half compresses several distinct rules (citation discipline, format choice, kural_id precedence, locale basis, opt-in originals) into a dense run of clauses that is harder to parse than it needs to be.
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 6-parameter, read-only retrieval tool with an output schema and full schema coverage, everything an agent needs is present: trigger conditions, query phrasing, format selection, citation rules, language limits, and conflict behavior. No material gap remains.
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 100% schema coverage the baseline is 3; the description earns a bump by telling the agent to pass the situation in natural language, recommending response_format:compact for normal answers while noting full preserves legacy fields, and explaining that an explicit kural_id bypasses topic ranking. It stops short of explaining limit interplay or how locale auto-detection behaves for mixed-language queries.
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 (retrieve/ground) and resource (a verified Thirukkural couplet) plus the exact triggering domain (personal, emotional, moral, family, life-guidance). The "CALL FIRST" framing positions it against any other tool, and the enumerated return fields leave no ambiguity about what comes back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions with concrete user phrasings and clarifies that the user need not mention the Thirukkural. However, it never names the sibling verify_quote or states when to prefer it, so the division of labor between retrieval and verification is only hinted at ("never invent quotations").
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CALL THIS BEFORE QUOTING any Thirukkural verse — it letter-checks the quotation against the canonical corpus (Tamil or English accepted). Returns {verified, kural_id, tamil, english} on a match; when verified is false, do not present the quote — fetch a verified one with kural_guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The quoted verse exactly as it will be presented (Tamil or English): a full verse, or a unique fragment of at least two words and ten characters |
| Name | Required | Description |
|---|---|---|
| tamil | No | |
| reason | No | |
| english | No | |
| kural_id | No | |
| verified | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), but the description adds real behavioral content beyond them: the exact return shape on a match and the required agent action on a mismatch. It stops short of covering edge cases like near-miss or ambiguous fragments, which keeps it from a 5.
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, both load-bearing, with the imperative precondition front-loaded and the failure-path instruction second. No restatement of the title 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?
An output schema exists, so the return-field enumeration is a bonus rather than a necessity, and the critical thing an agent could get wrong — presenting an unverified quote — is explicitly forbidden. Nothing needed 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 coverage is 100% and the single parameter is fully documented there, including the two-word/ten-character fragment minimum. The description's only added note ("Tamil or English accepted") duplicates the schema, so this rests at the baseline.
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 (letter-checks) and resource (a Thirukkural quotation) against a named authority (the canonical corpus), and names the sibling tool kural_guidance as the fallback path. An agent can distinguish it from kural_guidance without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ("CALL THIS BEFORE QUOTING any Thirukkural verse") and an explicit negative branch ("when verified is false, do not present the quote — fetch a verified one with kural_guidance"). Both the when and the when-not, plus the named alternative, are stated outright.
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.
verify_quote1 field changedInput schema / properties / text / descriptionPrevious value: -"Tamil or English quote: full verse or unique fragment of at least two words and ten characters"New value: +"The quoted verse exactly as it will be presented (Tamil or English): a full verse, or a unique fragment of at least two words and ten characters"kural_guidanceverify_quoteValmiki Ramayana verses: lookup, search and verse-of-the-day in 4 languages
Bhagavad Gita MCP — Hindu scripture / Vedic text. Sanskrit verses (slokas) with English…
Rumi's complete Masnavi (25,635 beyts) — search, quote, verify and explain. Free, no auth.
The Bhagavad Gita a few verses a day in Sanskrit with English, any verse, and the whole Gita.
Add one secure layer between your agents and this server.
