Skip to main content
Glama
svenkatreddy

ramayana-mcp

by svenkatreddy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ramayana-mcp

An MCP (Model Context Protocol) server for the Ramayana Book (svenkatreddy/ramayana-mcp). Search verses, fetch Sanskrit plus English/Hindi/Telugu translations, and get a deterministic verse of the day. Same codebase serves three targets:

  • stdio (src/stdio.ts) — Claude Desktop, Cursor, and Smithery hosting

  • Vercel serverless (api/mcp.ts) — stateless Streamable HTTP at /api/mcp

Tools

Tool

What it does

list_kandas

The seven kandas with Sanskrit titles and chapter counts

get_verse

One verse by kanda, sarga and verse number

get_sarga

Every verse of one sarga, optional language filter

search_verses

Full-text search across all four languages, with snippets

verse_of_the_day

Deterministic verse of the day (see below)

Plus a ramayana://kandas resource with kanda/chapter/verse counts.

Related MCP server: sacred-texts-mcp

Verse of the day

verse_of_the_day hashes the calendar date (FNV-1a, YYYY-MM-DD, UTC by default) and maps it uniformly onto all 24,214 indexed verses. The same date always returns the same verse; pass an explicit date to look up any other day.

Local setup

npm install
npm run build-index   # builds data/ from a Ramayana_Book checkout
npm run build
npm start             # stdio server

build-index reads the Ramayana_Book repo from RAMAYANA_BOOK_DIR (default: ../../ramayana-modernization/repo relative to this package).

Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "ramayana-book": {
      "command": "node",
      "args": ["/absolute/path/to/ramayana-mcp/dist/src/stdio.js"]
    }
  }
}

Deploy on Vercel (free Hobby plan, no payment needed)

  1. Push this directory to a new GitHub repo (create the repo yourself on github.com).

  2. In the Vercel dashboard: Add New Project -> Import the repo -> Deploy.

  3. No build config needed; vercel.json already ships the data/ files with the function. The MCP endpoint is https://<project>.vercel.app/api/mcp.

The endpoint is stateless (one POST per JSON-RPC request, no sessions), which fits the Hobby plan's function limits. Point any MCP client at the URL above.

Publish on Smithery (for discoverability)

  1. Push the repo to GitHub (public) - done: svenkatreddy/ramayana-mcp.

  2. Go to smithery.ai, sign in with GitHub.

  3. Add / deploy the ramayana-mcp repo. smithery.yaml declares the TypeScript runtime; Smithery installs, builds, and imports createServer plus configSchema from src/index.ts. No API keys or config needed.

Smithery hosts the server and gives it a registry page with one-click install for Claude Desktop, Cursor, and other clients.

Data and attribution

Verse data is built from the Ramayana_Book repository:

  • Sanskrit: Sanskrit Wikisource (Wikimedia); 3 chapters restored from IIT Kanpur's critical edition

  • English: Valmiki Ramayan Dataset (MIT) — M.N. Dutt's translation (1891-1894), IIT Kanpur, Gyaandweep

  • Hindi: Chaturvedi Dwarka Prasad Sharma's Hindi Ramayana (used with permission)

  • Telugu: Telugu Wikisource contributors (CC BY-SA)

Re-run npm run build-index after the Ramayana_Book translations change.

License

The server code in this repo is MIT licensed (see LICENSE).

The verse data under data/ carries the licenses of its sources, not MIT: Sanskrit from Sanskrit Wikisource (Wikimedia), English from the MIT-licensed Valmiki Ramayan Dataset, Hindi from Chaturvedi Dwarka Prasad Sharma's translation (used with permission), Telugu from Telugu Wikisource contributors (CC BY-SA). See the Ramayana_Book translation sources for full attribution.

Available Tools

5 tools
get_sargaA

Fetch every verse of one sarga (chapter), with Sanskrit and available translations

ParametersJSON Schema
NameRequiredDescriptionDefault
kandaYesKanda name, e.g. ayodhya_kanda
langsNoLanguages to include; defaults to all available
chapterYesSarga (chapter) number

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose the response content (Sanskrit plus available translations), which is useful, but says nothing about result size, pagination, or ordering for what could be a large chapter payload.

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

Conciseness5/5

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

A single tight sentence with the verb and scope front-loaded and zero filler. Nothing is wasted.

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

Completeness3/5

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

For a read-only chapter fetch with no output schema and no annotations, the description should ideally cover return shape or pagination. It hints at content (Sanskrit + translations) but leaves response structure and handling of large chapters unaddressed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents kanda, chapter, and langs with examples and defaults. The description's mention of 'available translations' loosely maps to the langs parameter but adds no syntax or default detail beyond the schema.

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

Purpose4/5

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

States a specific verb ('Fetch') and resource ('every verse of one sarga/chapter'), and the phrase 'every verse' implicitly contrasts with the sibling get_verse (single verse). It does not explicitly name the alternatives, but the scope is unambiguous.

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

Usage Guidelines3/5

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

Usage is only implied — an agent infers this is for retrieving a whole chapter rather than a single verse or a search. There is no explicit when-to-use/when-not guidance or reference to siblings like get_verse or search_verses.

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

get_verseA

Fetch a single verse by kanda, chapter (sarga) and verse number, with Sanskrit and available translations

ParametersJSON Schema
NameRequiredDescriptionDefault
kandaYesKanda name, e.g. bala_kanda
verseYesVerse number within the sarga
chapterYesSarga (chapter) number

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the return payload ('Sanskrit and available translations'), which usefully flags that translation coverage may vary. It says nothing about failure behavior for invalid kanda/chapter/verse values, whether numbering is 1-based, or rate limits, so gaps remain.

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

Conciseness5/5

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

A single front-loaded sentence with no filler; the lookup keys and returned content are both stated compactly.

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

Completeness4/5

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

For a simple three-parameter read tool with no output schema and no annotations, the description covers the essential who/what/returns. Only minor items are absent, such as error handling on invalid coordinates and the shape of the translations field.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters, and the baseline is 3. The description adds only the 'chapter (sarga)' equivalence, a small but real clarification for domain terminology.

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

Purpose5/5

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

States a specific verb (Fetch), a specific resource (a single verse), the exact lookup keys (kanda, chapter/sarga, verse number), and what comes back (Sanskrit plus translations). This clearly separates it from list_kandas, get_sarga, search_verses, and verse_of_the_day without needing to name them.

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

Usage Guidelines3/5

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

Usage is only implied: the coordinate-based phrasing signals 'use this when you already know the exact verse location.' There is no explicit when-to-use versus search_verses (partial text/unknown location) or verse_of_the_day, and no stated prerequisites.

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

list_kandasA

List the seven kandas of the Ramayana with their Sanskrit names and chapter counts

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. 'List' implies a safe read and the return contents are named, but there is no statement of ordering, stability, or that the result set is static and non-filterable.

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

Conciseness5/5

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

A single front-loaded sentence with no filler; every clause (verb, resource, scope, return fields) earns its place.

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

Completeness4/5

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

For a trivial zero-parameter static listing with no output schema, naming the returned fields is close to sufficient. Only minor details like ordering or exact count formatting are left unspecified.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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

Purpose4/5

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

States a specific verb (List) and resource (the seven kandas of the Ramayana) and even names the return payload (Sanskrit names, chapter counts). It is clearly distinct from the verse/sarga siblings, though it never explicitly contrasts itself with them.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of alternatives such as get_sarga or search_verses. The agent must infer that this is the top-level structural index rather than a lookup tool.

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

search_versesA

Full-text search across Sanskrit and English/Hindi/Telugu translations; returns matching verse references with snippets

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default 10)
queryYesSearch text, e.g. a name, phrase or Sanskrit word

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the return shape ('matching verse references with snippets'). However, it says nothing about result ranking/ordering, pagination beyond the limit param, or behavior when a language has no match, so behavioral coverage is partial.

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

Conciseness5/5

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

A single tight sentence that front-loads the verb and scope and ends with the return format. Every clause earns its place with no filler.

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

Completeness4/5

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

For a two-parameter search tool with full schema coverage and no output schema, the description covers the essentials: scope, languages, and returned content. It could be stronger by noting ordering/ranking or default limit, but nothing critical to invoking it is missing.

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

Parameters3/5

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

Schema description coverage is 100% (query and limit both documented with examples and bounds), so the schema does the heavy lifting. The description adds no additional parameter meaning such as matching semantics or how multi-language queries are handled, making the baseline 3 appropriate.

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

Purpose4/5

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

The description gives a specific verb (full-text search) and resource (verses) plus scope (Sanskrit and English/Hindi/Telugu translations), which separates it well from get_verse/get_sarga. It stops short of naming any sibling explicitly, so an agent must infer that this is the discovery tool rather than the fetch tool.

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

Usage Guidelines3/5

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

Usage is only implied: 'full-text search' suggests using this when you have a phrase or name rather than a known verse reference, but there is no explicit when-to-use statement, no exclusion, and no mention of the alternative retrieval tools like get_verse.

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

verse_of_the_dayA

A deterministic verse of the day: the same calendar date always yields the same verse, drawn uniformly from the whole corpus

ParametersJSON Schema
NameRequiredDescriptionDefault
dateNoDate as YYYY-MM-DD; defaults to today (UTC)

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses determinism (same date always yields the same verse) and the uniform distribution across the corpus, which implies idempotency and a read-only operation. It omits error behavior for invalid dates, auth requirements, and the return format.

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

Conciseness5/5

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

One compact sentence, front-loaded with the core purpose and immediately followed by the behavioral guarantee. No wasted words.

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

Completeness4/5

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

For a zero-required-parameter read tool with no output schema, the description covers the essentials: what is returned and the determinism guarantee. Only minor gaps remain around return shape and failure modes for malformed dates.

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

Parameters3/5

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

Schema coverage is 100% and the single date parameter is fully documented in the schema (format, default to today UTC). The description alludes to the date driving the output but adds no format or edge-case detail beyond the schema.

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

Purpose4/5

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

The description names a specific resource (verse of the day) and its defining property (deterministic, uniform draw from the corpus). It is clearly distinct from siblings like get_verse and search_verses, though it never names them explicitly.

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

Usage Guidelines3/5

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

Usage is only implied by the phrase 'verse of the day' — an agent can infer the daily-devotional use case. There is no explicit when-to-use statement and no routing guidance versus get_verse or search_verses.

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

Tool Schema Changelog

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

  1. 5 tool updatesv0.1.0
    • First observedget_sarga
    • First observedget_verse
    • First observedlist_kandas
    • First observedsearch_verses
    • First observedverse_of_the_day
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct granularity of the same corpus: listing kandas, fetching one verse, fetching one sarga, full-text search, and a deterministic daily pick. verse_of_the_day vs get_verse could superficially touch the same data, but the descriptions make the boundaries obvious.

Naming Consistency4/5

Four tools follow a clean verb_noun pattern (list_kandas, get_verse, get_sarga, search_verses) with consistent snake_case. verse_of_the_day breaks the pattern as a bare noun phrase with no verb, though it is still readable and unambiguous.

Tool Count5/5

Five tools is well-scoped for a scripture-browsing server: structure listing, two retrieval granularities, search, and a novelty feature. No tool feels redundant or padded.

Completeness4/5

Core lifecycle for corpus navigation is covered: browse structure, fetch verse/chapter, search, and a daily highlight. A gap remains at the kanda level — there is no way to list the sargas belonging to a kanda, so agents must guess chapter numbers before calling get_sarga.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers