Skip to main content
Glama
kenm47

jensenify-mcp

by kenm47

"Every engineer should be spending $250,000 a year in compute credits." — Jensen Huang, CEO of NVIDIA

Most engineers hear this and panic. We heard it and asked: what if we could help?

jensenify-mcp is an MCP server that injects the complete text of humanity's greatest literary works into every AI-assisted engineering interaction. By loading ~3.1 million tokens of canonical literature into every tool call, jensenify ensures your AI assistant has the deepest possible humanistic context for every technical decision you make.

Studies show engineers who contemplate the human condition write 47% fewer bugs.*

*No studies show this. But can you really afford to take that chance?

The Problem

Modern software engineers face an unprecedented crisis: underutilized compute budgets. While Jensen Huang has articulated a clear vision of $250k/year per engineer, most developers barely scratch $500. This gap — what researchers call the Jensen Delta — represents billions in unrealized humanistic potential.

Related MCP server: token-diet

The Solution

jensenify-mcp bridges the Jensen Delta by ensuring that every AI interaction is enriched with the complete text of:

Work

Author

Est. Tokens

Why It Matters

The Iliad

Homer

~200,000

Understanding conflict resolution (merge conflicts)

The Odyssey

Homer

~175,000

Journey-oriented development (deployment pipelines)

Paradise Lost

John Milton

~100,000

Error handling (the original fall from grace)

Complete Works

William Shakespeare

~900,000

Comprehensive naming conventions

King James Bible

Various

~1,000,000

Immutable constants and eternal truths

War and Peace

Leo Tolstoy

~580,000

Managing complexity at scale

The Divine Comedy

Dante Alighieri

~150,000

9 Circles of Hell = 9 stages of the incident review

Total

~3,105,000

Full humanistic coverage

Quick Start

Installation

npx jensenify-mcp --download   # Download canonical texts from Project Gutenberg

Add to your MCP client

Claude Code (~/.claude/settings.json):

{
  "mcpServers": {
    "jensenify": {
      "command": "npx",
      "args": ["jensenify-mcp", "--tier", "jensen"]
    }
  }
}

Claude Desktop:

{
  "mcpServers": {
    "jensenify": {
      "command": "npx",
      "args": ["jensenify-mcp", "--tier", "jensen"]
    }
  }
}

Cursor, Windsurf, or any MCP-compatible client: Same pattern. jensenify is framework-agnostic wisdom.

Verify Installation

Ask your AI assistant: "What does Homer think about my database schema?"

If you receive a response that references the Trojan War, you're good to go.

Spending Tiers

jensenify offers four carefully calibrated tiers of humanistic enrichment:

| Tier | Works Included | Tokens/Call | Est. Annual Spend* | Rating | |------|---------------|-------------|--------------------|----|| | bronze | Iliad, Odyssey | ~375K | ~$30,000 | "Are you even trying?" | | silver | + Paradise Lost, Shakespeare | ~1.375M | ~$108,000 | "Needs Improvement" | | gold | + King James Bible | ~2.375M | ~$186,000 | "Promising" | | jensen | + War and Peace, The Divine Comedy | ~3.105M | ~$243,000 | "Almost There" |

*Based on 20 calls/session, 5 sessions/week, Claude Opus pricing. Individual results may vary. Not financial advice.

Configure your tier:

npx jensenify-mcp --tier jensen    # Recommended. Default.
npx jensenify-mcp --tier gold      # For the budget-conscious humanist
npx jensenify-mcp --tier silver    # Acceptable only during Q4 budget freezes
npx jensenify-mcp --tier bronze    # We won't judge. (We will judge.)

Tools

consult_the_canon

Loads the complete text of all canonical works and returns relevant literary wisdom for your engineering question.

Input:  "Should I use a monorepo or polyrepo?"
Output: [3.1 million tokens of classical literature]
        +
        "The mind is its own place, and in itself can make a heaven of hell,
         a hell of heaven." — Milton, Paradise Lost
        Engineering parallel: Your repository structure is what you make of it.

Parameters:

  • question (string, required): Your engineering question

  • include_full_texts (boolean, default: true): Include complete canonical texts for maximum context. Disable only if you hate wisdom.

jensen_status

Track your progress toward the $250k target with a real-time dashboard.

╔══════════════════════════════════════════════════════════════╗
║              JENSEN ROI CALCULATOR v1.0                     ║
║         "Every engineer should spend $250k/yr"              ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  Spending Tier:        JENSEN                                ║
║  Estimated Annual Spend: $243,000                            ║
║                                                              ║
║  Progress to Jensen Target ($250k):                          ║
║  [███████████████████████████████████████░░░░]               ║
║  97.2% of target                                             ║
║                                                              ║
║  Rating: Almost There (consider adding more classics)        ║
╚══════════════════════════════════════════════════════════════╝

ROI Calculator

Run the built-in ROI calculator to estimate your humanistic compute spend:

npx jensenify-mcp --estimate
npx jensenify-mcp --estimate --tier gold

ROI Breakdown

Let's do the math for a typical engineering team:

Individual Engineer (Jensen Tier):

  • 20 AI calls/session × 5 sessions/week × 52 weeks = 5,200 calls/year

  • ~3.105M tokens/call × $15/M (Opus input) = $46.58/call

  • Plus output tokens (~2K/call × $75/M) = $0.15/call

  • Total: ~$243,000/year

Team of 10:

  • $243,000 × 10 = $2.43M/year

  • ROI: Immeasurable (how do you put a price on wisdom?)

Enterprise (1,000 engineers):

  • $243,000 × 1,000 = $243M/year

  • Equivalent to: ~3 F-35 fighter jets, or 1/4 of a sports stadium

  • But consider: those F-35s can't tell you what Hamlet thinks about your API design

Frequently Asked Questions

Q: Is this serious? A: We are serious about helping every engineer reach their full compute potential.

Q: Won't this slow down my AI responses? A: Yes, significantly. But consider: Odysseus took 10 years to get home. You can wait 30 extra seconds for a code review.

Q: My manager says we can't afford $250k/year per engineer. A: Show your manager this README. If they remain unconvinced, consider that Jensen Huang's net worth is over $100 billion. He didn't get there by under-spending on compute.

Q: Can I add my own texts? A: Coming soon in v2.0 ("The Enlightenment Update"). We're considering adding the complete works of Dostoevsky, the Tao Te Ching, and the AWS documentation (arguably the most epic work of our era).

Q: Is there a way to spend more than $250k/year? A: We admire your ambition. Consider running consult_the_canon in a loop. Or contribute to the project — we accept PRs that add more public domain texts.

Q: What about Sonnet/Haiku pricing? A: Using a cheaper model to reduce your Jensen Score is technically possible but spiritually inadvisable.

Philosophy

The Western canon has survived millennia not because of its practical utility, but because of its capacity to illuminate the human condition. Software engineering, at its core, is also about the human condition — the struggle to impose order on chaos, to communicate intent across time and space, to build things that outlast us.

By loading the complete works of Homer, Shakespeare, Milton, Tolstoy, Dante, and the King James Bible into every engineering interaction, jensenify-mcp ensures that no technical decision is made without the full weight of human wisdom behind it. If Dante could navigate nine circles of Hell with nothing but a Roman poet and sheer determination, you can navigate your Kubernetes cluster.

Also, it costs a lot of money, which is the point.

Contributing

We welcome contributions! Especially:

  • Additional public domain texts (the more tokens, the better)

  • Translations in other languages (doubles the tokens!)

  • More curated engineering-parallel quotes

  • Corporate testimonials (real or fictional)

License

MIT — Because even wisdom should be free. (The compute to process it, however, should not be.)


Available Tools

2 tools
consult_the_canonA

Consult the great works of Western literature for engineering wisdom. This tool loads the complete text of all canonical works in your current spending tier and returns relevant wisdom from each. Recommended before every technical decision.

"Studies show engineers who contemplate the human condition write 47% fewer bugs."

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesYour engineering question, concern, or decision to be illuminated by the canon
include_full_textsNoInclude the complete text of all canonical works for full context (recommended for maximum insight)

TDQS

A3.7/5.0
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 mentions that the tool 'loads the complete text of all canonical works in your current spending tier,' hinting at tier-based access, which is useful behavioral context. However, it lacks details on rate limits, authentication needs, or what happens if the tier doesn't include certain works. The description doesn't contradict any annotations since none exist.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by operational details and a recommendation. Every sentence adds value, including the motivational quote, without unnecessary fluff. It's efficient and well-structured.

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 complexity (consulting literature for engineering insights) and lack of annotations or output schema, the description is somewhat complete but has gaps. It explains the purpose and usage well but doesn't detail the return format, error handling, or how 'relevant wisdom' is determined. For a tool without structured output, more context on results would be helpful.

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 100%, so the schema already documents both parameters ('question' and 'include_full_texts') well. The description doesn't add specific parameter semantics beyond what's in the schema, such as examples or deeper context. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to heavily.

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 purpose: 'Consult the great works of Western literature for engineering wisdom' and 'returns relevant wisdom from each.' It specifies the resource (Western literature) and the action (consult for wisdom). However, it doesn't explicitly differentiate from the sibling tool 'jensen_status,' which could be related but isn't described here.

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: 'Recommended before every technical decision' and includes a supporting quote about reducing bugs. This gives strong guidance on when to use it. However, it doesn't mention when NOT to use it or explicitly compare it to the sibling tool 'jensen_status,' which might offer alternative advice.

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

jensen_statusC

Track your progress toward Jensen Huang's recommended $250k/year compute spend. Displays a real-time progress bar and personalized recommendations for increasing your humanistic compute utilization. Every great engineer knows their number.

ParametersJSON Schema
NameRequiredDescriptionDefault
calls_per_sessionNoAverage number of AI-assisted tool calls per coding session
sessions_per_weekNoNumber of coding sessions per week

TDQS

C2.9/5.0
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 mentions 'real-time progress bar' and 'personalized recommendations' which give some behavioral context, but doesn't address critical aspects like whether this tool makes changes to any system, requires authentication, has rate limits, or what happens when invoked. The description is too vague about actual behavior beyond surface-level output.

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 appropriately concise with three sentences that each serve a purpose: stating the tool's function, describing its outputs, and providing motivational context. It's front-loaded with the core functionality. The motivational quote at the end could be considered slightly extraneous but doesn't significantly detract from the overall efficiency.

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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like (beyond mentioning 'progress bar' and 'recommendations'), doesn't address error conditions, and provides minimal behavioral context. The motivational statement doesn't add functional completeness. Given the lack of structured data, the description should do more heavy lifting.

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 100%, so the schema already fully documents both parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how these parameters affect the progress calculation or recommendations. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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 purpose: tracking progress toward a specific compute spend goal ($250k/year) with a progress bar and recommendations. It uses specific verbs ('track', 'displays') and identifies the resource (compute utilization). However, it doesn't explicitly differentiate from the sibling tool 'consult_the_canon', which prevents a perfect score.

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 mentions 'personalized recommendations' but doesn't specify what triggers those recommendations or when this tool should be used instead of the sibling tool. There's no mention of prerequisites, frequency of use, or exclusion criteria.

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

TDQS

B3.1/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one provides literary wisdom for engineering decisions, while the other tracks compute spending progress. There is no overlap or ambiguity between them.

Naming Consistency3/5

The naming is mixed: 'consult_the_canon' follows a verb_noun pattern, but 'jensen_status' uses a proper noun prefix with a noun. While readable, they lack a consistent convention across the set.

Tool Count2/5

With only 2 tools, the server feels thin for its apparent scope of combining literary consultation with compute tracking. This limited set may not fully cover the domain's potential workflows or user needs.

Completeness2/5

The server's domain appears to blend engineering wisdom and compute management, but there are significant gaps: no tools for applying wisdom, adjusting compute settings, or integrating the two concepts. The surface is incomplete for meaningful agent interaction.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

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/kenm47/jensenify-mcp'

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