japanese-learning-memory

by hinoyayoi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: searching, upserting, relating, recording mistakes, fetching due reviews, and submitting reviews. No two tools overlap in function, and the descriptions reinforce their unique roles.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (search_items, upsert_item, add_relation, record_mistake, get_due_reviews, submit_review). The verb is always first and the noun is always the object, creating a predictable and readable API.
Tool Count5/5
With six tools, the server is well-scoped for a Japanese learning memory system. Each tool covers a distinct core operation without unnecessary bloat or thinning, fitting the typical 3-15 tool sweet spot.
Completeness4/5
The server covers the core lifecycle: create/update (upsert_item), read/search (search_items), relations (add_relation), and review scheduling (get_due_reviews, submit_review). A minor gap is the lack of an explicit delete operation, but this is not a fatal omission for a spaced-repetition memory system.
Average 3.2/5 across 6 of 6 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. 'Search' implies a read-only operation, but the description does not mention result ordering, match behavior (e.g., partial vs. exact), default limits, or any side effects. The phrase 'optional filters' hints at filtering capabilities but does not detail them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. Given the tool has five parameters and no schema descriptions, this brevity sacrifices necessary detail, making it more anemic than appropriately concise.
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?
With five parameters, no annotations, and a 0% schema coverage, the tool is underspecified. The description does not explain the purpose of each filter, how results are returned (although an output schema exists), or when to use this tool vs. sibling tools. The presence of an output schema mitigates some need for return-value detail, but the overall context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate. It only mentions 'optional filters' without naming any of the actual filter parameters (status, item_type, jlpt_level) or explaining the required 'query' parameter or 'limit'. The function's parameter semantics are almost entirely unsupported.
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 action ('Search') and resource ('personal Japanese knowledge items'), making its primary purpose unambiguous. However, it does not explicitly differentiate it from sibling tools like get_due_reviews, which also involves searching/fetching items.
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 such as get_due_reviews or upsert_item. It only implies usage for searching with filters, without any exclusions or contextual prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states that it will create or update based on a match. It does not explain what happens when no match exists, whether multiple matches are possible, idempotency, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately front-loaded, though its brevity borders on under-specification; however, that issue is more relevant to completeness than conciseness.
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 tool's complexity (14 parameters, no annotations) and the presence of an output schema, the description is still too minimal. It lacks usage context, behavioral details, and parameter semantics, making it insufficient for an agent to reliably select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not describe any parameters except indirectly implying 'expression' and 'item_type' as matching keys. The other 12 parameters remain unexplained, adding no meaning 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 ('Create or update') and the matching criteria ('exact normalized-expression and item-type match'), which distinguishes it from sibling tools like search_items and add_relation. However, it does not explicitly name the resource ('item') though it is implied by the tool name.
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 gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context. The only usage signal is the name 'upsert_item' and the generic upsert behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a key behavior: appending without deduplicating history, which helps the agent understand duplicates are allowed. However, it omits other important traits like permission requirements, reversibility, or side effects beyond the basic append.
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, front-loaded sentence with no filler words. Every word contributes to the meaning, making it an exemplar of concision.
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 tool has nine parameters and no annotations, the one-sentence description is insufficient. It lacks practical context on when to record a mistake, what the required fields mean, or any workflow guidance. The presence of an output schema mitigates return-value uncertainty but does not compensate for the missing usage and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any of the nine parameters. It provides only a general sense of 'mistake' without mapping to fields, forcing the agent to rely on parameter names alone, which is insufficient for parameters like activity_type and problem_type.
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?
The description uses a specific verb 'append' and identifies the resource as 'learning mistake,' clearly distinguishing this tool from siblings like search_items or submit_review. The phrase 'without deduplicating history' adds a critical behavioral nuance that sets it apart.
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, nor does it mention any exclusions or prerequisites. It simply states the action without context, leaving the agent to infer usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states 'never mutates data', which is a key non-mutating guarantee. This adds valuable context beyond the schema, though it omits other potential behaviors like pagination.
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?
Two sentences, front-loaded with the main purpose, followed by a behavior note. Every word earns its place with no unnecessary content.
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?
For a tool with 4 optional parameters, no annotations, and zero parameter documentation, two sentences are inadequate. The output schema covers return structure, but parameter roles and usage context are missing, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the four parameters (as_of, limit, item_type, review_type). The mention of 'new learning items' only vaguely hints at item_type/review_type filtering, insufficient for correct parameter use.
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?
The description uses the specific verb 'return' and names the resource 'due reviews and new learning items', clearly distinguishing this read tool from the sibling mutation tools. The read-only note further clarifies its role.
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?
No explicit when-to-use guidance or alternatives are provided. The statement 'this query never mutates data' implies safety but does not tell the agent when to choose this tool over search_items or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool saves history, schedules the next review, and updates mastery, which are key behavioral outcomes. However, it does not disclose potential side effects, required preconditions, or details on how 'conservative' mastery updates are performed.
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 sentence, front-loaded with action verbs, and contains no redundant information. It efficiently conveys the tool's purpose without unnecessary length.
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 7 parameters, no annotations, and 0% schema coverage, the description is too sparse to fully equip an agent to invoke the tool correctly. It lacks parameter guidance, edge-case handling, and integration context with the scheduling algorithm.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description provides high-level context but does not explain the meaning or format of individual parameters like score, review_type, error_type, or response_time_ms. Agents must infer parameter semantics from names alone, which is insufficient for correct invocation.
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?
The description uses specific verbs 'Save,' 'schedule,' and 'update' with clear resources (review history, next review, mastery). It clearly distinguishes from siblings like record_mistake (which likely only logs mistakes) and get_due_reviews (which fetches due items).
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?
The description implies usage when completing a review, but does not explicitly state when to use this tool versus alternatives like record_mistake or upsert_item. No exclusions or contextual triggers are mentioned, leaving the choice to the agent's interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the relation is 'validated' and involves 'existing' items, hinting at validation and prerequisites, but it does not explain what validation entails, failure behavior, or whether duplicate/overwriting relations are allowed. This is minimal but non-trivial context.
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 concise sentence with no filler or redundancy. It front-loads the primary action and resource, making it immediately clear what the tool does.
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 has an output schema, return values are covered. However, for a mutation tool with no annotations, the description lacks guidance on when to use it, validation failure behavior, and whether relations can be updated or duplicated. It is adequate but not thorough for a tool with four parameters and no structured annotations.
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?
The schema has zero description coverage, so the description must compensate. It maps 'two existing knowledge items' to from_item_id and to_item_id, and 'relation' to relation_type. However, the 'explanation' parameter is not mentioned, and no details on value formats or constraints are provided, leaving a gap.
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?
The description uses a specific verb ('Add') and clearly identifies the resource ('a validated relation between two existing knowledge items'). This clearly distinguishes it from siblings like search_items and submit_review, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'between two existing knowledge items' implies a prerequisite that both items must already exist, providing clear usage context. However, it does not explicitly mention when not to use this tool or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![japanese-learning-mcp MCP server](https://glama.ai/mcp/servers/hinoyayoi/japanese-learning-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hinoyayoi/japanese-learning-mcp)

Score Badge

Copy to your README.md:

[![japanese-learning-mcp MCP server](https://glama.ai/mcp/servers/hinoyayoi/japanese-learning-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hinoyayoi/japanese-learning-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hinoyayoi/japanese-learning-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server