Skip to main content
Glama
rocnubie

LessonLab MCP Server

by rocnubie
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Hi AI Tutor MCP Server

Hi AI Tutor - Turn source material into an interactive lesson

MCP Badge License: MIT Stdio Transport Zero Config Read Only Node MCP

A read-only Model Context Protocol server for the canonical Hi AI Tutor knowledge surface: lesson inputs, generated learning formats, plan boundaries, pricing, FAQ, and official links. It runs over stdio with no API key or remote dependency.

Official website: https://hiaitutor.com

About Hi AI Tutor

Hi AI Tutor helps people turn a PDF, notes, or a topic into an interactive lesson. Its public product surface covers narrated slides, self-grading quizzes, simulations where appropriate, shareable lessons, and paid export options such as editable PowerPoint files.

This MCP provides documented product context only. It does not upload documents, generate lessons, spend credits, grade learners, or return PowerPoint files. Use the live website for current generation modes, file limits, plan terms, and exports. Source fidelity and teaching suitability still require human review.

Related MCP server: CogniLedger Makuri MCP Server

Tools

get_lesson_workflow

Return the documented lesson-generation workflow, outputs, and plan boundaries.

get_pricing

Return the canonical pricing entry point.

get_official_links

Return the canonical Hi AI Tutor links.

Resources

  • site://hiaitutor/lesson-workflow - Public lesson inputs, generated formats, exports, and plan boundaries.

  • site://hiaitutor/pricing - Canonical pricing entry point.

  • site://hiaitutor/faq - Product scope and safety boundaries.

  • site://hiaitutor/links - Canonical URLs to share with users.

Prompts

tell_me_about_hiaitutor

Summarize what Hi AI Tutor is, who it is for, and how it works.

plan_a_lesson_hiaitutor

Plan an interactive lesson from a topic or source document without claiming that the MCP generated it.

Installation

Install via Smithery

npx -y @smithery/cli install hiaitutor-mcp --client claude

Replace claude with cursor, windsurf, or continue for those clients.

Install from source

git clone https://github.com/rocnubie/hiaitutor-mcp.git
cd hiaitutor-mcp
pnpm install

Add the server to the MCP client configuration:

{
  "mcpServers": {
    "hiaitutor-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/hiaitutor-mcp/src/index.mjs"
      ]
    }
  }
}

Debug with MCP Inspector

npx @modelcontextprotocol/inspector node src/index.mjs

Official Links

Development

pnpm install
pnpm start

License

MIT

Available Tools

3 tools
get_lesson_workflowA

Return the documented lesson-generation workflow, outputs, and plan boundaries exposed by the site. (LessonLab)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations exist, so the description carries full burden. It does not mention read-only behavior, idempotency, or potential side effects, though the purpose implies a safe retrieval.

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

Conciseness5/5

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

A single concise sentence with no wasted words; directly states the tool's function.

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

Completeness4/5

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

For a no-parameter retrieval tool, the description covers the essential output (workflow, outputs, plan boundaries) and is sufficient for an agent, though lacking output schema details.

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?

No parameters exist, so baseline is 4. The description adds no param info, but that is acceptable since there are none.

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 clearly states the tool returns the lesson-generation workflow, outputs, and plan boundaries, distinguishing it from sibling tools like get_pricing and get_official_links.

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 on when to use this tool vs alternatives; no context about prerequisites or typical use cases provided.

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

get_pricingA

Return the canonical pricing entry point for LessonLab.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states the tool returns a 'canonical pricing entry point', but does not disclose data freshness, authentication requirements, rate limits, or any potential side effects. This is insufficient for an agent to understand the tool's behavior.

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 that conveys the essential information without any filler. It is appropriately sized 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?

Given no output schema, the description should explain the return value. It does not describe what the 'pricing entry point' contains (e.g., a URL, object, or list). The description is minimally adequate but leaves significant gaps for an agent.

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 no parameters (schema coverage 100% vacuously). With 0 parameters, the baseline is 4. The description adds context by specifying 'LessonLab' and 'canonical pricing entry point', providing meaning beyond the empty schema.

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 clearly states the verb 'Return' and the specific resource 'canonical pricing entry point for LessonLab', making the tool's purpose unambiguous. It distinguishes itself from siblings like get_lesson_workflow and get_official_links.

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 does not explicitly state when to use this tool versus alternatives. The usage context is implied by the tool name and description, but there are no exclusions or guidance about when not to use it.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedget_lesson_workflow
    • First observedget_official_links
    • First observedget_pricing
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool targets a distinct aspect: workflow, pricing, and official links. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent get_{noun} pattern (get_lesson_workflow, get_pricing, get_official_links), making it predictable for an agent.

Tool Count4/5

Three tools is a reasonable count for an informational server focused on LessonLab documentation. It is not overly sparse, though a few more tools could enhance completeness.

Completeness4/5

The set covers core informational needs (workflow, pricing, links) but lacks additional resources like features or use cases. Minor gaps exist but agents can work around them.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/rocnubie/hiaitutor-mcp'

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