Skip to main content
Glama
Sign In
huly-mcp-selfhost

huly-mcp-selfhost

by JoKeks2023
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

check_setup

Read-only

Diagnose Huly MCP configuration issues by verifying version updates, login, workspaces, front URL, and non-secret settings.

Instructions

Diagnose the setup: version and updates, login, workspaces, front URL, settings (no secrets)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceNo
skipVersionCheckNoSkip asking npm for the latest version

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered structurally. The description adds genuine value by disclosing the diagnostic scope and that no secrets are returned, plus 'version and updates' hints at an external npm lookup, but it says nothing about result format, severity, or whether checks abort on the first failure.

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?

One front-loaded sentence with the scope stated immediately and no filler. The parenthetical '(no secrets)' earns its place, though the telegraphic comma list is a bit cryptic.

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?

With no output schema and one of two parameters undocumented, the description should say more about what a report looks like and how failures surface. It describes inputs checked but not the return shape an agent must interpret.

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 coverage is 50%: skipVersionCheck is documented in the schema, while the workspace parameter is undocumented there. The description only weakly compensates, mentioning 'workspaces' as a checked area and 'version and updates' as the thing skipVersionCheck controls, without stating that workspace scopes the whole diagnosis.

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 verb 'Diagnose' plus an enumerated checklist (version/updates, login, workspaces, front URL, settings) tells the agent exactly what this tool inspects, and it is clearly distinct from the issue/comment CRUD siblings. Only gap is that 'the setup' never names the product or environment being diagnosed.

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?

Usage is only implied: an agent can infer this is a troubleshooting/health-check call, but there is no explicit statement of when to call it, what a healthy vs. failing result means, or any alternative tool for configuration problems.

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

Deploy Server

Other Tools