How do I use Huly MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Huly MCP Server Create a new high priority issue to fix the login page bug" 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.

Huly MCP Server

by hha-nguyen

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Huly MCP Server

Custom MCP server for Huly workspace built from scratch. Runs on your remote server and connects to Huly WebSocket API.

Features

✅ Built from scratch - No dependencies on buggy huly-mcp package
✅ Fixes all bugs - Correct attachedToClass, collection, and kind fields
✅ Auto-resolves project kind IDs - Automatically gets correct task type for each project
✅ Runs on remote server - Deploy on your server where Huly is hosted
✅ Connects via SSH - Cursor connects via SSH to remote server

Installation on Remote Server

cd /path/to/huly-mcp-server
npm install
npm run build

Configuration

Create .env file or set environment variables:

HULY_URL=https://workspace.teasersoftware.com
HULY_EMAIL=your-email@example.com
HULY_PASSWORD=your-password
HULY_WORKSPACE=Teaser Software
PORT=3000

Running the Server

On Remote Server

npm start
# or for development
npm run dev

The server uses stdio transport (standard MCP protocol).

Connecting from Cursor

For HTTP Server (Remote)

Add to Cursor Settings → MCP Servers:

{
  "mcpServers": {
    "huly-remote": {
      "url": "http://your-server-ip:3000/mcp",
      "env": {
        "HULY_URL": "https://workspace.teasersoftware.com",
        "HULY_EMAIL": "your-email@example.com",
        "HULY_PASSWORD": "your-password"
      }
    }
  }
}

For Stdio Server (Local)

{
  "mcpServers": {
    "huly-local": {
      "command": "node",
      "args": ["/absolute/path/to/huly-mcp-server/dist/index.js"],
      "env": {
        "HULY_URL": "https://workspace.teasersoftware.com",
        "HULY_EMAIL": "your-email@example.com",
        "HULY_PASSWORD": "your-password"
      }
    }
  }
}

How It Works

Connects to Huly: Uses WebSocket API to connect to your Huly workspace
Resolves Project IDs: Automatically converts project names to space IDs
Gets Correct Kind ID: Queries existing issues to get the correct task type ID for each project
Creates Issues Correctly: Sets all fields correctly:
- attachedToClass: "tracker:class:Issue"
- collection: "subIssues"
- kind: <project-specific-id>

Available Tools

create_issue - Create issues with correct fields
list_issues - List issues from projects
list_projects - List all projects

Development

npm run dev:http  # Run HTTP server in development
npm run dev       # Run stdio server in development
npm run build     # Build TypeScript

Deployment on Remote Server

1. Copy to Server

scp -r huly-mcp-server user@your-server:/opt/huly-mcp-server

2. Install and Build

ssh user@your-server
cd /opt/huly-mcp-server
npm install
npm run build

3. Create .env File

cat > .env << EOF
HULY_URL=https://workspace.teasersoftware.com
HULY_EMAIL=hha.nguyen298@gmail.com
HULY_PASSWORD=Ha@29082002
HULY_WORKSPACE=Teaser Software
EOF

4. Test Locally on Server

node dist/index.js
# Should see: "Huly MCP Server running on stdio"

The server is ready! Cursor will connect via SSH.

Available Tools

3 tools

create_issueC

Create a new issue in Huly with correct fields

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Issue title
`description`	No	Issue description (Markdown supported)
`priority`	No	Issue priority
`project`	Yes	Project identifier or name (required)
`assignee`	No	Person name to assign the issue to (optional)
`component`	No	Component name to assign the issue to (optional)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation tool, implying a write operation, but doesn't mention permissions required, rate limits, error handling, or what happens on success (e.g., returns an issue ID). 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point without unnecessary words. However, it could be more front-loaded by immediately stating the core purpose, and the phrase 'with correct fields' is somewhat vague, slightly reducing clarity.

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 incomplete. It doesn't explain what the tool returns (e.g., issue ID, success confirmation), error conditions, or behavioral nuances like whether duplicate issues are allowed, which are critical for an agent to use it 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?

The input schema has 100% description coverage, clearly documenting all 6 parameters with their types, enums, and requirements. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced 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 action ('Create a new issue') and target resource ('in Huly'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'list_issues' beyond the basic create vs. list difference, missing an opportunity to clarify when to use each.

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 'list_issues' or 'list_projects'. It mentions 'with correct fields' but doesn't specify what constitutes correct fields or any prerequisites, leaving the agent with minimal context for decision-making.

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

list_issuesC

List issues from Huly

ParametersJSON Schema

Name	Required	Description	Default
`project`	No	Filter by project identifier (optional)

TDQS

C2.7/5.0

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 only states the action ('List issues') without describing traits like pagination, rate limits, authentication needs, or what 'Huly' refers to. This leaves significant gaps in understanding the tool's 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 extremely concise with a single sentence 'List issues from Huly', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary details.

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 lack of annotations and output schema, the description is incomplete. It does not explain what 'Huly' is, the return format, or any behavioral context, making it inadequate for a tool that likely returns a list of issues without further guidance.

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?

The input schema has 100% description coverage, with one optional parameter 'project' documented as 'Filter by project identifier (optional)'. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List issues from Huly' clearly states the verb ('List') and resource ('issues'), but it's vague about scope and lacks differentiation from sibling tools like 'create_issue'. It doesn't specify whether this lists all issues, filtered issues, or something else, which reduces clarity.

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 like 'create_issue' or 'list_projects'. The description does not mention any context, prerequisites, or exclusions, leaving the agent without usage instructions.

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

list_projectsB

List all projects in Huly

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

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 it's a list operation, implying read-only behavior, but doesn't specify any constraints like pagination, sorting, filtering, or rate limits. For a tool with zero annotation coverage, this is insufficient transparency.

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 without any unnecessary words. It's front-loaded and appropriately sized for a simple list tool, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, or output format. For a list tool with no structured support, it should provide more guidance 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 input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description doesn't add parameter details, which is appropriate here. The baseline for 0 parameters is 4, as no additional parameter semantics are needed.

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 ('projects in Huly'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_issues', which would require a 5. The description is specific but lacks 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 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 'list_issues' or 'create_issue'. It doesn't mention any context, prerequisites, or exclusions for usage. This leaves the agent without direction on tool selection.

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

Tool Schema Changelog

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

3 tool updatesv1.0.0Jan 27, 2026
- First observedcreate_issue
- First observedlist_issues
- First observedlist_projects

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-04-18 06:25 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: create_issue handles creation, list_issues handles listing issues, and list_projects handles listing projects. There is no overlap or ambiguity between these three operations.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case: create_issue, list_issues, list_projects. The naming is predictable and uniform throughout the set.

Tool Count3/5

With only 3 tools, the set feels thin for a project management domain like Huly, lacking operations such as update_issue, delete_issue, or get_project. However, it covers basic listing and creation, making it borderline appropriate.

Completeness2/5

The tool surface is significantly incomplete for managing issues and projects. It includes create_issue and list_issues but misses update_issue and delete_issue, and list_projects lacks corresponding create_project, get_project, or update_project operations, leaving agents with dead ends.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Loom
io.github.abhinand-adviciya
Manage Loom projects, tasks, bugs, defects, clients and phases from AI assistants
Project Management Testing & QA Tools
1
Tack
io.github.Thefirstmannnn
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Project Management Workplace & Productivity
1
OrbitOAuth
io.github.Noveum
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Project Management Workplace & Productivity
130
KelviaOAuth
io.github.gonnagetapower
Task manager your agent can fully operate: boards, tasks, sprints, roles, worklogs, day planner.
Project Management Workplace & Productivity
11