Skip to main content
Glama
Sign In
lpmoo

lpmoo

by tuhuateng
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

@lpmoo/mcp

Public, MIT-licensed stdio MCP server for lpmoo's frozen Section JSON tools.

This repository is only the MCP interface: list_templates, get_recipe, and generate_lp_sections. The default path is an offline stub. It does not contain the lpmoo SaaS (canvas, accounts, billing), the Gene catalog, the Gola knowledge base, or campaign prompts. Those stay in the private monorepo.

npx @lpmoo/mcp is not published. Do not install that name. Use this public GitHub repository.

Trust

Does

Does not

Advertise the three frozen tools and return Section JSON

Return a full HTML page (<!DOCTYPE / <html is rejected)

Run offline with no API key

Read or send AGENT_API_KEY, LPMOO_API_TOKEN, or any model key

Stay on stdout as newline-delimited JSON-RPC

Call the lpmoo API. LPMOO_MCP_MODE=remote returns mcp_byo_bridge_pending and does not use the network

The SaaS bridge (mcp_byo) is not part of this package. Production lpmoo does not run this process.

Related MCP server: cody-mcp

Install

Node 20+.

git clone https://github.com/tuhuateng/lpmoo-mcp.git
cd lpmoo-mcp
npm install
npm test

Anonymous clone of this repository is the supported install. npm test checks the tool list, schema-valid section output, HTML rejection, and a live stdio process.

Cursor and Claude Desktop

npx @lpmoo/mcp does not exist. This github: spec installs this repository:

~/.cursor/mcp.json, a project .cursor/mcp.json, or Claude Desktop's claude_desktop_config.json:

{
  "mcpServers": {
    "lpmoo": {
      "command": "npx",
      "args": ["-y", "github:tuhuateng/lpmoo-mcp"]
    }
  }
}

Claude Desktop paths: macOS ~/Library/Application Support/Claude/claude_desktop_config.json, Windows %APPDATA%\Claude\claude_desktop_config.json.

If a host prints npm's install log onto the MCP stdout channel, use a local checkout instead. Replace the path with your clone:

{
  "mcpServers": {
    "lpmoo": {
      "command": "node",
      "args": [
        "/ABS/PATH/TO/lpmoo-mcp/bin/lpmoo-mcp.mjs"
      ]
    }
  }
}

The server prints nothing until it receives JSON-RPC. A quiet terminal is it waiting.

Codex

~/.codex/config.toml (not mcp.json):

[mcp_servers.lpmoo]
command = "npx"
args = ["-y", "github:tuhuateng/lpmoo-mcp"]

Checkout fallback:

[mcp_servers.lpmoo]
command = "node"
args = ["/ABS/PATH/TO/lpmoo-mcp/bin/lpmoo-mcp.mjs"]

Optional environment

Variable

Default

Behavior

LPMOO_MCP_MODE

local

local or stub: offline section stub. remote: tools return mcp_byo_bridge_pending and make no request. Any other value is rejected.

LPMOO_API_TOKEN

unset

Reserved. This server never reads it.

Tools

  • list_templates — direction recipes. No model call.

  • get_recipe — ordered section structure (type, title, job). No copy, no HTML.

  • generate_lp_sections — ordered sections (type, spec, rationale) validated as Section JSON.

Verify

Source of truth is https://github.com/tuhuateng/lpmoo-mcp. There is no postinstall script. Tool names are checked at startup against MCP_SECTION_TOOLS in src/schema.ts. Behavior is src/stub.ts.

License

MIT. See LICENSE.

Available Tools

3 tools
generate_lp_sectionsB
Read-onlyIdempotent

Generate an ordered Section array (type, spec, rationale) from a brief and structure constraints. Never return a full-page HTML document.

NameRequiredDescriptionDefault
briefYes
constraintsNo
coachContextNo
trendSummaryNo

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value by defining the return contract (ordered Section array of type/spec/rationale) and prohibiting full-page HTML output, but says nothing about how ordering is determined, how lockedSectionIds are respected, or whether generation is deterministic.

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 short sentences with the output shape front-loaded and zero filler. Every clause carries information: what is produced, from what inputs, and the one thing never to produce.

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?

There is no output schema, and the description usefully compensates by defining the returned array shape. However, for a tool with a deeply nested brief/constraints object and 0% parameter documentation, key operational details are absent: what happens with min/maxSections conflicts, how sectionTypes constrains output, and how locked sections interact with ordering.

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 carries the full burden, yet it only names two of the four top-level inputs (brief, constraints) and none of their eight-plus nested sub-fields. coachContext and trendSummary are never mentioned, and it is unclear whether constraints.structure is a hard spec or a hint.

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?

States a specific verb (generate) and resource (an ordered Section array with type/spec/rationale), and pins down the input sources (brief, structure constraints). The negative clause 'Never return a full-page HTML document' sharpens the output boundary, though it does not name or contrast with the siblings list_templates / get_recipe.

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 explicit statement of when to call this versus alternatives, nor any prerequisites (e.g., whether a recipeId from get_recipe should be fetched first). The 'never return full-page HTML' line is an output guardrail, not usage routing, so an agent is left to infer context.

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

get_recipeA
Read-onlyIdempotent

Return ordered section structure for a recipe id (type, title, job). No copy, no HTML.

NameRequiredDescriptionDefault
recipeIdYes

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so safety is covered. The description adds real behavioral value by clarifying the response is structural only ('No copy, no HTML' and 'ordered'), but says nothing about failure behavior or how deeply nested/ordered the sections are.

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 compact sentence that front-loads the action and expected output, with the 'No copy, no HTML' constraint tacked on efficiently. No wasted text.

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 single-parameter read tool with annotations covering safety and no output schema, the description is nearly complete: it names the return fields and the structural-only nature. Only a hint about the id's origin/format is missing.

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 names the 'recipe id' concept, but adds no format, sourcing, or validation detail beyond the schema's recipeId:string, leaving the required parameter thinly 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?

States a specific verb ('Return') and resource ('ordered section structure for a recipe id') and even enumerates the returned fields (type, title, job), which lets an agent distinguish it from the template/section-generation siblings. It does not explicitly name a sibling to contrast against, keeping it just below 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?

Usage is implied by the scope ('No copy, no HTML'), which signals when NOT to use it if content is needed, but there is no explicit when-to-use guidance or named alternative among list_templates / generate_lp_sections.

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

list_templatesA
Read-onlyIdempotent

List LP direction recipes the canvas can generate from. No model call.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new context beyond them with 'No model call', telling the agent this is cheap and fast with no LLM cost or latency, which matters when choosing between this and generate_lp_sections.

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 short sentences, no filler, and the value proposition ('No model call') is placed immediately after the purpose. Nothing is repeated from the name or title.

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 zero-parameter lister with no output schema, the description should hint at what comes back – recipe names or IDs – since the agent needs those to call get_recipe next. That chaining detail is absent, though the read-only and no-model-call facts are complete.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. Schema coverage is 100% and additionalProperties is false, leaving no ambiguity about inputs.

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?

States a specific verb ('List') and resource ('LP direction recipes the canvas can generate from'), which distinguishes it from the generation sibling generate_lp_sections. It stops short of explicitly contrasting with get_recipe, and 'LP direction recipes' is domain jargon an agent may not resolve.

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 framing 'recipes the canvas can generate from' implies this is the discovery step preceding get_recipe or generate_lp_sections, but no alternative or trigger condition is named. Usage is inferable rather than stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedgenerate_lp_sections
    • First observedget_recipe
    • First observedlist_templates
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct role: list_templates enumerates available recipes, get_recipe retrieves structural details for a specific recipe id, and generate_lp_sections performs generation from a brief. The required inputs and verbs make misselection unlikely.

Naming Consistency4/5

All three names follow a consistent verb_noun snake_case pattern. The only minor drift is terminology between 'templates' and 'recipe', but the naming style itself is predictable.

Tool Count5/5

Three tools are well-scoped for a narrow LP section-generation server: discovery, structure inspection, and generation. No tool appears redundant or extraneous.

Completeness4/5

The surface covers the core lifecycle of listing recipes, inspecting a recipe structure, and generating sections. It lacks explicit validation or refinement operations, but those are not clearly required for the stated generation-focused purpose.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-maptiler

    pipeworx-io
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables geocoding, reverse geocoding, elevation profiles, static map PNGs, and coordinate reprojection using MapTiler's OpenStreetMap data.
    605 npm
    MIT

  • cody-mcp

    daolmedo
    A
    license
    A
    quality
    C
    maintenance
    Enables MCP-capable clients to search team knowledge, browse an integration catalog, and get sourced product answers through deterministic, offline tools.
    3
    7 npm
    MIT

  • LK Transit MCP

    AppKade
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables MCP clients to explore Sri Lankan transit data offline by finding nearby stops, searching and retrieving routes with ordered stop sequences, checking scheduled arrivals, and inspecting feed coverage status. All results come from bundled synthetic fixtures marked as non-production, with no live operator feeds connected.
    Apache 2.0