Skip to main content
Glama
nakamura196

Genji MCP Server

by nakamura196
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Genji MCP Server

npm version

A Model Context Protocol (MCP) server that provides access to the Genji API for classical Japanese literature analysis and search. This server enables AI assistants like Claude to search and analyze texts from classical Japanese literature with advanced normalization features.

Features

  • đŸĨ Health Check: Monitor API status and availability

  • 🔍 Advanced Text Search: Search classical Japanese texts with sophisticated normalization options

  • ⚙ī¸ Normalization Rules: Access and understand text normalization rules

  • 🔍 Normalization Preview: Preview how text will be normalized before processing

  • đŸ‡¯đŸ‡ĩ Classical Japanese Support: Specialized handling of historical Japanese text variations

Related MCP server: e-Gov Law MCP Server

Installation

npm install -g @nakamura196/genji-mcp-server

Configuration

Add the server to your Claude Desktop configuration file:

macOS

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "genji": {
      "command": "npx",
      "args": ["@nakamura196/genji-mcp-server"]
    }
  }
}

Windows

Edit %APPDATA%/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "genji": {
      "command": "npx",
      "args": ["@nakamura196/genji-mcp-server"]
    }
  }
}

Alternatively, if you installed globally:

{
  "mcpServers": {
    "genji": {
      "command": "genji-mcp-server"
    }
  }
}

Usage

After configuration, restart Claude Desktop. The Genji tools will be automatically available. You can ask Claude for classical Japanese literature analysis like:

Health Check

  • "Check if the Genji API is working"

  • "Is the classical Japanese literature database available?"

Text Search

  • "Search for '花' in classical Japanese texts"

  • "Find passages containing 'æēæ°' with phonetic normalization"

  • "Search for text in volume 1 of Genji Monogatari"

  • "Look for '恋' with all normalization options enabled"

Normalization Features

  • "What normalization rules are available for classical Japanese?"

  • "Preview how 'æēæ°į‰ŠčĒž' would be normalized"

  • "Show me the normalization rules for historical kana"

Available Tools

genji_health_check

Checks the health and availability of the Genji API.

Parameters: None

genji_search

Searches classical Japanese texts with advanced normalization options.

Parameters:

  • query (string, optional): Search query text

  • limit (number, optional): Maximum results to return (1-100, default: 20)

  • offset (number, optional): Number of results to skip (default: 0)

  • sort (string, optional): Sort order for results

  • expand_repeat_marks (boolean, optional): Expand repeat marks (default: true)

  • unify_kanji_kana (boolean, optional): Unify kanji/kana variations (default: true)

  • unify_historical_kana (boolean, optional): Unify historical kana (default: true)

  • unify_phonetic_changes (boolean, optional): Unify phonetic variations (default: true)

  • unify_dakuon (boolean, optional): Unify voiced sound variations (default: true)

  • vol_str (array, optional): Volume/chapter filter

genji_get_normalization_rules

Retrieves the list of available text normalization rules.

Parameters: None

genji_preview_normalization

Previews how text would be normalized with current rules.

Parameters:

  • text (string, required): Text to preview normalization for

Text Normalization Features

The server supports various normalization options for classical Japanese text:

  • Repeat Marks Expansion: Converts repeat marks (々, ゝ, ゞ) to full characters

  • Kanji-Kana Unification: Handles variations between kanji and kana representations

  • Historical Kana Unification: Normalizes historical kana usage to modern equivalents

  • Phonetic Changes: Accounts for historical phonetic variations

  • Dakuon Unification: Handles voiced/unvoiced sound variations

Requirements

Development

# Clone the repository
git clone https://github.com/nakamura196/genji-mcp-server.git
cd genji-mcp-server

# Install dependencies
npm install

# Build the project
npm run build

# Start in development mode
npm run dev

API Reference

This server interfaces with the Genji API, which provides:

  • Full-text search of classical Japanese literature

  • Advanced text normalization for historical Japanese

  • Metadata about literary works and volumes

  • Health monitoring endpoints

Error Handling

The server includes comprehensive error handling for:

  • API connectivity issues

  • Invalid search parameters

  • Text encoding problems

  • Normalization errors

  • Rate limiting (if applicable)

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT License - see the LICENSE file for details.

Support

If you encounter any issues, please file them on the GitHub Issues page.

Related Projects

Changelog

1.0.1

  • Fix API URL references in documentation

  • Remove unused TypeScript interfaces for cleaner code

  • Update documentation links

1.0.0

  • Initial release

  • Health check functionality

  • Advanced text search with normalization options

  • Normalization rules management

  • Text normalization preview

  • Full classical Japanese text analysis support

Available Tools

4 tools
genji_get_normalization_rulesB

Get the list of available text normalization rules

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify if it requires authentication, has rate limits, returns paginated results, or what format the list takes. This leaves significant gaps for a tool that retrieves data.

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?

The description is a single, clear sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it efficient and easy to parse.

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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic read operation. However, it lacks details on return format, error handling, or behavioral constraints that would help an agent use it effectively, especially with sibling tools present.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, focusing instead on the tool's purpose. A baseline of 4 is justified since the schema fully handles the parameter aspect.

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 clearly states the action ('Get') and resource ('list of available text normalization rules'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'genji_preview_normalization' or 'genji_search', which likely involve normalization rules in different ways.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'genji_preview_normalization' (which might show rule effects) or 'genji_search' (which might apply rules), leaving the agent to infer usage from tool names alone.

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

genji_health_checkB

Check the health status of the Genji API

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the purpose but lacks details on what 'health status' entails (e.g., response format, metrics), whether it's safe or has side effects, or any operational constraints like rate limits. This leaves significant gaps for a tool that might inform system reliability.

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?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and avoids redundancy, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the health check returns (e.g., status codes, details), which is critical for a diagnostic tool. For a tool with no structured behavioral hints, this leaves the agent guessing about results.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information 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 clearly states the action ('check') and target ('health status of the Genji API'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this health check from sibling tools like genji_get_normalization_rules or genji_search, which prevents a perfect score.

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?

The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing (e.g., before other operations), or how it relates to sibling tools, leaving the agent with minimal context for decision-making.

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

genji_preview_normalizationC

Preview how text would be normalized with current rules

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to preview normalization for

TDQS

C2.9/5.0
Behavior2/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 states the tool is a 'preview,' implying it is non-destructive and read-only, but does not disclose behavioral traits like whether it requires authentication, has rate limits, or what the output format looks like. This is a significant gap for a tool with no annotations.

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?

The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It does not explain what 'normalization' entails, what the preview output includes, or how it relates to sibling tools. For a tool with one parameter but lacking structured context, this leaves gaps in understanding.

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%, with one parameter 'text' fully documented in the schema. The description adds no additional meaning beyond the schema, such as examples of normalization rules or input constraints, so it meets the baseline of 3.

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 clearly states the tool's purpose: 'Preview how text would be normalized with current rules.' It specifies the action ('preview') and resource ('text normalization'), but does not differentiate from sibling tools like 'genji_get_normalization_rules' or 'genji_search,' which prevents a score of 5.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or contexts where this preview is useful, such as testing rules before applying them, leaving the agent with minimal usage context.

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. 4 tool updatesv1.0.5
    • First observedgenji_get_normalization_rules
    • First observedgenji_health_check
    • First observedgenji_preview_normalization
    • First observedgenji_search
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.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: getting rules, health checks, previewing normalization, and searching texts. The descriptions make it easy to differentiate between configuration, monitoring, testing, and core functionality.

Naming Consistency5/5

All tools follow a consistent 'genji_verb_noun' pattern with snake_case throughout. The naming is predictable and readable, making it easy to understand each tool's function at a glance.

Tool Count5/5

Four tools is well-scoped for a server focused on text normalization and search in classical Japanese texts. Each tool earns its place by covering distinct aspects: configuration, health, preview, and core search functionality.

Completeness4/5

The toolset covers the essential workflows for text normalization and search, but there are minor gaps such as updating or managing normalization rules beyond just getting them. However, agents can work effectively with the provided tools for most use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • e-Gov Law MCP Server

    ryoooo
    A
    license
    A
    quality
    D
    maintenance
    Enables intelligent search and retrieval of Japanese legal statutes through the e-Gov API. Supports smart lookup of laws and articles with abbreviation recognition, batch processing, and multi-tier caching for high-performance legal research.
    8
    15
    MIT

  • Japan Data MCP

    yurukusa
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to query Japanese public data (laws, corporations, statistics) from official government APIs, returning normalized English metadata with source attribution.
    1
    MIT