Horizon MCP

by henry-insomniac

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. Tools like hz_fetch_items, hz_score_items, hz_filter_items, hz_enrich_items, and hz_generate_summary represent sequential stages in a content processing pipeline, while others handle metadata, metrics, configuration, and pipeline execution, all with non-overlapping functions.
Naming Consistency5/5
All tool names follow a consistent hz_verb_noun pattern with snake_case throughout. The naming is predictable and readable, making it easy to understand each tool's function at a glance, such as hz_list_runs, hz_get_metrics, and hz_run_pipeline.
Tool Count5/5
With 12 tools, the count is well-scoped for a content processing pipeline server. Each tool earns its place by covering distinct aspects like pipeline stages, metadata access, metrics, configuration validation, and full pipeline execution, without being excessive or insufficient.
Completeness5/5
The tool set provides complete coverage for the content processing domain. It includes all pipeline stages (fetch, score, filter, enrich, summarize), metadata and summary retrieval, run listing, metrics monitoring, configuration validation, and a full pipeline execution tool, leaving no obvious gaps for agent workflows.
Average 2.7/5 across 12 of 12 tools scored. Lowest: 2.1/5.
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

Behavior1/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 lists the pipeline steps without explaining what the tool actually does behaviorally—e.g., whether it's read-only or destructive, its permissions, rate limits, or output format. This is inadequate for a tool with 9 parameters and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that lists the pipeline steps concisely. It's front-loaded with the core action ('一键执行') and wastes no words, though it could benefit from slightly more detail given the tool's complexity.
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 complexity (9 parameters, no annotations, 0% schema coverage), the description is incomplete. It doesn't explain the tool's behavior, parameter roles, or output (even though an output schema exists, the description doesn't hint at what it returns). For a multi-step pipeline tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 9 parameters are documented in the schema. The description adds no information about what parameters like 'hours', 'languages', or 'threshold' mean or how they affect the pipeline. It fails to compensate for the lack of schema documentation, leaving parameters entirely unexplained.
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 '一键执行抓取->打分->过滤->富化->摘要' clearly states the tool executes a pipeline of operations (crawl, score, filter, enrich, summarize), which is a specific verb+sequence. However, it doesn't distinguish this from sibling tools like hz_fetch_items, hz_score_items, etc., which handle individual pipeline steps, so the purpose is clear but lacks sibling differentiation.
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 its siblings (e.g., hz_fetch_items for just crawling, hz_score_items for just scoring). It implies usage for a full pipeline execution but doesn't specify contexts, prerequisites, or alternatives, leaving the agent to guess based on tool names 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'fetch and deduplicate content' and 'write to the raw stage', which implies data retrieval, processing, and storage, but lacks details on permissions, side effects, error handling, or performance traits. For a tool with 5 parameters and no annotations, 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 concise with a single sentence, but it's under-specified rather than efficiently informative. It's front-loaded but lacks detail, making it somewhat wasteful in terms of clarity. However, it avoids redundancy and is structurally simple.
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 5 parameters with 0% schema coverage, no annotations, and an output schema (which might help with return values), the description is incomplete. It doesn't explain the tool's role in the pipeline, parameter purposes, or behavioral context, making it inadequate for a tool of this complexity. Sibling tools suggest a data processing workflow, but this isn't leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description does not mention any parameters or provide meaning beyond the generic 'fetch and deduplicate content'. It fails to compensate for the low coverage, leaving all 5 parameters (hours, run_id, horizon_path, config_path, sources) without contextual explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '抓取并去重内容，写入 run 的 raw 阶段' (Fetch and deduplicate content, write to the raw stage of a run) states a purpose but is vague. It mentions 'fetch and deduplicate content' without specifying what content or from where, and 'write to the raw stage of a run' lacks context on what a 'run' or 'raw stage' entails. It doesn't clearly distinguish from siblings like hz_enrich_items or hz_filter_items, which might involve similar processing stages.
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 explicit guidance on when to use this tool versus alternatives is provided. The description implies it's for an initial data ingestion phase ('raw stage'), but it doesn't specify prerequisites, when not to use it, or how it relates to siblings like hz_run_pipeline or hz_list_runs. Usage is only vaguely implied by the mention of 'run' and 'raw stage'.
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 the full burden of behavioral disclosure. It indicates a write operation ('写入 enriched 阶段'), suggesting mutation, but it doesn't disclose critical traits like permissions needed, whether it's idempotent, rate limits, or what happens if enrichment fails. The description is too brief to provide adequate behavioral context for a tool that modifies data.
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 concise with a single sentence, front-loaded with the core action. There's no wasted text, but it may be overly brief, risking under-specification. It efficiently states the purpose without redundancy.
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 complexity (involving enrichment and writing to a stage), lack of annotations, 0% schema description coverage, and 4 parameters, the description is incomplete. It doesn't explain the enrichment process, error handling, or output (though an output schema exists, which mitigates some gaps). For a mutation tool in a pipeline context, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description must compensate by explaining parameter meanings, but it adds no information beyond the schema. It doesn't clarify what 'run_id', 'source_stage', 'horizon_path', or 'config_path' are used for, leaving the agent to guess based on titles alone. This is insufficient given the low coverage.
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 states the tool '对高分内容执行背景富化，写入 enriched 阶段' (performs background enrichment on high-scoring content, writes to the enriched stage), which provides a specific verb ('执行背景富化') and resource ('高分内容'), but it doesn't clearly distinguish this from sibling tools like hz_filter_items or hz_score_items, which might also process content in a pipeline. The purpose is somewhat vague regarding what 'background enrichment' entails.
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 mentions writing to the 'enriched stage', which implies it's part of a pipeline, but it doesn't specify prerequisites (e.g., after scoring or filtering) or name any sibling tools as alternatives. Without explicit when-to-use or when-not-to-use instructions, the agent lacks clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('读取' - reads) without any information about permissions, rate limits, response format, or whether this is a safe read operation. This is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's function. It's appropriately sized for a simple tool, though it could be more front-loaded with critical information given the lack of annotations.
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 that an output schema exists, the description doesn't need to explain return values. However, for a tool with 2 parameters, 0% schema coverage, and no annotations, the description should provide more context about what 'summary content' means and how it differs from other run-related tools. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions '指定 run' (specified run) which hints at the run_id parameter, but doesn't explain what a run is, what format the ID should be, or mention the language parameter at all. This adds minimal value beyond the bare schema.
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 states the tool reads summary content for a specified run, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like hz_get_run_meta or hz_get_run_stage that also retrieve run-related information, making the purpose somewhat vague in context.
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. With sibling tools like hz_get_run_meta and hz_get_run_stage, there's no indication of what distinguishes this tool's 'summary content' from other run data, leaving usage unclear.
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 mentions generating a Markdown summary but doesn't explain what happens during generation, whether this is a read-only operation or creates new data, what permissions might be required, or how the output relates to the input parameters. The description is too minimal to adequately inform an agent about the tool's behavior beyond the basic action.
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 extremely concise - a single sentence in Chinese. While this could be seen as efficient, it borders on under-specification rather than true conciseness. There's no wasted language, but also no helpful elaboration. The structure is simple and front-loaded with the core action.
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 that there's an output schema (which should document return values), the description doesn't need to explain outputs. However, for a tool with 6 parameters (all undocumented in schema), no annotations, and complex sibling relationships, the single-sentence description is inadequate. It doesn't provide enough context about what 'stage content' means, how the generation works, or when to use this versus other summary-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters (1 required, 5 optional), the description provides no information about any parameters. It doesn't explain what 'run_id', 'language', 'source_stage', 'horizon_path', 'config_path', or 'save_to_horizon_data' mean or how they affect the summary generation. The description fails to compensate for the complete lack of parameter documentation in the schema.
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 states the basic purpose ('从某阶段内容生成 Markdown 摘要' - 'Generate Markdown summary from certain stage content'), which identifies the verb (generate) and resource (summary). However, it's vague about what '某阶段内容' (certain stage content) refers to and doesn't distinguish this tool from sibling tools like hz_get_run_summary or hz_get_run_stage that might also retrieve or process stage-related information.
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 sibling tools that deal with runs, stages, and summaries (hz_get_run_summary, hz_get_run_stage, hz_get_run_meta), but the description doesn't explain how this generation tool differs from those retrieval tools or when one should be preferred over another.
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 only states it 'reads' content, implying a read-only operation, but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or what 'stage content' entails (e.g., structured data, logs, or metadata). This is inadequate for a tool with parameters and potential complexity.
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, concise sentence in Chinese that directly states the tool's function. It's front-loaded with no unnecessary words, making it efficient and easy to parse, though it lacks depth.
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 has an output schema (which reduces the need to describe return values), 3 parameters with 0% schema coverage, and no annotations, the description is minimally adequate but incomplete. It states the basic purpose but misses parameter explanations, behavioral context, and differentiation from siblings, leaving gaps for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'run' and 'stage' implicitly but doesn't define what a 'run' or 'stage' is, their formats, or the purpose of 'max_items'. The description adds minimal value beyond the schema's property names, failing to clarify parameter meanings or usage.
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 states the purpose as '读取指定 run 的某一阶段内容' (Read the content of a specified stage of a run), which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like hz_get_run_meta or hz_get_run_summary, leaving ambiguity about what distinguishes 'stage content' from 'meta' or 'summary' information.
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, exclusions, or compare to sibling tools like hz_get_run_meta or hz_get_run_summary, leaving the agent to guess based on tool names 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 for behavioral disclosure. It mentions filtering by threshold and topic deduplication, but doesn't explain what happens during filtering (e.g., items below threshold are discarded), what 'topic deduplication' entails, or the write operation's characteristics (overwrites, appends, creates new stage). No information about permissions, rate limits, or error behavior is included.
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 Chinese sentence that states the core functionality and outcome. Every word contributes essential information with zero waste. It's front-loaded with the primary action and efficiently communicates the tool's purpose.
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 6-parameter tool with 0% schema coverage and no annotations, the description is insufficient. While an output schema exists (which reduces need to describe returns), the description lacks crucial context about parameter meanings, behavioral details, and integration within the pipeline. It doesn't explain what 'filtered stage' means operationally or how this tool interacts with siblings like hz_score_items that likely precede it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all 6 parameters are undocumented in the schema. The description only mentions 'threshold' and 'topic deduplication' (matching threshold and topic_dedup parameters), leaving run_id, source_stage, horizon_path, and config_path completely unexplained. It doesn't provide format expectations, default behaviors, or relationships between parameters.
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 ('按阈值过滤并做主题去重' - filter by threshold and perform topic deduplication) and the outcome ('写入 filtered 阶段' - write to filtered stage), providing a specific verb+resource combination. It doesn't explicitly distinguish from siblings like hz_score_items or hz_enrich_items, but the filtering+dereplication purpose is reasonably distinct within a pipeline context.
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 about when to use this tool versus alternatives. The description mentions writing to 'filtered stage' which implies it's part of a pipeline sequence, but there's no explicit direction about prerequisites (e.g., after scoring) or when to choose this over other filtering approaches. The context suggests it follows scoring stages, but this is only implied.
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 mentions that scoring is performed by AI and results are written to a 'scored' stage, but lacks details on permissions, rate limits, side effects (e.g., whether it modifies existing data), or error handling. This is inadequate for a tool that likely involves AI processing and data mutation.
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 directly states the tool's function. It is front-loaded with the core action and outcome, with no unnecessary words. However, it could be slightly more informative without sacrificing brevity.
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 complexity of an AI scoring tool with 4 parameters, 0% schema coverage, no annotations, but an output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, parameter meanings, and usage context. The presence of an output schema mitigates the need to explain return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only vaguely references '指定阶段内容' (specified stage content), which might relate to 'source_stage', but fails to explain the purpose of 'run_id', 'horizon_path', or 'config_path'. This leaves most parameters without semantic clarification beyond their titles.
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 ('执行 AI 打分' - perform AI scoring) and the target ('指定阶段内容' - specified stage content), with the outcome being writing to a 'scored' stage. It distinguishes from siblings like hz_enrich_items or hz_filter_items by focusing on scoring. However, it doesn't specify what exactly is being scored (e.g., items, data points), making it slightly less specific than 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 like hz_enrich_items or hz_filter_items, nor does it mention prerequisites or context for invocation. It simply states what the tool does without indicating appropriate 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?
No annotations are provided, so the description carries full burden. It mentions listing 'recent' runs and stage status, implying a read-only operation, but doesn't disclose behavioral traits like pagination, ordering, rate limits, authentication needs, or what 'recent' means (e.g., time-based or count-based). For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 in Chinese that directly states the tool's function. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be slightly more specific (e.g., clarifying 'recent'), but overall it's appropriately concise.
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 has an output schema (which should document return values), no annotations, and a simple input schema with one optional parameter, the description is minimally adequate. It states what the tool does but lacks context on usage relative to siblings and behavioral details. For a list tool with output schema support, this is the bare minimum to be functional.
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 one parameter (limit) with 0% description coverage, so the schema provides no semantic context. The description doesn't mention parameters at all, but since there's only one optional parameter with a default value, the baseline is high. The tool likely functions without any input, and the limit parameter is straightforward, so the lack of parameter explanation is less critical.
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 states '列出最近运行记录与阶段状态' (List recent run records and stage status), which provides a basic verb+resource combination. However, it's vague about scope ('recent' is ambiguous) and doesn't differentiate from sibling tools like hz_get_run_meta, hz_get_run_stage, or hz_get_run_summary that also appear to retrieve run-related information. The purpose is understandable but lacks specificity.
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. With multiple sibling tools related to runs (hz_get_run_meta, hz_get_run_stage, hz_get_run_summary, hz_run_pipeline), the description offers no context about distinctions, prerequisites, or exclusions. The agent must infer usage from the tool name 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'validate' implies a read-only diagnostic operation, the description doesn't specify what happens during validation: whether it returns detailed error reports, success/failure status, what 'key environment variables' means, whether it modifies anything, or what permissions are required. For a validation 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 extremely concise - a single sentence in Chinese that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's front-loaded with the core function and appropriately sized for what it communicates.
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 that an output schema exists, the description doesn't need to explain return values. However, for a validation tool with 4 parameters and no annotations, the description is too minimal. It doesn't provide enough context about what 'validation' entails, what constitutes valid vs invalid configuration, or how the parameters interact. The existence of an output schema helps, but the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (titles only, no descriptions) and 4 parameters, the description provides no information about what the parameters mean or how they affect validation. The description mentions 'Horizon configuration' and 'environment variables' which loosely map to some parameters, but doesn't explain horizon_path vs config_path, what 'sources' refers to, or what 'check_env' controls. The description doesn't compensate for the schema's lack of parameter documentation.
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 ('校验' meaning 'validate') and the target ('Horizon 配置和关键环境变量' meaning 'Horizon configuration and key environment variables'). It uses a specific verb and identifies the resource being validated. However, it doesn't explicitly differentiate this validation tool from its many sibling tools (like hz_get_metrics or hz_run_pipeline), which all operate on Horizon-related resources.
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. With 11 sibling tools on the server, there's no indication whether this should be used before running a pipeline, after configuration changes, or as a diagnostic tool. The description doesn't mention prerequisites, dependencies, or typical usage scenarios.
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 only states it reads metadata without specifying what metadata includes, whether it's a safe read operation, any permissions required, or response format. This leaves significant gaps for a tool with an output schema.
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 no wasted words. It's front-loaded with 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations and low schema coverage, it lacks context on behavior, usage, and parameter details. It's minimally adequate but has clear gaps for a metadata-reading 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 0%, so the description must compensate. It implies a 'run_id' parameter is needed to specify which run's metadata to read, adding some meaning beyond the bare schema. However, it doesn't detail format, constraints, or examples, leaving the parameter only partially clarified.
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 ('读取' meaning 'read') and resource ('指定 run 的元数据' meaning 'specified run's metadata'), making the purpose understandable. However, it doesn't differentiate from sibling tools like hz_get_run_stage or hz_get_run_summary, which appear to read related run data.
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, exclusions, or comparisons to sibling tools like hz_list_runs or hz_get_run_summary, leaving usage context unclear.
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 the full burden of behavioral disclosure. It states the tool reads memory metrics but doesn't add context such as what service it targets, whether it requires authentication, rate limits, or what the output format entails. This is a significant gap 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 a single, efficient sentence: '读取服务内存指标.' (Read service memory metrics). It is front-loaded with the core purpose, has zero waste, and is appropriately sized for a simple tool. Every word earns its place.
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 (0 parameters, no annotations, but with an output schema), the description is minimally complete. It states what the tool does but lacks context like service scope or behavioral traits. The output schema exists, so return values needn't be explained, but overall it's adequate with clear gaps in usage and transparency.
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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any gaps, and it appropriately doesn't mention parameters. A baseline of 4 is applied since no parameter info is required, but it's not a 5 as it could hint at implicit inputs (e.g., service 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 tool's purpose as '读取服务内存指标' (read service memory metrics), which specifies both the verb (read) and resource (service memory metrics). It distinguishes from siblings like hz_list_runs or hz_get_run_summary by focusing on metrics rather than runs or items. However, it doesn't explicitly differentiate from all siblings (e.g., hz_get_run_meta might also involve metrics), keeping it from 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., when memory metrics are needed), or exclusions (e.g., not for CPU metrics). With siblings like hz_get_run_summary that might include metrics, the lack of explicit comparison leaves usage unclear.
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:

[![Horizon-mcp MCP server](https://glama.ai/mcp/servers/henry-insomniac/Horizon-mcp/badges/card.svg)](https://glama.ai/mcp/servers/henry-insomniac/Horizon-mcp)

Score Badge

Copy to your README.md:

[![Horizon-mcp MCP server](https://glama.ai/mcp/servers/henry-insomniac/Horizon-mcp/badges/score.svg)](https://glama.ai/mcp/servers/henry-insomniac/Horizon-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/henry-insomniac/Horizon-mcp'

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