Happy Server MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.10
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. Tools are grouped into session management (e.g., start, archive, list sessions), session interaction (e.g., send message, read messages, wait for idle), and Zen todo management (e.g., create, delete, update, list todos), with no overlap in functionality. The descriptions reinforce these distinct roles, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent 'happy_verb_noun' pattern with snake_case throughout. The naming is predictable and readable, with verbs like list, start, send, read, wait, create, delete, link, set, and update applied consistently to their respective nouns (e.g., sessions, messages, todos). There are no deviations in style or convention.
Tool Count5/5
With 15 tools, the count is well-scoped for the server's purpose of managing Happy AI sessions and Zen todos. Each tool earns its place by covering essential operations such as session lifecycle, interaction, and todo CRUD, without being excessive or sparse. This number supports comprehensive functionality while remaining manageable.
Completeness5/5
The tool surface provides complete coverage for the domain of Happy AI session and Zen todo management. For sessions, it includes start, archive, list, send messages, read messages, and wait for idle, plus supporting tools for machines and environment sets. For Zen todos, it offers full CRUD operations (create, read, update, delete) and linking to sessions, with no obvious gaps or dead ends in the workflow.
Average 3.3/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates a new item, implying a write operation, but lacks details on permissions, side effects (e.g., if it triggers notifications), error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose and key parameters without unnecessary words. It is appropriately sized and front-loaded with essential information.
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?
Given the tool is a mutation (create) with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns an ID, error cases), behavioral traits, or integration with sibling tools, leaving significant gaps for agent usage.
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%, with clear parameter documentation in the schema. The description adds minimal value by reiterating that 'text' is optional, but doesn't provide additional context like character limits, formatting, or examples beyond what the schema already specifies.
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 action ('Create a new Zen (todo) item') and specifies the resource ('todo item') with its core attributes ('title and optional description'). It distinguishes from siblings like happy_zen_list_todos (list) and happy_zen_update_todo (update), but doesn't explicitly differentiate from other creation-related tools (none in siblings).
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 (e.g., happy_zen_update_todo for modifications, happy_zen_set_todo_done for completion). It mentions optional parameters but offers no context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete' implies a destructive mutation, but the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, or what happens on success/failure. For a destructive operation with zero annotation coverage, this leaves significant behavioral gaps.
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 extremely concise - a single sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple delete operation and front-loads the essential information.
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 destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion (success confirmation, error cases), doesn't mention permissions or side effects, and provides no context about the todo system. Given the complexity of a delete operation, more completeness is needed.
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% (the 'id' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema - it doesn't explain where to find the todo ID, format requirements, or provide examples.
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 action ('Delete') and resource ('a Zen (todo) item'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'happy_zen_update_todo' or 'happy_zen_set_todo_done' which might also modify todo items, so it doesn't fully distinguish from alternatives.
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 like 'happy_zen_update_todo' or 'happy_zen_set_todo_done'. It doesn't mention prerequisites (e.g., needing an existing todo ID) or when deletion is appropriate versus updating status. No explicit when/when-not statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a linking operation, implying a mutation, but doesn't disclose behavioral traits such as permissions required, whether the link is reversible, error handling, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core action. It avoids unnecessary words and directly states the purpose. However, it could be slightly more structured by including key details like prerequisites or outcomes.
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?
Given the tool involves mutation (linking), has no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, error conditions, or usage context. For a 3-parameter mutation tool, more information is needed to guide an AI agent effectively.
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%, with clear descriptions for all three parameters (id, session_id, display_title). The description adds minimal value beyond the schema by mentioning 'display title' but doesn't elaborate on parameter meanings, constraints, or interactions. Baseline is 3 since the schema does the heavy lifting.
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 action ('Link'), the resources involved ('Zen (todo) item' and 'Happy session'), and the purpose ('with a display title'). It distinguishes from siblings like happy_zen_create_todo or happy_zen_update_todo by focusing on linking rather than creating or modifying. However, it doesn't explicitly differentiate from all siblings (e.g., happy_zen_set_todo_done might also involve todo items).
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 doesn't mention prerequisites (e.g., existing todo and session), exclusions, or compare it to siblings like happy_zen_update_todo (which might also handle linking). Usage is implied by the action but lacks explicit context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the toggle behavior when 'done' is not provided, which is useful, but lacks critical details: whether this requires specific permissions, if changes are reversible, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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, efficient sentence that front-loads the core action ('set or toggle') and resource. Every word earns its place by clarifying the tool's function without redundancy or fluff. It's appropriately sized for a simple tool with two parameters.
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?
Given this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't cover error conditions, response format, or side effects, leaving the agent to guess about outcomes. While the purpose is clear, the lack of behavioral and output context makes it inadequate for safe and informed use.
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 fully documents both parameters ('id' and 'done'). The description adds marginal value by explaining the toggle behavior when 'done' is omitted, but doesn't provide additional context like ID format examples or edge cases. This meets the baseline for high schema coverage without enhancing parameter understanding significantly.
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 verb ('set or toggle') and resource ('a Zen (todo) item completion status'), making the purpose immediately understandable. It distinguishes from siblings like 'happy_zen_create_todo' or 'happy_zen_update_todo' by focusing specifically on completion status manipulation. However, it doesn't explicitly mention that this is for existing todos only, which would make it a perfect 5.
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 doesn't mention prerequisites (e.g., needing an existing todo), compare with 'happy_zen_update_todo' which might also handle status changes, or specify scenarios where toggling versus explicit setting is preferred. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool updates fields, implying mutation, but doesn't disclose permissions needed, whether updates are reversible, error handling (e.g., invalid ID), or side effects. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It front-loads the core action and resource, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as what happens on success/failure, return values, error conditions, or how it interacts with other Zen todo tools (e.g., whether updates affect linked sessions).
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 parameters are fully documented in the schema. The description adds marginal value by confirming that 'title' and 'text' correspond to 'title and/or description' updates, but doesn't provide additional context like format constraints or examples beyond the schema.
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 action ('Update') and resource ('a Zen (todo) item'), specifying what fields can be modified ('title and/or description'). It distinguishes from siblings like happy_zen_create_todo (create) and happy_zen_delete_todo (delete), but doesn't explicitly differentiate from happy_zen_set_todo_done which modifies a different attribute.
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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing todo ID), exclusions, or comparisons with sibling tools like happy_zen_set_todo_done for marking completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return fields (session IDs, titles, etc.) but lacks critical details like whether this is a read-only operation, pagination behavior, error conditions, or performance characteristics. For a list tool with zero annotation coverage, this is insufficient.
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, efficient sentence that front-loads the core action and return data. Every word earns its place with no redundancy or wasted text.
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 low complexity (single optional parameter) and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it should ideally provide more behavioral context (e.g., default behavior, error handling) to be fully complete.
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 fully documents the 'limit' parameter. The description adds no additional parameter information beyond what the schema provides, which meets the baseline for high schema coverage.
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 verb ('List') and resource ('all Happy AI sessions'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'happy_list_machines' or 'happy_list_recent_paths' beyond the resource name, 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing, or comparisons to siblings like 'happy_list_machines', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation but doesn't disclose important behavioral traits: whether it lists all items or is paginated, if there are any filters or sorting options, what authentication is required, or how the data is returned. For a list operation with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that communicates the core functionality. It's appropriately sized for a simple list operation with no parameters. Every word earns its place - 'List' (verb), 'Zen (todo) items' (resource), and the specific attributes returned. No wasted words or unnecessary elaboration.
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?
Given no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain the return format, whether it's paginated, how results are structured, or how it differs from other list operations. For a tool in a server with 14 sibling tools including multiple list operations, more context about this specific list's scope and behavior would be helpful.
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 has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters since none exist. It appropriately focuses on what the tool does rather than parameter details. The baseline for 0 parameters with high schema coverage is 4, as there's nothing to compensate for.
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 verb 'List' and resource 'Zen (todo) items' with specific attributes (titles, descriptions, completion status). It distinguishes from siblings like create/delete/update/set_done operations but doesn't explicitly differentiate from other list tools on the server. The purpose is specific but could be more distinctive among multiple list operations.
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. There are multiple list tools on the server (list_environment_sets, list_machines, list_recent_paths, list_sessions) and other Zen todo operations (create, delete, update, set_done), but the description offers no context about when this specific list operation is appropriate versus other listing or todo management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool lists 'recently used folder paths' and hints at use for session starting, but doesn't disclose behavioral traits like whether this is a read-only operation, what format the output returns, if there are rate limits, or authentication needs. For a tool with no annotations, this leaves significant gaps.
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 sized with two concise sentences that are front-loaded with the main purpose. Every sentence adds value, though it could be slightly more structured by separating purpose from usage hint.
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 annotations and no output schema, the description is minimally adequate for a simple listing tool but lacks completeness. It covers the basic purpose and a usage hint, but doesn't address output format, error conditions, or detailed behavioral context, leaving room for improvement in a tool with 2 parameters.
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 (machine_id and limit). The description adds no additional meaning beyond what the schema provides, such as explaining what 'recently used' means or how paths are ordered. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('List recently used folder paths') and resource ('for a machine'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'happy_list_machines' or 'happy_list_sessions' which also list things, missing full sibling distinction.
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 provides implied usage context ('Useful for starting sessions in familiar locations'), suggesting when this tool might be helpful, but doesn't explicitly state when to use it versus alternatives or any exclusions. No clear guidance on prerequisites or comparisons to other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool reads messages, implying a read-only operation, but doesn't disclose behavioral traits such as permissions needed, rate limits, error handling, or what 'recent' entails (e.g., time-based or count-based). This leaves gaps for a tool with no annotation coverage.
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 two concise sentences that are front-loaded with the core purpose. Every sentence earns its place by stating what the tool does and its use case, with zero waste or redundancy.
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 annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on return values, error conditions, or behavioral context. For a read tool with no structured safety hints, it should do more to inform the agent about what to expect.
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%, with clear parameter descriptions in the schema. The description adds no additional meaning beyond the schema, such as format details for session_id or constraints on limit. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context.
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 verb 'Read' and resource 'recent messages from a Happy AI session', making the purpose unambiguous. It distinguishes from siblings like 'happy_send_message' (write) and 'happy_list_sessions' (list metadata), though not explicitly named. However, it could be more specific about what 'recent' means versus 'happy_list_recent_paths'.
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 implies usage for viewing conversation history, which suggests context like after sending a message or starting a session. However, it lacks explicit guidance on when to use this versus alternatives like 'happy_list_sessions' for session metadata or 'happy_send_message' for interaction. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral trait of 'bypass permissions mode', which is valuable context not in the schema. However, it doesn't cover other important aspects like rate limits, error handling, or what 'trigger it to work' entails (e.g., does it return a response?). This leaves gaps for a mutation tool.
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 a single, efficient sentence that front-loads the core purpose ('Send a message... to trigger it to work') and adds a key behavioral detail ('with bypass permissions mode'). There's no wasted text, but it could be slightly more structured by separating usage context from technical details.
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 annotations and no output schema, the description is moderately complete. It covers the basic action and a permission detail, but for a mutation tool with 3 parameters, it lacks information on return values, error cases, or dependencies (e.g., session must exist). This leaves the agent with gaps in understanding full behavior.
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 fully documents parameters like session_id and message. The description adds no additional meaning beyond the schema, such as explaining message format or session_id sourcing. 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 action ('send a message') and target ('to a Happy AI session'), with the specific purpose 'to trigger it to work'. It distinguishes from siblings like happy_read_messages (read vs. send) and happy_start_session (start vs. interact). However, it doesn't explicitly differentiate from all siblings, such as those in the 'zen' family, which handle todos rather than session messages.
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 implies usage by stating the tool sends a message to trigger work, suggesting it's for interacting with an active session. However, it lacks explicit guidance on when to use this vs. alternatives like happy_start_session (for new sessions) or happy_read_messages (for retrieving messages). No exclusions or prerequisites are mentioned, such as requiring an existing session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the session will be 'terminated and marked as inactive,' which implies a destructive, irreversible action, but does not cover critical details like required permissions, side effects (e.g., data loss), error conditions, or response format. This leaves significant gaps for a mutation tool.
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 two concise sentences with zero waste. The first sentence states the action and resource, and the second clarifies the outcome. It is front-loaded and appropriately sized for the tool's complexity, earning its place efficiently.
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?
Given the tool's destructive nature (implied by 'terminated'), lack of annotations, and no output schema, the description is incomplete. It fails to address permissions, reversibility, error handling, or return values, which are critical for safe and effective use. The description does not compensate for the missing structured data.
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?
Schema description coverage is 100%, so the schema already documents the single parameter (session_id). The description does not add any parameter-specific details beyond what the schema provides, but with only one parameter, the baseline is high. No extra semantic context is given, but the minimal parameter count reduces the need for compensation.
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 action ('Archive (stop)') and resource ('a Happy AI session'), distinguishing it from siblings like happy_list_sessions (list) and happy_start_session (create). The parenthetical 'stop' reinforces the termination action, making the purpose specific and unambiguous.
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 implies usage when a session should be terminated and marked inactive, but lacks explicit guidance on when to use this versus alternatives (e.g., happy_wait_for_idle for pausing, or happy_zen_link_session for linking). No exclusions or prerequisites are mentioned, leaving usage context partially implied rather than fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Returns machine IDs, hostnames, platforms, and activity status' which covers output content, but lacks behavioral details like whether it's paginated, rate-limited, requires authentication, or has any side effects. For a read operation with zero annotation coverage, this is insufficient.
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, efficient sentence that front-loads the core purpose ('List all machines registered with Happy') and adds useful detail about return values. Every word earns its place with zero waste.
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 simple list tool with no parameters and no output schema, the description adequately covers purpose and return data. However, without annotations or output schema, it should ideally mention behavioral aspects like pagination or authentication requirements to be fully 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 has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 ('List') and resource ('all machines registered with Happy'), and specifies the return data (machine IDs, hostnames, platforms, activity status). It distinguishes from siblings like happy_list_sessions and happy_list_environment_sets by focusing on machines rather than sessions or environment sets.
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 implies usage for retrieving machine information, but provides no explicit guidance on when to use this tool versus alternatives like happy_list_sessions or happy_list_environment_sets. No prerequisites, exclusions, or comparative context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool waits for a session to become idle, implying it blocks until processing finishes or times out. However, it doesn't detail behavioral traits like error handling, what 'idle' means precisely, or side effects (e.g., if it consumes resources). This is adequate but has gaps for a tool with no annotation coverage.
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 front-loaded and efficient: two sentences that directly explain the purpose and usage without waste. Every sentence earns its place by providing essential information, making it appropriately sized for the tool's complexity.
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 annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally complete. It covers the basic purpose and usage but lacks details on return values, error cases, or deeper behavioral context. For a wait tool with no structured output, this is adequate but not thorough.
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 ('session_id' and 'timeout_seconds') with descriptions. The description adds no additional meaning beyond what the schema provides, such as clarifying parameter interactions or usage tips. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Wait for a Happy AI session to become idle (finish processing).' It specifies the verb ('wait for') and resource ('Happy AI session'), making it understandable. However, it doesn't explicitly differentiate from siblings like 'happy_read_messages' or 'happy_send_message' in terms of timing or state management, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it: 'Useful after sending a message to wait for AI to complete its work.' This gives a specific scenario (post-message) but doesn't mention alternatives (e.g., polling with other tools) or exclusions (e.g., when not to wait), so it's not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional Git worktree creation for isolated development, which adds useful context beyond the basic action. However, it lacks details on permissions, rate limits, session lifecycle, or error conditions, leaving gaps for a mutation tool.
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 sized with three sentences, each earning its place: the core purpose, prerequisite tools, and optional Git worktree feature. It is front-loaded with the main action. Minor improvement could be tighter phrasing, but it avoids waste.
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 (8 parameters, mutation operation) and no annotations or output schema, the description is moderately complete. It covers purpose, prerequisites, and a key optional feature, but lacks details on behavioral traits like side effects, response format, or error handling, which are important for a session-starting tool.
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 all 8 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only implying that 'machine_id' and 'environment_preset_id' relate to outputs from sibling tools. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('Start a new Happy AI session') on a specific resource ('on a machine'), distinguishing it from siblings like happy_list_sessions (list) or happy_send_message (interact). It explicitly mentions the verb 'start' and the resource 'session', avoiding tautology with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it instructs to 'Use happy_list_machines to find available machines first' and 'Use happy_list_environment_sets to see available environment presets', naming specific sibling tools for prerequisite steps. This clearly defines the context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies this is a read-only operation by using 'List,' but does not disclose behavioral traits like whether it requires authentication, has rate limits, or returns paginated results. The description adds some context about the presets' purpose but lacks detailed behavioral disclosure.
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, efficient sentence that is front-loaded with the tool's purpose and includes additional context without waste. Every part of the sentence earns its place by clarifying the tool's function and usage.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and how its output is used, but could be more complete by detailing return format or behavioral aspects, though this is less critical for a simple list tool.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the semantics of the output (environment variable presets) and their use case, which compensates for the lack of an output schema, going beyond what the schema provides.
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 ('List') and resource ('available environment variable presets'), specifying what the tool does. It distinguishes from siblings by focusing on environment presets rather than sessions, machines, or other resources, making its purpose specific and unambiguous.
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 context by explaining that the presets 'can be used when starting new sessions with happy_start_session,' indicating when this tool is relevant. However, it does not explicitly state when not to use it or name alternatives, such as whether to use happy_list_sessions for session details instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![happy-server-mcp MCP server](https://glama.ai/mcp/servers/zhigang1992/happy-server-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zhigang1992/happy-server-mcp)

Score Badge

Copy to your README.md:

[![happy-server-mcp MCP server](https://glama.ai/mcp/servers/zhigang1992/happy-server-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhigang1992/happy-server-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/zhigang1992/happy-server-mcp'

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