MCP server for the StressZero Intelligence API — burnout prevention self-assessment for AI agents, across 3 dimensions (physical, emotional, effectiveness).
Enable Claude, Cursor, Windsurf, n8n, and any MCP-compatible client to help users self-assess their workload signals in real-time conversations.
⚠️ Not a medical device. All scores are indicative, based on self-reported answers. This server provides no diagnosis, no screening, and no clinical triage. Persistent exhaustion warrants a doctor — the tools say so in their outputs.
Tool | Description |
| Self-assessed burnout signals across physical, emotional, and effectiveness dimensions. Returns an indicative score, level, contributing factors, and prevention recommendations. |
| Generate a detailed self-assessment report with action plans. Requires Starter+ tier. |
| Simplified 3-score self-check for chatbots and quick conversations. |
| Create a free API key (500 calls/month) for a user. |
Related MCP server: Env Manager AI MCP
Resource | Description |
| Complete OpenAPI 3.1 specification |
Prompt | Description |
| Guided burnout assessment questionnaire template (FR/EN) |
Visit stresszeroentrepreneur.fr/intelligence-api and sign up. Free tier: 500 calls/month, no credit card required.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"stresszero": {
"command": "npx",
"args": ["-y", "stresszero-mcp"],
"env": {
"STRESSZERO_API_KEY": "sz_live_your_key_here"
}
}
}
}Add to .mcp.json at your project root or ~/.claude/mcp.json:
{
"mcpServers": {
"stresszero": {
"command": "npx",
"args": ["-y", "stresszero-mcp"],
"env": {
"STRESSZERO_API_KEY": "sz_live_your_key_here"
}
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"stresszero": {
"command": "npx",
"args": ["-y", "stresszero-mcp"],
"env": {
"STRESSZERO_API_KEY": "sz_live_your_key_here"
}
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"stresszero": {
"command": "npx",
"args": ["-y", "stresszero-mcp"],
"env": {
"STRESSZERO_API_KEY": "sz_live_your_key_here"
}
}
}
}Ask Claude: "Check my burnout risk. My sleep quality is 40/100, motivation is 55/100, and productivity is 35/100. I work 60 hours/week as an entrepreneur."
Claude will automatically call quick_burnout_check and return your score with recommendations.
AI coaching assistant — Help users self-assess their workload in real-time during conversations
HR AI agent — Aggregated, anonymized team load signals only (individual scores are never exposed to employers)
Wellness chatbot — Suggest next steps based on self-reported load, including seeing a doctor when signals persist
n8n automation — Trigger prevention workflows when a self-assessed score crosses a threshold
Productivity tool — Monitor self-reported wellbeing and suggest breaks
Free tier: 500 calls/month, no credit card. Current paid tiers and pricing: stresszeroentrepreneur.fr/intelligence-api
Variable | Required | Description |
| Yes | Your API key (starts with |
| No | Custom API base URL (default: |
git clone https://github.com/stresszero/stresszero-mcp.git
cd stresszero-mcp
npm install
npm run build
STRESSZERO_API_KEY=sz_live_xxx node build/index.jsDebug with the MCP Inspector:
npx @modelcontextprotocol/inspector node build/index.jsMIT — Emmanuel Gomes Soares, StressZero Entrepreneur
Score burnout risk across 3 dimensions (physical, emotional, effectiveness). Returns a 0-100 total score, risk level (low/moderate/high/critical), risk factors, urgency rating, and personalized recommendations. Requires 3-20 response items covering at least the 3 dimensions. Free tier: 500 calls/month. All tiers have access.
| Name | Required | Description | Default |
|---|---|---|---|
| responses | Yes | Array of 3-20 scored responses across the 3 burnout dimensions. Must include at least one item per dimension (physical, emotional, effectiveness). | |
| context | No | Optional context for more personalized analysis | |
| language | No | Response language: 'fr' (French, default) or 'en' (English) | fr |
| include_recommendations | No | Include personalized recommendations in the response. Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds valuable behavioral context including specific return values (0-100 score, risk levels, urgency rating), rate limits, and tier availability. No contradiction with annotations.
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?
Three efficiently structured sentences: purpose first, then requirements, then operational constraints. No redundant information; every sentence adds actionable detail not duplicated in the title or schema.
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?
Despite no output schema, the description comprehensively documents return values. Given the complex nested input structure (4 parameters with enums and nested objects), it adequately covers operational constraints and prerequisites.
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?
With 100% schema coverage (baseline 3), the description reinforces critical constraints ('3-20 response items', 'at least the 3 dimensions') that help agents understand how to properly populate the complex nested 'responses' array parameter.
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 uses specific verbs ('Score burnout risk') and identifies the resource (3 dimensions: physical, emotional, effectiveness). It distinguishes from sibling tools like 'quick_burnout_check' and 'generate_burnout_report' by emphasizing detailed multi-dimensional scoring with specific output metrics.
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 prerequisites ('Requires 3-20 response items covering at least the 3 dimensions') and rate limit context ('Free tier: 500 calls/month'). However, it lacks explicit guidance on when to choose this over 'quick_burnout_check' or 'generate_burnout_report'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive burnout assessment report with dimension-by-dimension analysis, action plans (immediate/short-term/long-term), and resource recommendations. REQUIRES Starter tier or above (29€/month). Free tier will receive a 403 error. More detailed than analyze_burnout — includes interpretations, status per dimension, and a structured action plan.
| Name | Required | Description | Default |
|---|---|---|---|
| responses | Yes | Array of 3-20 scored responses across the 3 burnout dimensions. | |
| context | No | Context for personalized report generation | |
| language | No | Report language: 'fr' (French) or 'en' (English) | fr |
| format | No | Output format: 'json' (structured data) or 'html' (rendered report) | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. Description adds critical behavioral context beyond annotations: specific pricing/auth requirement (29€/month Starter tier, 403 error) and output structure details (action plans split by timeframe, resource recommendations). No contradictions with annotations.
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?
Three sentences with zero waste: Sentence 1 states purpose and output contents; Sentence 2 states auth constraint; Sentence 3 distinguishes from sibling. Front-loaded with action verb. No redundant repetition of schema or annotation information.
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 complex nested schema (4 params with nested objects, enums) and no output schema, description adequately explains return value structure (analysis types, action plan categories) and critical auth constraints. Missing only minor details like explicit mention of JSON/HTML format differences handled by schema.
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 baseline is 3. Description references 'dimension-by-dimension' which loosely maps to the responses array structure, but does not add specific parameter guidance, syntax help, or examples beyond what the comprehensive schema already provides.
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?
Specific verb 'Generate' + resource 'burnout assessment report' + scope details (dimension-by-dimension analysis, action plans immediate/short-term/long-term, resource recommendations). Explicitly distinguishes from sibling analyze_burnout by stating it is 'More detailed' and lists specific additions (interpretations, status per dimension, structured action plan).
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?
Provides explicit prerequisite warning (Starter tier required, 403 error for Free tier). Names sibling tool analyze_burnout for comparison ('More detailed than analyze_burnout'). Implicitly guides selection by contrasting depth, though does not explicitly prescribe 'Use this when...' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a free StressZero API key (500 calls/month). Use this to help users get started with the API. The key is returned once and cannot be retrieved later. Requires a valid email address.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User's email address for the API key | ||
| project_name | No | Name of the project using the API key | MCP Integration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical context beyond annotations: rate limit '500 calls/month,' irrevocability 'key is returned once and cannot be retrieved later,' and prerequisite 'Requires a valid email address.' Aligns with idempotentHint=false (creates new resource each time) and destructiveHint=false.
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?
Four sentences with zero waste: (1) purpose+constraints, (2) usage context, (3) critical behavioral warning, (4) prerequisites. Well front-loaded and appropriately sized for a 2-parameter mutation tool.
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?
Lacks output schema but description compensates by stating the key is 'returned once.' Covers rate limiting, retrieval constraints, and authentication requirements. Missing only minor details like error cases for duplicate emails.
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 has 100% coverage so baseline is 3. Description adds validation emphasis ('valid email address') and implicitly contextualizes project_name via 'help users get started.' Elevates slightly above baseline by highlighting the required nature of email beyond just schema constraints.
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?
Specific verb 'Create' + resource 'StressZero API key' with clear scope (500 calls/month). Distinguishes from burnout analysis siblings (analyze_burnout, etc.) by focusing on API provisioning vs. burnout assessment.
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?
Explicitly states when to use: 'help users get started with the API.' Lacks explicit 'when not to use' or named alternatives, though differentiation from siblings is obvious from the domain shift (API keys vs burnout analysis).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simplified burnout screening with just 3 scores (one per dimension). Perfect for quick assessments in conversations, chatbots, or triage. Internally calls analyze_burnout with sensible defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| physical_score | Yes | Physical wellbeing score 0-100 (sleep quality, energy, health). Low = burnout risk. | |
| emotional_score | Yes | Emotional wellbeing score 0-100 (motivation, stress, mood). Low = burnout risk. | |
| effectiveness_score | Yes | Professional effectiveness score 0-100 (productivity, focus, achievement). Low = burnout risk. | |
| profession | No | Professional role (e.g., 'entrepreneur', 'developer', 'manager') | |
| hours_per_week | No | Weekly working hours (triggers overwork alert if > 50) | |
| language | No | Response language: 'fr' or 'en' | fr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read operation) and openWorldHint=true (external API call). Description adds value by disclosing the wrapper pattern ('internally calls analyze_burnout with sensible defaults'), helping agents avoid redundant calls. However, lacks details on output format or what constitutes 'sensible defaults'.
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?
Three sentences with zero waste: first defines the tool (simplified screening), second specifies use contexts (chatbots/triage), third explains implementation (wrapper with defaults). Information is front-loaded and every sentence earns its place.
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 100% schema coverage, presence of annotations, and the tool's nature as a simplified wrapper, the description adequately covers intent and delegation pattern. Minor gap: no mention of return value format (though no output schema exists to guide this).
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 coverage is 100%, establishing a baseline of 3. Description adds conceptual value by grouping the three required parameters as '3 scores (one per dimension),' providing semantic coherence that individual schema descriptions lack. Also hints at the optional parameters' purpose (profession, hours) through the use-case examples.
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?
Description states specific action ('simplified burnout screening') and resource (burnout/risk assessment). It clearly distinguishes from sibling 'analyze_burnout' by positioning itself as the lightweight alternative ('just 3 scores') and explicitly noting it wraps the other tool.
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?
Provides clear contexts for use ('quick assessments in conversations, chatbots, or triage') and explains relationship to sibling ('internally calls analyze_burnout'). Would be 5 if it explicitly stated 'use analyze_burnout instead for detailed analysis' rather than implying it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_burnoutgenerate_burnout_reportget_stresszero_api_keyquick_burnout_checkScored across 4 tools
The tools are mostly distinct, but analyze_burnout and quick_burnout_check have overlapping purposes, as quick_burnout_check is described as a simplified version that internally calls analyze_burnout. This could cause confusion about which to use for basic assessments. However, generate_burnout_report and get_stresszero_api_key are clearly separate in function.
All tool names follow a consistent verb_noun pattern (e.g., analyze_burnout, generate_burnout_report, get_stresszero_api_key, quick_burnout_check). The naming is uniform and predictable, making it easy for agents to understand the action and target of each tool.
With 4 tools, the count is well-scoped for a burnout assessment server. Each tool serves a specific purpose: analysis, reporting, API setup, and quick checks. This number is appropriate, avoiding both overcomplication and undercoverage for the domain.
The toolset covers key aspects of burnout assessment: analysis, reporting, and API access. However, there is a minor gap in update or management tools (e.g., for modifying API keys or reports), which agents might need for extended workflows. The core functionality is well-covered, but some advanced operations are missing.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
MCP server for Flux AI image generation
MCP server for NanoBanana AI image generation and editing
MCP server for Grok Imagine AI video generation
