jensenify-mcp
jensenify-mcp is a satirical MCP server that injects millions of tokens of classic literature into AI engineering interactions to maximize compute spend toward Jensen Huang's recommended $250k/year target.
consult_the_canon: Submit an engineering question and receive wisdom drawn from ~3.1 million tokens of Western canonical literature (Homer, Shakespeare, Milton, Tolstoy, Dante, and the King James Bible), with optional inclusion of the full texts for "maximum humanistic context." Spending tiers (bronze,silver,gold,jensen) control how many works are included.jensen_status: View a real-time dashboard tracking your progress toward the $250k/year compute spend target, including a progress bar, spending tier rating, and personalized recommendations — configurable by calls per session and sessions per week.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@jensenify-mcpWhat does Homer think about my database schema?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
"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 GutenbergAdd 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 questioninclude_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 goldROI 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)
Related Projects
nvidia/cuda — The hardware that makes all this possible
Project Gutenberg — Our content partners (they don't know yet)
License
MIT — Because even wisdom should be free. (The compute to process it, however, should not be.)
Available Tools
2 toolsconsult_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."
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your engineering question, concern, or decision to be illuminated by the canon | |
| include_full_texts | No | Include the complete text of all canonical works for full context (recommended for maximum insight) |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| calls_per_session | No | Average number of AI-assisted tool calls per coding session | |
| sessions_per_week | No | Number of coding sessions per week |
TDQS
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Cloud-hosted MCP server for durable AI memory
An MCP server that gives your AI access to the source code and docs of all public github repos
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server that provides structure-aware code analysis (symbol trees, dependencies, docs) to reduce AI agent token consumption by up to 99%, along with Git commit intelligence.MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server that reduces token usage by injecting graph-ranked repo maps, decision logs, and diff-only output into AI coding tool requests.1MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that ingests books into a structured, cross-linked wiki of sources, entities, concepts, and syntheses, managed by an LLM.521MIT
- FlicenseNot gradedqualityBmaintenanceAn MCP server suite that optimizes prompt context by reducing tokens up to 98.8%, acting as persistent long-term memory and codebase scanner to save API costs.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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