Learning MCP

by giseungNoh

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 targets a distinct phase of the learning workflow: feature lifecycle, context, decision records, debug attempts, session sync, manifest retrieval, evidence details, and final review. There is no meaningful overlap that would cause an agent to pick the wrong tool.
Naming Consistency5/5
All tool names follow a clear snake_case verb_noun pattern, with get_, record_, start_, save_, finish_, and sync_ as predictable action prefixes. The naming is internally consistent and easy to navigate.
Tool Count5/5
Ten tools is well-scoped for a learning-tracking MCP server covering feature lifecycle, context, decision/debug capture, Codex session synchronization, evidence retrieval, and review export. Each tool has a clear purpose and none feel redundant.
Completeness4/5
The core lifecycle is well covered: start a feature, capture decisions and debugging, sync sessions, retrieve evidence, save reviews, and finish. The main gap is the lack of update/correction or delete/abandon operations for recorded data, though this can be worked around by appending new records.
Average 2.9/5 across 10 of 10 tools scored.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It tells the caller that tracking starts and that project_root is required, but it does not mention side effects, persistence, what data is stored, or what happens if tracking already exists.
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 short and front-loaded, with no filler, but brevity results in significant under-specification. It is minimal rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, two sentences are grossly insufficient. The agent cannot confidently determine how to populate the scope arrays, what success_conditions should contain, or what outcome to expect after calling the tool.
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 explains only project_root. The remaining six parameters, including the important user_owned_scope and ai_allowed_scope arrays, are not semantically clarified, leaving an agent without guidance for filling them correctly.
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 uses a specific verb ('start') and resource ('new feature/task learning tracking'), so an agent can tell the tool initializes tracking. It does not explicitly contrast with sibling tools like record_decision or finish_feature, which keeps it from a 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 only states a calling requirement (project_root must be passed explicitly) and gives no guidance about when to use this tool versus siblings such as record_decision, finish_feature, or get_learning_history. No alternatives or exclusions are mentioned.
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 carries the full disclosure burden, but it only says the tool 'selectively retrieves' details. It does not explain what happens with the 'refs' list, how 'max_chars' truncates, whether the tool is purely read-only, or what a valid 'feature_id' looks like. Naming evidence types adds a little context but not enough for transparent behavioral expectations.
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 single153 sentence with no filler, and the key idea ('selectively retrieves specific evidence details') appears upfront. It earns high marks for economy and structure, though the Korean phrasing is slightly awkward.
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 there is no output schema, no annotations, and three parameters with zero schema descriptions, the description is too thin to be a complete invocation guide. The agent knows the tool fetches evidence details from the manifest, but lacks semantics for required parameters, return format, and edge cases like max_chars truncation.
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 only partially compensates. The phrase 'specific evidence items (decision, debug, diff, commit, etc.)' hints at possible 'refs' values, and 'selectively' implies filtering, but there is no explanation of 'feature_id' or 'max_chars'. Two of the three parameters remain semantically unexplained.
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 states a clear verb ('가져옵니다' / retrieves) and a specific resource: detailed history of specific evidence items from the manifest, with the item types (decision, debug, diff, commit, etc.) listed. This distinguishes it from generic tools, though it does not explicitly name a sibling to differentiate from, so it stops short of a 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 gives no guidance about when to use this tool versus alternatives like get_feature_manifest or get_learning_history. There is no 'use this instead when...' or 'not for...' information, so the agent must infer usage from the name and short description.
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, the description carries full burden and only discloses that data is saved and optionally exported to Obsidian. It omits important behavioral details: whether export overwrites or creates notes, whether the operation is idempotent, any prerequisites for Obsidian export, or whether saving affects other project state. The optional-export behavior is a useful hint but not enough for a mutation/export tool.
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 one short sentence that front-loads the core action. It contains no redundant filler beyond the '[MCP Tool]' prefix. It is appropriately concise for the amount of meaning it conveys, though it sacrifices helpful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 9 parameters (7 required), a nested object, an optional export side-effect, and no output schema or annotations. The one-line description is grossly insufficient: it leaves parameter semantics, side effects, return behavior, prerequisites, and relationship to sibling lifecycle tools entirely unexplained.
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 provides no parameter-level meaning. It says the tool saves 'review data' but does not clarify the ownership object structure, the expected format of code_flow, the meaning of alternatives vs. weaknesses, or what verified and export_to_obsidian control. The description fails to compensate for the schema's lack of descriptions.
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 action ('saves learning retrospective/review data') and a clear context ('after feature implementation is complete'), plus an optional secondary action ('export to Obsidian Vault'). It is clear and informative, though it does not explicitly differentiate itself from siblings like record_decision or record_debug_attempt beyond the inherent difference in the resource.
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 provides a temporal condition for use: after feature implementation is complete. This implies the tool belongs at the end of the feature lifecycle. However, it does not mention alternatives, exclusion criteria, or how this relates to finish_feature or record_decision, leaving some routing ambiguity.
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?
No annotations are provided, so the description must carry the full behavioral transparency burden. It states that the tool connects a session file to a feature and computes a token delta, but it does not disclose side effects, whether data is mutated, permission requirements, reversibility, or what the response contains. This is a significant gap for a tool with no annotations and no output schema.
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 sentence that conveys the core operation without unnecessary elaboration. The '[MCP Tool]' prefix is minor namespace noise, but the rest is compact and direct. It earns a high score for conciseness, though it sacrifices detail for brevity.
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 no annotations, no output schema, and a phase parameter that clearly affects behavior, the description is not complete enough. The agent is left without critical context about what each phase does, what the calculated delta represents, and what the tool returns after execution. This is a materially incomplete definition for a stateful sync operation.
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?
The schema provides only titles for parameters and no descriptions, so coverage is very low. The description adds useful meaning for session_file (a Codex CLI .jsonl log) and feature_id (a feature), and mentions token usage delta, but it does not explain the phase parameter at all. With three parameters and minimal schema documentation, the description only partially compensates.
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 identifies the tool's action: syncing a Codex CLI session log (.jsonl) to a feature and calculating the consumed token usage delta. It names a specific resource and operation, which distinguishes it from the sibling tools (e.g., start_feature, finish_feature) even without explicitly naming them. However, it does not explicitly differentiate itself from any sibling or state what the sync entails.
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 guidance on when this tool should be used, when it should not be used, or how it relates to alternatives like start_feature or finish_feature. The phase enum (start/update/finish) implies lifecycle usage, but the description does not explain which phase applies in which situation, leaving the agent to infer the intended workflow.
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?
No annotations are provided, so the description carries the full disclosure burden. It clearly states that the operation mutates feature state to completed and updates Codex token usage, but it does not disclose reversibility, permission requirements, failure behavior, or other side effects. The word '최종' hints at finality but does not explain consequences.
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 short, front-loaded sentence with no redundant clauses. The '[MCP Tool]' prefix is minor noise, but otherwise the structure is efficient.
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 state-changing tool with no annotations and no output schema, this description is incomplete: it omits what the caller should expect after completion, whether the operation is reversible, and how to obtain or format feature_id. It works as a high-level summary but not as a complete invocation guide.
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 feature_id has only a title, so the description must compensate for the missing parameter meaning. It does not explain feature_id's format, source, or valid values; the only implied meaning is that it identifies the in-progress feature being completed.
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 action ('진행 중인 기능을 완료(completed) 처리') and a concrete resource (features), and it adds the distinct side effect of finalizing Codex session token usage. This distinguishes it from start_feature and sync_codex_session, though it does not explicitly name alternatives, so it stops short of a 5.
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 phrase '진행 중인 기능' implies the trigger condition: use this when finishing an in-progress feature. However, there is no when-not-to-use, no prerequisite guidance, and no explicit comparison to siblings like start_feature or sync_codex_session.
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?
Annotations are absent, so the description carries the burden of behavioral disclosure. It conveys a write/recording side effect but does not reveal whether decisions are appended, deduplicated, tied to an existing feature, or returned with an ID; no failure or permission implications are mentioned.
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?
A single focused sentence that front-loads the tool's purpose and adds minimal noise. The '[MCP Tool]' prefix is unnecessary, but otherwise every phrase earns its place.
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 six-parameter recording tool with no annotations and no output schema, the description is too thin: it lacks usage guidance, behavioral expectations, and parameter clarification. An agent could call it correctly based on names and schema, but only by guessing at conventions.
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 only partially maps to parameters: '선택 대안' aligns with alternatives and '결정 주체' with decided_by, while feature_id, question, chosen_option, and reason are left to their bare names. It adds some domain context but does not sufficiently compensate for the total absence of schema descriptions.
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 uses a specific verb ('기록합니다' / records) and names the resource: important architecture or implementation decisions, alternatives, and decision subject. It is clear enough to distinguish from unrelated siblings, though it does not explicitly contrast with record_debug_attempt.
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 phrase '아키텍처 또는 구현 방식에 관한 중요한 의사결정' implies this tool is for significant design decisions rather than routine logs or debug attempts. However, it never states when to prefer this tool over record_debug_attempt or other siblings, and gives no exclusions or prerequisites.
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 provided, the description carries the full burden of behavioral disclosure. The word '조회합니다' indicates a read/query operation and the description states what data is returned, which is helpful. However, it does not mention whether results are paginated, sorted, or limited beyond the schema's 'limit' parameter, nor does it clarify any access considerations.
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 sentence that immediately states the resource and action, making it easy to scan. The only waste is the '[MCP Tool]' prefix, which is redundant metadata, but overall the structure is tight and front-loaded.
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 relatively simple read tool with two parameters and no output schema, the description covers the core purpose and the nature of the returned data. However, it omits parameter semantics and any usage context, so an agent has only partial information needed to invoke it confidently.
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%, so the description must compensate by clarifying parameter meaning. It does not describe 'project_slug' or 'limit' at all. The names are somewhat self-explanatory, but the description adds no semantic value beyond the schema itself.
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 uses a specific verb ('조회합니다' / retrieves) and clearly identifies the resource: the project's recent learning review records and top recurring weaknesses list. It distinguishes the tool from siblings like get_project_context or get_evidence by naming a distinct data domain, though it does not explicitly contrast itself with any sibling.
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 guidance is given about when to use this tool versus alternatives such as get_project_context or get_evidence. There are no stated conditions, exclusions, or hints about whether this should be called before or after other learning/review operations.
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 provided, the description carries the behavioral burden. The verb 조회합니다 strongly implies a read-only operation, and the retrieved contents are named. However, it does not mention prerequisites such as needing a valid Git repository, return format, or behavior when no active feature exists.
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 sentence with no redundant clauses. The '[MCP Tool]' prefix is unnecessary noise, but the core statement is appropriately sized and readable.
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 one-parameter read-only tool, the description is functional, but because there is no output schema or annotations, it should provide more context about return shape or prerequisites. It names the contents returned but not their structure or edge-case behavior.
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%, so the description must compensate. It only adds that project_root is a '경로' (path), which is already implied by the parameter name and title. It does not clarify whether the path should be absolute or relative, or whether it must be the repository root.
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 a specific action (조회합니다/query) and a concrete resource (Git status and currently active feature for a project_root). It is easy to understand what the tool does, but it does not explicitly contrast itself with sibling tools such as get_feature_manifest or get_learning_history.
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 guidance about when to use this tool versus its siblings. The description only says what it retrieves, not when it should be preferred over the other read-oriented tools like get_evidence or get_feature_manifest, so the agent must infer the appropriate use case.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a compressed/token-efficient representation rather than the full transcript, which is a meaningful behavioral trait. It does not discuss other side effects, limits, or authorization requirements, but the read-only verb '조회합니다' and the described output cover the main behavior.
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?
One concise, front-loaded sentence that communicates the core purpose and differentiator before any other detail. The '[MCP Tool]' prefix adds slight noise but does not undermine 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?
There is no output schema and no annotations, and the two parameters are undocumented in both the schema and the description. The description gives a high-level idea of the return value but not the structure, parameter semantics, or how 'compressed manifest' relates to 'evidence ref list', leaving an agent short of the information needed for confident invocation.
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 makes no mention of feature_id or the detail enum. An agent must infer the meaning of 'quick' vs 'standard' and the format of feature_id solely from parameter names and types, with no assistance from the tool description.
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 states a specific retrieval action (조회합니다) and a precise resource: a token-efficient compressed manifest and evidence reference list rather than the full transcript. This clearly differentiates it from a full-transcript tool and from siblings like get_evidence, even though no sibling is explicitly named.
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 phrase 'instead of the full transcript' gives a clear context for when to use this tool, i.e., when a token-efficient overview is preferred. However, it does not explicitly mention alternatives from the sibling list, exclusions, or prerequisites, so usage guidance is implied rather than fully specified.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool 'records' debug information, but does not state whether this creates a persistent log, whether it updates existing records, whether it requires a valid feature_id, or what side effects occur. This is a significant transparency gap.
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. Every phrase contributes meaningful context about the tool's scope and contents.
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, no output schema, and six parameters, the description is too minimal to fully support correct invocation. It lacks guidance on how feature_id relates to the debug attempt, what outcome represents, the meaning of status values, and what happens after recording. The tool's purpose is clear, but operational completeness is weak.
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 0%, so the description must compensate. It adds meaning for symptom, hypotheses, verification, and debugging status, but it does not mention feature_id, and outcome is only loosely implied by 'experiment results.' The mapping is partial but helpful.
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 uses a specific action ('기록합니다' = records) and a clear resource (bug cause investigation: symptoms, hypotheses, experiment results, debugging status). It clearly describes what the tool does, though it does not explicitly differentiate it from sibling tools like record_decision.
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 description provides clear usage context: use this when investigating the cause of a bug and needing to record symptoms, hypotheses, verification, and debugging state. It does not mention alternatives or explicit when-not-to-use conditions, but the context is specific enough for basic routing.
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:

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

Score Badge

Copy to your README.md:

[![AI-learning-mcp MCP server](https://glama.ai/mcp/servers/giseungNoh/AI-learning-mcp/badges/score.svg)](https://glama.ai/mcp/servers/giseungNoh/AI-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/giseungNoh/AI-learning-mcp'

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