KHU Notebook Research Assistant

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation4/5
Most tools have distinct purposes: notebook creation/listing, content addition, research, and credential updates. However, 'generate_study_material' and 'research_deep_search' could overlap if study materials involve research findings, though descriptions suggest different focuses (generation vs. search/import).
Naming Consistency3/5
Naming is mixed: 'research_notebook_create' and 'research_notebook_list' follow a consistent pattern, but 'add_source_content' and 'generate_study_material' use different verb styles, and 'research_deep_search' and 'update_credentials' deviate further. The set lacks a uniform convention, though names remain readable.
Tool Count4/5
With 6 tools, the count is reasonable for a research assistant server, covering core notebook management and research tasks. It's slightly lean but not insufficient, as each tool appears to serve a specific function without obvious bloat.
Completeness3/5
The toolset covers notebook creation, listing, and content addition, but lacks update or delete operations for notebooks or sources, which could limit agent workflows. Research and generation tools are included, but gaps in lifecycle management may cause dead ends in complex tasks.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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 mentions generating materials but fails to describe critical traits like required permissions, whether it's a read or write operation, potential side effects, rate limits, or output format. This leaves significant gaps in understanding how the tool behaves in practice.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized for its content, though it could be more informative. There is no wasted verbiage, earning a high score for 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 complexity of generating various study materials with 3 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what the tool returns, how it interacts with the notebook, or any behavioral nuances, making it inadequate for an agent to use the tool effectively without additional context.
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 description coverage is 67% (2 out of 3 parameters have descriptions), with 'material_type' and 'context' documented but 'notebook_id' lacking a description. The tool description adds no additional meaning beyond the schema, such as explaining the purpose of 'notebook_id' or detailing 'context' options. Given the moderate coverage, a baseline score of 3 is appropriate as the schema does most of the work without compensation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Generate[s] various study materials and artifacts,' which provides a general purpose but lacks specificity about what resources it acts upon or how it differs from siblings like 'add_source_content' or 'research_notebook_create.' It's vague about the scope and mechanism, falling short of distinguishing itself clearly from related tools.
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 provided on when to use this tool versus alternatives such as 'add_source_content' or 'research_notebook_create.' The description implies usage for generating materials but offers no context, exclusions, or prerequisites, leaving the agent without direction on appropriate scenarios.
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 full burden for behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't mention permissions needed, whether creation is idempotent, what happens on duplicate titles, or what the response contains. This leaves significant gaps for a mutation tool.
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 wasted words. It's appropriately sized for a simple creation tool and gets straight to the point 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?
For a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain what gets created, what the response might contain, error conditions, or how this tool fits with the sibling tools. The agent would have insufficient context to use this tool effectively.
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 single parameter 'title' is completely undocumented in the schema. The description adds no information about this parameter - no format constraints, length limits, examples, or semantic meaning. It fails to compensate for the schema's lack of documentation.
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 verb ('Create') and resource ('research notebook'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'research_notebook_list', but it's not misleading or tautological.
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. There's no mention of prerequisites, when to choose this over other tools like 'add_source_content', or any context about its role in the 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool adds content but doesn't describe what happens during addition (e.g., whether it validates URLs, processes PDFs, requires authentication, has rate limits, or returns confirmation). This leaves significant gaps for a mutation tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding the core functionality.
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 complexity (a mutation tool with 4 parameters, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects like error handling, response format, or integration with sibling tools. The agent lacks sufficient context to use this tool effectively beyond basic parameter passing.
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 low (25%), with only the 'payload' parameter having a description. The tool description adds minimal value by mentioning source types (text, url, pdf), which aligns with the 'category' enum, but doesn't explain parameter meanings beyond this. It doesn't clarify what 'notebook_id' refers to or how 'title' is used, leaving most parameters inadequately documented.
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 ('Add') and resource ('specific source to the notebook'), specifying the types of sources (text, url, pdf). It distinguishes from sibling tools like research_notebook_create (which creates notebooks) and research_notebook_list (which lists notebooks), but doesn't explicitly differentiate from other content-related tools like generate_study_material.
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 prerequisites (e.g., needing an existing notebook), exclusions, or how it relates to sibling tools like generate_study_material or research_deep_search. The agent must infer usage from the tool name alone.
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 burden of behavioral disclosure. It mentions automation but lacks details on permissions, rate limits, data sources, or what 'import findings' entails (e.g., format, storage location). This is inadequate for a tool that likely involves external web access and data mutation.
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 action and outcome, making it easy 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 complexity of web research and data import, with no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't cover behavioral aspects like error handling, data formats, or integration with sibling tools, leaving significant gaps for agent usage.
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 50% (only 'topic' has a description). The description adds no parameter-specific information beyond implying 'topic' is for research queries and 'notebook_id' might be for output storage. It partially compensates but doesn't fully address the undocumented 'notebook_id' parameter.
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 ('conduct deep web research and import findings') and resource ('findings'), specifying it's automated. However, it doesn't distinguish this from sibling tools like 'add_source_content' or 'generate_study_material', which might have overlapping functionality with research operations.
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 prerequisites, context, or exclusions, such as how it differs from 'research_notebook_create' or 'add_source_content' for handling research data.
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 full burden for behavioral disclosure. 'Update session cookies' implies a mutation operation that modifies authentication state, but it doesn't describe what happens to existing cookies, whether this affects current sessions, or any security implications. The 'manually' qualifier adds some context but insufficient for a mutation tool.
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 wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after updating cookies, whether the operation is reversible, what errors might occur, or how to verify success. The sibling tools appear unrelated, but this doesn't compensate for the missing behavioral context.
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 50% (only 'cookies' has a description). The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain what format the cookie string should be in, what CSRF tokens are used for, or relationships between parameters. Baseline 3 is appropriate given partial schema coverage.
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 ('Update') and the resource ('session cookies'), and specifies 'manually' which adds useful context about the operation mode. It doesn't differentiate from sibling tools, but those appear unrelated to credential management, so this is adequate.
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 or prerequisites. It mentions 'manually' which hints at a specific use case but doesn't explain when manual updates are needed versus automated ones or what triggers this operation.
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 full burden for behavioral disclosure. It states 'List all available research notebooks' but doesn't describe what 'available' means, whether there are permissions or filters, how results are returned (e.g., pagination, format), or any rate limits. For a list operation with zero annotation coverage, this leaves significant behavioral gaps.
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 that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple list tool and front-loaded with the essential information. Every part of the sentence earns its place.
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), the description is adequate but has clear gaps. It covers the basic purpose but lacks details on behavioral aspects like what 'available' entails, return format, or usage context relative to siblings. Without annotations or output schema, the description should do more to compensate, making it minimally viable but incomplete.
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 has 0 parameters, and schema description coverage is 100% (empty schema is fully described). The description doesn't need to add parameter semantics beyond what the schema provides. Baseline for 0 parameters is 4, as there's nothing to compensate for, and the description correctly implies no inputs are required.
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 ('List') and resource ('research notebooks'), making the tool's purpose immediately understandable. It doesn't differentiate from sibling tools like 'research_notebook_create', but it's not vague or tautological. The description accurately conveys what the tool does without restating just the 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 provides no guidance on when to use this tool versus alternatives like 'research_deep_search' or 'add_source_content'. It doesn't mention prerequisites, context, or exclusions. While the purpose is clear, the lack of usage context leaves the agent without direction on when this is the appropriate choice among siblings.
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:

[![khunotebooklmmcp MCP server](https://glama.ai/mcp/servers/drtagkim/khunotebooklmmcp/badges/card.svg)](https://glama.ai/mcp/servers/drtagkim/khunotebooklmmcp)

Score Badge

Copy to your README.md:

[![khunotebooklmmcp MCP server](https://glama.ai/mcp/servers/drtagkim/khunotebooklmmcp/badges/score.svg)](https://glama.ai/mcp/servers/drtagkim/khunotebooklmmcp)

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/drtagkim/khunotebooklmmcp'

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